Bug#1057087: RFA: ikiwiki -- wiki compiler
Hi, Jonathan Dowland (2023-11-29): > I'm still actively using IkiWiki and want it to continue to be > well-maintained in Debian. I am happy to co-maintain the package, Thanks a lot, Jonathan! > Thank you Simon for doing an amazing job, upstream and in Debian, > keeping IkiWiki going. Yes, thanks a lot Simon! Cheers, -- intrigeri
Bug#1006872: RFH: apparmor -- user-space parser utility for AppArmor
Hi Andrej, Andrej Shadura (2022-03-07): > This reminded me I promised to work on dh-apparmor. I should find > time for that, Great! > maybe also for apparmor itself. Sounds good. Please keep me updated as you think about it :)
Bug#1006872: RFH: apparmor -- user-space parser utility for AppArmor
Package: wnpp Severity: normal X-Debbugs-Cc: debian-de...@lists.debian.org, pkg-apparmor-t...@alioth-lists.debian.net Control: affects -1 src:apparmor Hi, I request assistance with maintaining the apparmor package. AppArmor has been enabled by default on the Linux ports of Debian since Buster. The big picture of AppArmor maintenance in Debian is pretty good: - Vincas Dargis has been helping quite a lot on the policy (profiles) side of things — thanks! - Various package maintainers are taking care of AppArmor profiles shipped in their packages, asking help when needed, which is awesome. - Debian folks have generally been very cooperative when it comes to making AppArmor work on their system, e.g. by submitting merge requests upstream when suggested. - The kernel part of things happens upstream. AFAIK it did not require dedicated work on the Debian side for years. But regarding maintenance of src:apparmor itself, the bus factor of in Debian is 1, which is not great. I don't feel comfortable with this situation. src:apparmor includes: - system initialization bits - AppArmor parser, which is required to compile AppArmor profiles and load them into the kernel for use by the AppArmor Linux Security Module - abstractions, i.e. reusable bits of policy The workload is not particularly big: I would say a few hours per month on average. Upstream is very cooperative. Cheers!
Bug#996440: O: metche -- configuration monitor to ease collective administration
Package: wnpp Severity: normal Control: affects -1 src:metche I intend to orphan the metche package. The package description is: metche monitors changes made to a "system state" composed of: - a "watched" directory (typically: /etc) - one or more user maintained changelog files (e.g. /root/Changelog) - the state of Debian packages and versions (using apt-show-versions) by periodically: - saving backups of the corresponding files - emailing the changes in the system state to your administrators' mailing list For context and details, see https://bugs.debian.org/913719. Cheers!
Bug#992081: RFP: elpa-persistent-scratch -- preserve scratch buffers across Emacs sessions
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-emac...@lists.debian.org * Package name: elpa-persistent-scratch Version : 0.3.5 Upstream Author : Fanael Linithien * URL or Web page : https://github.com/Fanael/persistent-scratch * License : BSD 2-clause "Simplified" License Description : preserve the state of scratch buffers across Emacs sessions
Bug#983108: Closing power-profiles-daemon ITP?
Hi, I see that power-profiles-daemon has been in experimental for a while? Is there any particular reason why we should not close this ITP? Thanks a lot for packaging this piece of software, can't wait to try it once GNOME 41 lands in sid with the corresponding GNOME Shell UI bits :)
Bug#977896: ITP: metadata-cleaner -- View and remove metadata in files
Hi, > I would like to maintain this program Awesome, thanks! > and am searching for a sponsor. I suggest you get in touch with the maintainers of MAT2 in Debian: https://tracker.debian.org/pkg/mat2 They might be happy to sponsor uploads of your work, and perhaps even to collaboratively maintain this package together with you under the umbrella of their team :) Cheers!
Bug#974897: RFP: elpa-moody -- tabs and ribbons for the Emacs mode line
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-emac...@lists.debian.org * Package name: elpa-moody Version : 0.5.4 Upstream Author : Jonas Bernoulli * URL or Web page : https://github.com/tarsius/moody * License : GPL 3+ Description : tabs and ribbons for the Emacs mode line
Bug#974896: RFP: elpa-company-quickhelp -- add documentation popups to company completion candidates
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-emac...@lists.debian.org * Package name: elpa-company-quickhelp Version : 2.3.0 + Git master Upstream Author : Dmitry Gutov * URL or Web page : https://github.com/company-mode/company-quickhelp * License : GPL-3 Description : add documentation popups to company completion candidates
Bug#960788: ITP: alsa-sof-firmware -- Intel SOF audio firmware and topology
Hi, Hector Oron (2020-09-04): > Missatge de Jordi Mallach del dia dj., 3 de set. > 2020 a les 16:48: > >> After claiming it and looking at the source, I resolved this probably >> belongs as part of linux-firmware or whatever the source name is, as >> Ubuntu did. zumbi@ has been talking to the kernel people about this but >> right now I'm unsure what the status is. > > That is correct, we have been discussing it at the #debian-kernel IRC > channel and Maximilian was planning to add this SOF-bin to the > firmware-nonfree package. Great news, thanks a lot for the summary! So we could close this ITP (#960788, since in the end no new source package will be introduced) in favor of #949019 and #962134, which could themselves be merged, right? I'm happy to do the BTS paperwork if this makes sense to you folks :) > I believe Lenovo is supportive and is going to send a machine to > Maximilian to be able to test it out. This is great news too. With my Tails hat on I'll suppose this will take some time on the Debian/Lenovo side. Cheers!
Bug#960788: ITP: alsa-sof-firmware -- Intel SOF audio firmware and topology
Hi Jordi, I see you took responsibility for this ITP a few months ago. Are you in a position to share a rough timeline? Cheers!
Bug#968843: RFH: asciio -- dynamically create ASCII charts and graphs with GTK+2
Hi Nick, Nick Black (2020-08-22): > intrigeri left as an exercise for the reader: >> Or is there a good alternative to asciio in the archive? >> (I was not able to find any.) > > What all graphs are you hoping to draw? I'm not using asciio myself, but a colleague of mine uses it to draw diagrams: boxes, labels, connectors, arrows — the sort of things you could do with LibreOffice Draw or Dia. Cheers!
Bug#968843: RFH: asciio -- dynamically create ASCII charts and graphs with GTK+2
Package: wnpp Severity: normal X-Debbugs-Cc: debian-de...@lists.debian.org, da...@debian.org Hi, on behalf of its maintainer David Paleino, I request assistance about the asciio package. The package description is: This gtk2-perl application allows you to draw ASCII diagrams in a modern (but simple) graphical application. The ASCII graphs can be saved as ASCII or in a format that allows you to modify them later. Upstream has been inactive for 4+ years and unfortunately, this program uses the deprecated libgtk2-perl (#912870), so what's needed here is essentially a new upstream maintainer, who would port this program to another GUI toolkit. Or is there a good alternative to asciio in the archive? (I was not able to find any.) Cheers!
Bug#964022: ITP: libdata-password-zxcvbn-perl -- Perl port of Dropbox's password strength estimation library, zxcvbn
Hi tous, I encourage you to join the Debian Perl Group and maintain this package within this team: https://perl-team.pages.debian.net/ :) Cheers!
Bug#958338: ITP: libsub-handlesvia-perl -- alternative handles_via implementation for Moo, Moose, and more
Package: wnpp Owner: intrigeri Severity: wishlist X-Debbugs-CC: debian-p...@lists.debian.org * Package name: libsub-handlesvia-perl Version : 0.013 Upstream Author : Toby Inkster (TOBYINK) * URL : https://metacpan.org/release/Sub-HandlesVia * License : Artistic or GPL-1+ Programming Lang: Perl Description : alternative handles_via implementation for Moo, Moose, and more If you've used Moose's native attribute traits, or MooX::HandlesVia before, you should have a fairly good idea what Sub::HandlesVia does. Why re-invent the wheel? Well, this is an implementation that should work okay with Moo, Moose, Mouse, and any other OO toolkit you throw at it. One ring to rule them all, so to speak. Also, unlike MooX::HandlesVia, it honours type constraints, plus it doesn't have the limitation that it can't mutate non-reference values. The package will be maintained under the umbrella of the Debian Perl Group. It's a new dependency of recent libmoox-late-perl, which is in the archive already.
Bug#916210: ITP: rauc -- Robust Auto-Update Controller
Uwe Kleine-König: > Update: Arnaud and I spend some time now and there is a rauc-1.1-1 > package now that waits for the OK by the ftp team, see > https://ftp-master.debian.org/new/rauc_1.1-1.html . Excellent, thanks a lot! (rauc is one of the tools we want to investigate at Tails to replace our own upgrade system) Cheers, -- intrigeri
Bug#922002: ITP: gotop -- terminal based graphical activity monitor inspired by gtop and vtop
Hi, this looks like a duplicate of #921276 so perhaps you can join Antoine's efforts :) Cheers!
Bug#898622: ITP: mat2 -- Metadata Anonymisation Toolkit 2
Hi! For the record we've started some discussion upstream about the relationship between MAT and MAT2 / the future of MAT v1. Personally I don't have anything at stake wrt. what's decided upstream, although I've already shared my thoughts with Julien privately. What matters to me is the users' perspective. I think we should provide a clear, unambiguous transition path and avoid leaking technical details to users. So once MAT2 reaches feature parity with MAT (I think the only real blocker is the lack of a Nautilus extension; MAT v1's seems to be broken on sid currently but it has a GUI which mitigates that problem) I think we should: - Have mat2 conflicts+replaces mat, remove mat from testing+sid, and ship a transitional package called mat that pulls mat2 in. Or simply call mat2 source and binary packages "mat". - Ensure the app launcher (.desktop) for MAT2 makes it clear that it provides MAT, without leaking version numbers or such: GenericName=Metadata Anonymisation Toolkit Name=MAT Thoughts? Cheers!
Bug#897633: ITP: bolt -- system daemon to manage thunderbolt 3 devices
Is this different from #884363 or a duplicate? In any case: thanks a lot for working on this!
Bug#849727: [Pkg-privacy-maintainers] Bug#849727: Adopting seahorse-nautilus?
Clément Hermann: > Since there is no news for a while and seahorse-nautilus has been > removed from testing, I'll resume work on this under the pkg-privacy > umbrella. Excellent, thanks! > Carlos, feel free to jump in if you still want to work on this package! Indeed, team-maintenance is more pleasant (having someone around to ask for advice/opinions in nice) and produces higher-quality packages. And Ulrike is committed to work on this package as well, at least until the end of 2018Q1, so you folks have a dedicated sponsor to upload your work already :) Cheers, -- intrigeri
Bug#879716: ITP: usbauth-notifier -- Notifier for USB Firewall to use with desktop environments
Stefan Koch: > * Package name: usbauth-notifier > * URL : https://github.com/kochstefan/usbauth-all/usbauth-notifier FWIW I get an error 404 there. > A notifier for the usbauth firewall against BadUSB attacks. The user > could manually allow or deny USB devices. I'm curious: what are the pros/cons compared to usbguard, that's already in Debian?
Bug#873753: GnuPG Perl bindings in Debian [Re: Bug#873753: O: libcrypt-gpg-perl -- An Object Oriented Interface to GnuPG]
gregor herrmann: > On Thu, 07 Sep 2017 18:11:16 -0400, Daniel Kahn Gillmor wrote: >> Over on https://bugs.debian.org/873753, Ricardo Mones wrote: >> >> > The current maintainer of libcrypt-gpg-perl, Roberto Jimeno >> > <robertojimen...@terra.es>, >> > is apparently not active anymore. Therefore, I orphan this package now. >> fwiw, this package has not been updated for many years (nearly a >> decade), and is several versions behind upstream (1.52, in unstable >> today, was released upstream in 2005!). I strongly doubt whether it >> even works with modern versions of GnuPG. It also has no reverse >> dependencies. > Yes. > I had a short look; the package has direct changes to the code and > doesn't run the test suite. Trying to enable it leads to syntax > errors (!) in t/*.t. > Popcon votes: 16 is not that low, and there is a newer upstream > release, but I think working on this package would bring more pain > than benefit, and I also doubt it works with gpg2. > So +1 for removal from me. +1 I'm not entirely happy with GnuPG::Interface, but at least it works with modern GnuPG and some of my contributions upstream were accepted eventually. Let's make it more obvious that it's the least worst that we have right now. Cheers, -- intrigeri
Bug#826551: [Pkg-puppet-devel] RFP: puppetdb-termini -- Enable a Puppet master to connect to PuppetDB
Hi, micah: > Apollon Oikonomopoulos <apoi...@debian.org> writes: >>> On the master, I see nothing in the puppet logs, but I do see in the >>> apache logs: >>> >>> newpuppetmaster:8140 0.0.0.0 - - [03/Feb/2017:08:41:30 -0800] "GET >>> /production/certificate/puppetdb? HTTP/1.1" 404 5361 "-" "Ruby" >>> >>> but nothing else. The puppetmaster has no certs pending to be signed and >>> only has one cert signed (the puppetmaster itself). There is nothing in >>> /var/lib/puppet/ssl on the master besides the puppetmaster cert bits. >>> >>> I'm wondering if this works for others, or if maybe this part of the >>> puppet3 compatibility was missed? >> >> From the looks of it, you're using a Webrick puppetmaster. You should >> switch to puppet-master-passenger instead :) > Hmmm, I've got that installed: > ii puppet-master-passenger 4.8.2-1 all > configuration management system, scalable master service [...] > am I missing something here? Micah, has this been fixed since then somehow? If not, may you please report it as a separate bug, since it already affects Stretch and is somewhat off-topic on a bug report that's about "Enable a Puppet master to connect to PuppetDB"? Cheers, -- intrigeri
Bug#826551: [Pkg-puppet-devel] RFP: puppetdb-termini -- Enable a Puppet master to connect to PuppetDB
Hi! Apollon Oikonomopoulos (Thu, 2 Feb 2017): > Following up, here's a more detailed course of action: [...] > - As soon as 4.8.2-1 enters testing, I intend to upload 4.8.2-2, with >the following changes: > * Restore the vim-puppet and puppet-el binary packages, which were > removed in 4.4.2-1. > * Import the PuppetDB terminus from PuppetDB 4.3.0. > * Ship the PuppetDB terminus in puppet-terminus-puppetdb. (Closes: > #826551) >It will go through NEW for puppet-terminus-puppetdb, vim-puppet and >puppet-el, but there should be no problems here. > - When 4.8.2-2 hits unstable and if all is well, I will file for an >unblock request to have 4.8.2-2 migrate to testing. At that point the >decision will be up to the release team. > - If and when 4.8.2-2 is accepted in testing, I will file for a >jessie-pu to update 3.7.2-4 in Jessie to also include the PuppetDB >terminus (from PuppetDB 2.3.8). Again, the terminus will be provided >in a new binary package, puppet-terminus-puppetdb. > If all goes well, we should end up with PuppetDB-enabled versions in > both Jessie and Stretch. Also, for the puppet-terminus-puppetdb package > I'm using PuppetDB's version numbers (and not the puppet source > version), so that the package can be taken over by the puppetdb source > when the latter is ready for Debian. I really like this plan. Is it still up-to-date? Cheers, -- intrigeri
Bug#849727: Adopting seahorse-nautilus?
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 :) > 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? Cheers, -- intrigeri
Bug#849727: Adopting seahorse-nautilus?
Hi team, seahorse-nautilus was orphaned (#849727). Upstream is not very active, and most of the non-translation-related commits there since a few years come from people working for or on Tails. Last package upload was prepared by Ulrike. Any objection to our team adopting this package? Cheers, -- intrigeri
Bug#835923: ITP: libgtk3-simplelist-perl -- Perl simple interface to GTK+ 3's complex MVC list widget
Package: wnpp Owner: intrigeri <intrig...@debian.org> Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libgtk3-simplelist-perl Version : 0.15 Upstream Author : Thierry Vignaud <tvign...@cpan.org> * URL : https://metacpan.org/release/Gtk3-SimpleList * License : Artistic or LGPL-2.1+ Programming Lang: Perl Description : Perl simple interface to GTK+ 3's complex MVC list widget Gtk3 has a powerful, but complex MVC (Model, View, Controller) system used to implement list and tree widgets. Gtk3::SimpleList automates the complex setup work and allows you to treat the list model as a more natural list of lists structure. After creating a new Gtk3::SimpleList object with the desired columns you may set the list data with a simple Perl array assignment. Rows may be added or deleted with all of the normal array operations. You can treat the data member of the list simplelist object as an array reference, and manipulate the list data with perl's normal array operators. A mechanism has also been put into place allowing columns to be Perl scalars. The scalar is converted to text through Perl's normal mechanisms and then displayed in the list. This same mechanism can be expanded by defining arbitrary new column types before calling the new function. The package will be maintained under the umbrella of the Debian Perl Group.
Bug#777382: O: dogtail
Hi, (Cc-ing anonym, who's our dogtail specialist at Tails.) Michael Prokop: > I just took care of the upload of a new upstream version of dogtail. Great, thank you :) > @intrigeri: IIRC Tails uses dogtail too, so maybe you're interested > in helping the dogtail maintence? :) I had totally missed the fact that the dogtail package was orphaned, when we started using it at Tails a few months ago. Oops :) I'd rather not commit to any new thing right now, but I've just subscribed to the package tracker so it's now on my radar, and I _might_ find time to give a hand from time to time ⇒ feel free to ask whenever help is needed. Maybe start by pushing to a Vcs-Git in collab-maint? Cheers, -- intrigeri
Bug#829740: [Pkg-privacy-maintainers] Bug#829740: RFP: corridor - a Tor traffic whitelisting gateway
Hi Patrick, Patrick Schleizer wrote (05 Jul 2016 18:28:00 GMT) : > Is someone from the PkgPrivacyMaintainers team interested / willing to > help get corridor [4] [5] [6] into Debian? Not me. > I: corridor source: unused-file-paragraph-in-dep5-copyright paragraph at > line 3 > https://github.com/adrelanos/corridor/blob/debian_new/debian/copyright > Any idea what is wrong in the debian/copyright file? "Multiple Files paragraphs are allowed. The last paragraph that matches a particular file applies to it. More general paragraphs should therefore be given first, followed by more specific overrides." (https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/) > Would a combined manpage, i.e. 'man corridor', symlinked to the > individual command names (corridor-init-forwarding, corridor-init-snat, > ...) be acceptable by Debian policy and otherwise or should a separate > man page per binary be provided? I guess it would be OK, but I didn't re-read Policy 12.1 in details recently. > And I never figured out how to manually figure out a mailing list > reference number and replicate it so that the thread does not break. AFAIK the bits you want are correct "In-Reply-To" and "References" headers :) Cheers, -- intrigeri
Bug#673515: ITP: puppetdb -- Puppet data warehouse
Hi, Stig Sandbeck Mathisen wrote (31 May 2016 13:06:19 GMT) : > In theory (and documentation) the puppetdb-termini package must match > the version of the puppetdb you are connecting to. In practice, the > puppetdb-termini is updated less frequently than puppetdb, and it may > work without updating, but without any promises. > Debian only accepts one version of a package at a time. This may > prevent you from upgrading puppetdb to a version not supported by the > puppetdb-termini in Debian, and when the puppetdb-termini package in > Debian is updated, you may have to update your PuppetDB installation to > follow. Good to know. It seems that the most common use cases can be handled relatively easily by maintaining puppetdb-termini in stretch-backports in addition to Stretch itself, so Debian stable users at least can choose between using a PuppetDB corresponding to the version of Puppet shipped in Stretch, or or a more up-to-date one. > Apart from that, it does not look very hard at all to build only the > puppetdb-termini from the puppetdb source. Good! I've filed a RFP: #826551. Cheers, -- intrigeri
Bug#826551: RFP: puppetdb-termini -- Enable a Puppet master to connect to PuppetDB
Package: wnpp Severity: wishlist * Package name: puppetdb-termini Version : 4.1.1 Upstream Author : PuppetLabs * URL or Web page : https://github.com/puppetlabs/puppetdb * License : Apache License version 2.0 Description : Enable a Puppet master to connect to PuppetDB As discussed on https://bugs.debian.org/673515, packaging these bits this seems to be the only realistic way to enable a Puppet master to connect to PuppetDB, without requiring any 3rd-party packages on the Puppet master's side. One will still need to install PuppetDB somehow (e.g. using upstream's packages), but then it can live on a separate system, which allows to confine PuppetDB as much as possible, in order to avoid the need to trust 3rd-party (upstream) APT repositories on the puppetmaster. puppetdb-termini has no dependencies except puppet-agent. It just ships 16 .rb files, that live in the upstream PuppetDB Git repository, and are distributed in PuppetDB upstream tarballs. Also, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673515#38 for a potential problem wrt. versioning of PuppetDB vs. puppetdb-termini. Cheers, -- intrigeri
Bug#673515: ITP: puppetdb -- Puppet data warehouse
Hi, Stig Sandbeck Mathisen wrote (29 May 2016 12:39:53 GMT) : > intrigeri <intrig...@debian.org> writes: >> Are there currently any plans to package PuppetDB for Debian? > I'm not aware of any. > I spent a few days on it in 2012, but the necessary free time investment > to learn all the required tools and package all the requirements was too > big for me then, and still is. OK, thanks for making this clear :) >> Any expected specific difficulty that would be worth sharing here? > A packaging effort will require a familiarity with Leiningen, Maven and > Clojure in particular, and Java application packaging in general. I'm > not familiar with either of these. > Leiningen is no longer packaged in Debian, it is only present in > "oldstable". > Puppet's Cloujure projects depend on "trapperkeeper"[0], also referred > to as "tk", and are built with a buildsystem called "ezbake"[1] which is > a Leiningen plugin. > PuppetDB also has a lot of other dependencies[2] which need to be mapped > to existing Debian packages, or packaged. Ouch. This sounds like a really big amount of work, just to get used to the needed tools. It would be great if someone did that, but I'm not holding my breathe. >> Rationale for my question: the infrastructure behind Tails [0] relies >> on exported resources, and we can't allow ourselves to rely on >> third-party packages. > When you really need exported resources, there's nothing like it. Exactly, that's why it would be very sad to lose support for this feature when upgrading to Stretch. > One can in _some_ cases use Hiera to provide the necessary data to > puppet for creating resources across many hosts. This does, however, > require you to generate that data beforehand. I'm afraid Hiera can't solve our problem: we use exported resources e.g. to set up monitoring from the classes that manage services. So, here's another idea. Let's assume one needs exported resources, and thus PuppetDB, but they want to confine PuppetDB as much as possible, in order to avoid the need to trust 3rd-party (upstream) APT repositories on the puppetmaster. So, say PuppetDB is installed from upstream on a dedicated system. Then, if I got it right, the only bit missing in Debian, for the puppetmaster to be able to connect to PuppetDB without using any 3rd-party packages, is puppetdb-termini. Correct so far? puppetdb-termini has no dependencies except puppet-agent. It just ships 16 .rb files, that live in the upstream Puppet Git repository, and are distributed in PuppetDB upstream tarballs. So it seems that the only realistic way to go, in order for Debian Stretch to support the use case I've described, without having to tackle the packaging of PuppetDB itself, would be to package puppetdb-termini. Would you, or anyone else, be up to it? Cheers, -- intrigeri
Bug#673515: ITP: puppetdb -- Puppet data warehouse
Hi, are there currently any plans to package PuppetDB for Debian? Any expected specific difficulty that would be worth sharing here? Rationale for my question: the infrastructure behind Tails [0] relies on exported resources, and we can't allow ourselves to rely on third-party packages. (BTW: thanks for packaging & uploading Puppet 4!) [0] https://tails.boum.org/ Cheers, -- intrigeri
Bug#637051: RFP: TreeMaker -- TreeMaker is a program for the design of origami bases.
Hi, it seems that TreeMaker used to require a custom build of a patched wxwidget, and in any case is explicitly marked as not compatible with wxwidget 2.7 and newer. Cheers, -- intrigeri
Bug#753012: ITP: vagrant-libvirt -- Vagrant provider for libvirt
Hi, Antonio Terceiro wrote (19 Feb 2016 12:48:29 GMT) : > On Wed, Feb 17, 2016 at 07:18:58PM +0100, intrigeri wrote: >> It would be awesome if this could be uploaded within the next few >> weeks or months [...] > by all means, please go ahead. Woohoo, this is encouraging, thanks :) I can certainly do the initial upload. But I can't reasonably commit to maintain these two packages on the long term; besides, not being a Ruby guy, I'm concerned that just staying on top of current pkg-ruby-extras best practices would add some overhead on my side that I'd rather skip. So I'd rather not be listed in the Uploaders field. What I can do, though, is use the packages daily, on my personal systems (sid) and on the Tails infrastructure (generally Debian stable), file as good bug reports as I can, and send you folks pull requests whenever I can do that without leaving my comfort zone too much. So, who wants to be commit to maintain the package (== be listed in the Uploaders field)? Antonio and/or Miguel? Anyone else? Another option (that I like less, but well) could be that I try to maintain the package as long as it's easy, and I shout and ask for help whenever it gets harder / more Ruby -specific. > when you have code to create the boxes, would you please add them to > http://anonscm.debian.org/cgit/cloud/debian-vm-templates.git/ ? > (feel free to send me patches if you don't want to go through the hoops to > obtaining write access etc) I'll check with anonym how we do boxes, and we'll see if/how it applies to Debian cloud images. > or does it use the virtualbox boxes the way they are? I think we can either trivially convert a VirtualBox box with qemu-img, or build a dedicated one e.g. with vmdebootstrap. Cheers! -- intrigeri
Bug#796265: ITP: tor-monitor -- GTK+ application to display Tor circuits and streams
Control: retitle -1 ITP: onioncircuits -- GTK+ application to display Tor circuits and streams Upstream is in the process of renaming the software to onioncircuits (to avoid including "Tor" in the name, for trademark reasons). > * URL : http://git.tails.boum.org/alan/tor-monitor/ ... becomes https://git-tails.immerda.ch/onioncircuits/ Stay tuned for an actual upstream release that takes the rename into account. Cheers, -- intrigeri
Bug#753012: ITP: vagrant-libvirt -- Vagrant provider for libvirt
Hi Miguel, Antonio and others, Miguel Landaeta wrote (14 Aug 2015 20:10:32 GMT) : > On Thu, Aug 13, 2015 at 03:52:11PM +0200, intrigeri wrote: >> It would not be reasonable of me to add these packages to my plate, >> but perhaps the pkg-ruby-extras team could? > Awesome, if nobody beats me to it I could take a look at them and > upload them soon. Excellent! I wanted to move this forward a bit, so I've merged Antonio's previous work into mine (we had Git history without any common ancestor), and then updated both packages to the latest upstream release. The current state of my work can be found there: https://git-tails.immerda.ch/intrigeri/ruby-fog-libvirt/ https://git-tails.immerda.ch/intrigeri/vagrant-libvirt/ The resulting binary packages have seen a bit of manual testing, conducted by my Tails team-mate anonym (Cc'ed). I assume he'll be happy to go on testing preliminary packages if needed :) It would be awesome if this could be uploaded within the next few weeks or months (we'll likely need this for working on making Tails builds reproducible soonish, and in any case getting rid of our dependency on VirtualBox would make the life of some of our developers easier). Antonio: for vagrant-libvirt, it seems that you haven't pushed your upstream and pristine-tar branches, nor the upstream/0.0.31 tag, while you pushed the corresponding changes in the master branch. And for ruby-fog-libvirt, it seems that you haven't pushed the upstream/0.0.2 tag. Can you please push the missing bits? Thanks in advance! Cheers, -- intrigeri
Bug#796295: closed by Tzafrir Cohen <tzaf...@debian.org> (Bug#796295: fixed in hspell 1.2-3)
Control: reopen -1 Hi Tzafrir, it seems like you've typo'ed a bug number in a d/changelog or something => you might need to manually close another bug. Cheers!
Bug#796295: RFH: torbrowser-launcher -- helps download, update and run the Tor Browser Bundle
Package: wnpp Severity: normal X-Debbugs-Cc: pkg-anonymity-to...@lists.alioth.debian.org torbrowser-launcher is maintained by the pkg-anonymity-tools team. Sadly, it's been regularly broken in Jessie since the release, especially with AppArmor enabled, and testing/sid haven't always been in a much better shape. We would welcome help for triaging bug reports, forwarding them upstream, ensuring that upstream puts out bugfix releases in a timely manner, or worst case identifying the commits we should cherry-pick and ship in sid and possibly in stable proposed updates. Cheers, -- intrigeri
Bug#795668: ITP: libdist-zilla-plugin-test-eol-perl -- Author tests making sure correct line endings are used
Package: wnpp Owner: intrigeri intrig...@debian.org Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org * Package name: libdist-zilla-plugin-test-eol-perl Version : 0.18 Upstream Author : Florian Ragwitz r...@debian.org, Caleb Cushing xenoterrac...@gmail.com, Karen Etheridge et...@cpan.org * URL : https://metacpan.org/release/Dist-Zilla-Plugin-Test-EOL * License : Artistic or GPL-1+ Programming Lang: Perl Description : Author tests making sure correct line endings are used This is an extension of LDist::Zilla::Plugin::InlineFiles, providing the file Fxt/author/eol.t, a standard LTest::EOL test. The package will be maintained under the umbrella of the Debian Perl Group.
Bug#751205: b43-fwcutter
Hi, Sidharth Krishnan wrote (02 Apr 2015 12:00:18 GMT) : I am aware of the problem and have spoken to the maintainer Daniel Echeverry. Even though he put it up for adoption, I am not yet maintainer, and only he can make changes and commit. In the source package I see: Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/b43-fwcutter.git Vcs-Git: git://anonscm.debian.org/collab-maint/b43-fwcutter.git ... so anyone who's in collab-maint has write access there. So you should be able to adopt the package, maintain it in Git, and use requests for sponsorships if you lack upload rights. Cheers, -- intrigeri
Bug#753012: ITP: vagrant-libvirt -- Vagrant provider for libvirt
Hi, Antonio Terceiro wrote (16 Jun 2015 18:19:57 GMT) : Now it is even easier to package vagrant plugins, instructions are in the README.Debian for vagrant: [...] Confirmed, thanks a lot for making it this simple! I've prepared an initial, untested packaging of vagrant-libvirt and its only missing dependency: https://git-tails.immerda.ch/intrigeri/vagrant-libvirt https://git-tails.immerda.ch/intrigeri/ruby-fog-libvirt It would not be reasonable of me to add these packages to my plate, but perhaps the pkg-ruby-extras team could? If someone (or preferably a team) volunteers, then I'm sure that someone at Tails will happily test packages before they are uploaded to the archive. Many thanks in advance! Cheers, -- intrigeri
Bug#794211: ITP: libmemory-usage-perl -- Determine actual memory usage of Perl programs
Package: wnpp Owner: intrigeri intrig...@debian.org Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org * Package name: libmemory-usage-perl Version : 0.201 Upstream Author : Dave O'Neill d...@dmo.ca * URL : https://metacpan.org/release/Memory-Usage * License : Artistic or GPL-1+ Programming Lang: Perl Description : Determine actual memory usage of Perl programs Memory::Usage measures, from the operating system's perspective, how much memory a Perl program is using at any given time. It can record memory usage at specific times, and report about it afterwards. -- 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/20150731093022.3413C721CA7@localhost
Bug#733860: Debian Pond Packages
Ximin Luo wrote (11 Jan 2015 16:34:40 GMT) : I spoke to upstream (agl) at 31c3 and explained to him what Debian experimental is, and he is happy for it to be packaged there for now. Woohoo! \o/ -- 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/85oaq5i39b@boum.org
Bug#448638: RFP: i2p -- I2P is an anonymizing network
kytv wrote (20 Nov 2014 03:08:58 GMT) : On Mon, 17 Nov 2014 12:01:12 + (UTC) intrigeri intrig...@debian.org wrote: Now that you've started contributing to Debian, maybe you would be interested in maintaining I2P directly in there? This would make the Tails release process and source tree a bit simpler :) Yes, I would certainly be willing to do so. \o/ I think the next formal step is to retitle this bug to ITP and set yourself as the owner, then :) Cheers, -- intrigeri -- 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/85a93mbcbj@boum.org
Bug#448638: RFP: i2p -- I2P is an anonymizing network
Hi Kill Your TV, Carlos Alberto Lopez Perez wrote (13 Mar 2013 03:31:16 GMT) : retitle 448638 RFP: i2p -- I2P is an anonymizing network [...] If anyone of you want to step in and take care of packaging I2P for Debian please re-title the bug back to ITP and assign it to you. If it happens that there is more than one person interested on packaging I2P, then the interested ones can talk between them to check the possibility of maintaining the package together. Now that you've started contributing to Debian, maybe you would be interested in maintaining I2P directly in there? This would make the Tails release process and source tree a bit simpler :) Cheers, -- intrigeri -- 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/851tp2ca4p@boum.org
Bug#724344: ITP: bdsync -- bdsync is a fast block device synchronizing tool
Hi maxigas, did you really intend to file this bug as an ITP (intent to package), or instead as a RFP (request for package)? Cheers, -- intrigeri -- 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/85bnplinba@boum.org
Bug#754120: ITP: python-gnupg-ng -- A Python wrapper for GnuPG
Hi, micah anderson wrote (14 Aug 2014 21:12:03 GMT) : Also - we have a package ready to upload for it. Where can I find this package? Cheers, -- intrigeri -- 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/85r40g9fht@boum.org
Bug#753012: [Tails-dev] Bug#753012: RFP: vagrant-libvirt -- Vagrant provider for libvirt
Hi Miguel, Miguel Landaeta wrote (02 Aug 2014 14:44:20 GMT) : I'm not a libvirt or Vagrant maintainer but I can take care of this package. This would totally rock. \o/ However, I think vagrant needs to be updated. Otherwise, this package is not really useful. Right. There's been WIP documented on Debian#741996 a month ago. Cheers, -- intrigeri -- 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/85lhr62a98@boum.org
Bug#753010: [Pkg-mozext-maintainers] Bug#753010: RFP: xul-ext-disconnect -- Make the web faster, more private, and more secure
Hi, @David: thanks a lot for looking into this! David Prévot wrote (29 Jun 2014 01:32:47 GMT) : Looking at their README [1], it may be a bit challenging to distribute it within Debian: “The Disconnect logos […] used in this program cannot be reused without permission and no license is granted thereto.” (If I understood correctly the purpose of this extension is to “See how websites collect and use your data” with “Easy-to-understand icons for thousands of sites” [2]) Indeed... I should have looked beyond than what https://addons.mozilla.org/en-US/firefox/addon/disconnect/ was telling me. Many icons under firefox/content/disconnect.safariextension in the source tree are, I guess, problematic to distribute. So, even if we were willing to package a rebranded version of this extension (to avoid issues with upstream's trademark policy and non-free logos), we would still not be there. @Freepto folks: are you interested in looking at this deeper, e.g. to find ways to replace the non-free icons with others? If not, I think we should simply close this RFP bug. There are also quite a few embedded code copies: https://github.com/disconnectme/disconnect#software-used I've not looked at which of these ones are available in Debian. Cheers, -- intrigeri -- 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/85y4wghtxo@boum.org
Bug#753010: RFP: xul-ext-disconnect -- Make the web faster, more private, and more secure
Package: wnpp Severity: wishlist * Package name: xul-ext-disconnect Version : 3.14.0 Upstream Author : Brian Kennish byoo...@gmail.com * URL or Web page : https://disconnect.me/ * License : GPL-3 Description : Make the web faster, more private, and more secure. The Freepto [1] Debian derivative is shipping this extension, presumably for good reasons. They're trying to reduce their delta with Debian, and a good step in this direction would be to have all browser extensions they ship part of Debian. Then, we at Tails [2] may consider shipping this extension too. The Freepto people are somewhat interested in maintaining this package themselves, but they lack the needed skills right now, and it'll take some time to get them up-to-speed, so it would be great if someone else tackled the initial packaging work. [1] http://www.freepto.mx/en/ [2] https://tails.boum.org/ Cheers, -- intrigeri -- 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/85tx75npfb@boum.org
Bug#753012: [Tails-dev] Bug#753012: RFP: vagrant-libvirt -- Vagrant provider for libvirt
Dear libvirt / Vagrant maintainers, vinc3nt wrote (28 Jun 2014 14:37:32 GMT) : Package name: vagrant-libvirt Version: 0.0.18 Upstream Author: Lukas Stanek URL: https://github.com/pradels/vagrant-libvirt License: MIT License Description: Vagrant provider for libvirt. Would you be interested in maintaining vagrant-libvirt in Debian? It would greatly help at least Tails [1] and Freepto [2]. [1] https://tails.boum.org/ [2] http://www.freepto.mx/ Cheers, -- intrigeri -- 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/851tu8okav@boum.org
Bug#747235: RFP: tracebox -- Middlebox Detection Tool
Hi Axel, hi OONI folks, [Note: 747235@bugs.d.o, Cc'd, is publicly archived.] Axel Beckert wrote (06 May 2014 16:07:18 GMT) : Package: wnpp Severity: wishlist * Package name: tracebox Version : 0.1 Upstream Author : Gregory Detal gregory.de...@uclouvain.be et al. * URL or Web page : http://www.tracebox.org/ * License : GPLv2+ Description : Middlebox Detection Tool Tracebox is a tool that allows to detect middleboxes on any paths, i.e., between a source and any destination. Tracebox can be viewed as a tool similar to traceroute as it uses ICMP replies to identify changes in the packets. The fact that tracebox is able to detect middleboxes comes from the observation that ICMP messages are often not as defined in RFC792. Indeed it is quite common to receive a ICMP Time-to-Live exceeded message with the original datagram instead of 64 bits as described in the standard. This is caused by operating systems configured to reply with full ICMP (e.g., Linux, Cisco IOS-XR, etc.) as well as the ICMP Multi-Part Messages extension that standardize the fact that routers using MPLS tunnels replies and ICMP message containing the full datagram. There seems a start of Debian packaging in the upstream repository, but it's not complete (missing debian/copyright), and doesn't build a working package, at least not when being used from a plain git checkout. It seems that a prerequisite for packaging tracebox is packaging libcrafter: https://github.com/pellegre/libcrafter -- it's included in https://github.com/tracebox/tracebox as a git submodule. This sounds like something potentially useful for OONI (https://ooni.torproject.org/). Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85siomlvf1@boum.org
Bug#743841: ITP: libdist-zilla-plugin-localemsgfmt-perl -- Dist::Zilla plugin to compile PO files with Locale::Msgfmt
Package: wnpp Owner: intrigeri intrig...@debian.org Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org * Package name: libdist-zilla-plugin-localemsgfmt-perl Version : 1.203 Upstream Author : Patrick Donelan pdone...@cpan.org * URL : https://metacpan.org/release/Dist-Zilla-Plugin-LocaleMsgfmt * License : Artistic or GPL-1+ Programming Lang: Perl Description : Dist::Zilla plugin to compile PO files with Locale::Msgfmt Dist::Zilla::Plugin::LocaleMsgfmt is a Dist::Zilla plugin that compiles PO files, found in a configurable location, to the binary (.mo) message catalog file format. The resulting .mo files can then be included in the dist tarball generated by dzil build. -- 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/8538hp4gi9@boum.org
Bug#722130: [pkg-otr-team] gajim-plugin-otr
Hi, Dmitry Smirnov wrote (03 Apr 2014 20:41:07 GMT) : Very nice, thanks. I'd like to let you know about gajim-plugin-otr (RFP #722130) that I packaged some time ago. It is pretty much ready and only need someone to take ownership. I would personally be happy to see you upload the Gajim OTR plugin, and become the primary maintainer for it, under our team's umbrella. But maybe other team members will want to get more involved :) Now, I have a few questions: 1. The current state of upstream work on this plugin is a bit confusing. The homepage [1] says bugs live in Trac [2], while I've seen the author re-create on GitHub [3] a bug filed in Trac. Any idea where is the preferred place to forward Debian bugs? 2. Upstream wrote [4] I don't have a lot of time for gotr right now five months ago, and indeed, an important bug like the OTR logs conversations [5] one has seen no update since then. Are you confident such problems will be addressed in a timely manner by upstream, in the future? 3. I see you've called the source package gajim-plugins. If the idea is to potentially maintain a bunch of non-OTR Gajim plugins in the source package, then I doubt it's appropriate to put it under the OTR team's umbrella. So, perhaps a dedicated source package would be better. What do you think? [1] https://trac-plugins.gajim.org/wiki/OffTheRecordPlugin [2] https://trac-plugins.gajim.org/query?status=acceptedstatus=assignedstatus=newstatus=reopenedcomponent=OffTheRecordPlugin [3] https://github.com/afflux/gotr/issues [4] https://github.com/afflux/pure-python-otr/issues/45 [5] https://trac-plugins.gajim.org/ticket/69 Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/8561mpmgg8@boum.org
Bug#725309: RFP: teatimer - A tea brewing timer
Control: retitle -1 RFP: gnome-shell-extension-teatime - tea brewing timer extension for GNOME Shell Control: noowner -1 Hi, the initial RFP submitter is happy with gnome-shell-timer, so I won't package gnome-shell-extension-teatime. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/851tzcs633@boum.org
Bug#721845: ITP: flashproxy -- ephemeral browser-based pluggable transport for Tor
Hi, Ximin Luo wrote (18 Jan 2014 01:34:25 GMT) : https://mentors.debian.net/package/flashproxy Assuming all my previous concerns were deal with (which I believe is the case, unless something was dropped when replying), the package now seems to be in pretty good shape. If you need any further review or anything, feel free to ask :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85mwidzig8@boum.org
Bug#721845: ITP: flashproxy -- ephemeral browser-based pluggable transport for Tor
Hi, Ximin Luo wrote (18 Jan 2014 01:31:39 GMT) : [...] but overriding the first-person would require 5 override files. I think it's worth adding it. Adding the overrides allows you to start from a Lintian-clean state, and in the future, to easily notice oh, the package is not Lintian-clean anymore, what happened?, instead of getting used to ignoring Lintian warnings since, oh well, we already know there're here. Your call anyway. This is now in NEW: https://ftp-master.debian.org/new/node-ws_0.4.30-1.html Cool. Hopefully it will come out of NEW soon :) I've now verified everything with both piuparts and pbuilder and everything is OK. \o/ Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/851tzp1ung@boum.org
Bug#737045: ITP: htpdate -- HTTP based time synchronization tool
Hi, note that we at Tails (https://tails.boum.org/) have been maintaining our own version of the Perl version of htpdate for years, since upstream never replied any of our merge requests, so I'm not convinced at all that shipping the upstream code into Debian is a good an idea. Have you discussed with upstream about this? Do you know for a fact that they're still maintaining this piece of software? (Disclaimer: I've not checked if they have been releasing anything new recently.) FWIW, our code is there: http://git.tails.boum.org/htp/ Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85ppna65fx@boum.org
Bug#737045: ITP: htpdate -- HTTP based time synchronization tool
Hi, Eriberto wrote (29 Jan 2014 18:06:33 GMT) : The last version was released at 20-Sep-2013. Please, check this at http://www.vervest.org/htp/archive/c/ Fair enough. The Perl version (http://www.vervest.org/htp/archive/perl/) has seen no release since 2005, but I'm glad upstream is still somewhat active on the C version at least. Why you didn't package your version? I had no use for it outside of the threat model of Tails, and nobody ever asked for it. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/8561p2647j@boum.org
Bug#579605: TAG: sd4l -- On-The-Fly Encryption
Hi, Danny Piccirillo wrote (29 Apr 2010 02:11:40 GMT) : ScramDisk for Linux (SD4L) is a great OTFE alternative that also supports TrueCrypt containers. http://sd4l.sourceforge.net/ The last upstream release was published in 2011. Besides, cryptsetup now supports the TrueCrypt on-disk format, so perhaps a better course of action would be to use this from the desktop GUI's, which probably starts with adding such support to udisks: https://bugs.freedesktop.org/show_bug.cgi?id=70164 Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85ha9asjxv@boum.org
Bug#721845: ITP: flashproxy -- ephemeral browser-based pluggable transport for Tor
Hi, Ximin Luo wrote (07 Jan 2014 17:08:33 GMT) : Thanks for the review! Thank you for packaging flashproxy! Great that you added DEP-3 headers. I'm not sure if the This patch header follows DEP-3 notice is useful, though. On 18/12/13 21:42, intrigeri wrote: 3. Please make the package Lintian -clean, if possible in pedantic mode, e.g. like this: lintian --info --display-info --pedantic --color auto *.changes Lintian has good advices for you, e.g. using DEP-3 for the Debian-specific patch to indicate it should not be forwarded upstream :) Fixed - Great! The only two left IMO are false positives: - debian-watch-file-is-missing: currently N/A, upstream does not release the tarballs separately outside of git tags. I work closely enough with upstream that it's not so important anyways. - using-first-person-in-description: does not exactly apply, we used here is descriptive and neutral rather than instructive. Fair enough. Please add overrides that explain this as a comment, then. 11. I find it a bit scary not to install the upstream LICENSE file, and to rely on Debian's copyright instead. As soon at the Debian packaging misses an upstream update (and they are *already* in mismatch, actually), then we're violating the upstream license. I recommend installing the upstream LICENSE file. Unfortunately that results in a lintian warning: http://lintian.debian.org/tags/extra-license-file.html I've fixed LICENSE in a patch anyways, which has also been applied upstream. OK. I've just learnt something, actually. Thanks :) 5. We don't ship software in Debian that has dependencies outside Debian to be useful at all. So, in the current state of things, the node-flashproxy binary package (and its README.Debian) is a no-no. Time to ping Mike Gabriel on #721558 (and offer your help if you wish), perhaps. 12. I have not tested the resulting binary packages with piuparts. I suggest you do it if you can afford it: discovering issues before the QA team knocks at the door is nicer both for them, and for you :) I'll deal with these last two points and follow-up to this email. Cool. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85bnzn3d51@boum.org
Bug#733860: ITP: pond -- Forward secure, asynchronous messaging for the discerning.
Hi, Kartik Mistry wrote (03 Jan 2014 04:45:02 GMT) : Suitable for experimental for sure. I'll be happy to help in packaging if needed. Great, three candidate packagers for a single ITP :) I'm re-adding the ITP bug to the Cc list. Please keep it copied so that the discussion is archived there. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85lhyx63ky@boum.org
Bug#721845: ITP: flashproxy -- ephemeral browser-based pluggable transport for Tor
Hi,
here's a quick initial review of the 1.5-1 packaging. Note that I've
not looked at the upstream code, assuming some people better skilled
than me in this area, in the Tor Project, have done this already.
If this is not the case, please tell me.
First of all, if this is your first serious packaging task, this is
a high-quality result, and I'm impressed.
1. debian/copyright gives copyright 2011-2013 to David Fifield, while
the upstream source only mentions 2012. The correct place to fix
upstream copyright information, if that was the intent, is upstream
sources: we're merely relaying it in debian/copyright.
2. Please upgrade to the latest available standards-version.
3. Please make the package Lintian -clean, if possible in pedantic
mode, e.g. like this:
lintian --info --display-info --pedantic --color auto *.changes
Lintian has good advices for you, e.g. using DEP-3 for the
Debian-specific patch to indicate it should not be forwarded
upstream :)
4. Is the flashproxy-facilitator's dependency on python really needed?
I have nearly no experience in Python software packaging, but isn't
the role of ${python:Depends} to do just that?
5. We don't ship software in Debian that has dependencies outside
Debian to be useful at all. So, in the current state of things, the
node-flashproxy binary package (and its README.Debian) is a no-no.
Time to ping Mike Gabriel on #721558 (and offer your help if you
wish), perhaps.
6. A the facilitator's postinst depends on /usr/share/doc to be
available. This is a violation of Policy 12.3: Packages must not
require the existence of any files in /usr/share/doc/ in order to
function. These files must be moved to /usr/share/$PACKAGE and may
be symlinked from /usr/share/doc/$PACKAGE.
7. In the facilator's postinst, instead of install + cat, you could
just use install to copy reg-email.pass where it belongs.
8. Why install symlinks in the facilitator's postinst, instead of ship
them in the package (e.g. with dh_link(1))? This would avoid the
need to remove them in postrm (and having to handle the case when
the administrator changed these files).
9. This comment leaves me thinking:
# NOTE: debian/rules build (which runs tests) must be run outside of
fakeroot
# since the tests open sockets, which fakeroot stubs out.
It could be worth supporting fakeroot environments, no?
Can't you detect fakeroot and (loudly) skip tests if applicable?
10. What does this mean, exactly?
# TODO(infinity0): handle setup.py better
Any potential issue you foresee?
11. I find it a bit scary not to install the upstream LICENSE file,
and to rely on Debian's copyright instead. As soon at the Debian
packaging misses an upstream update (and they are *already* in
mismatch, actually), then we're violating the upstream license.
I recommend installing the upstream LICENSE file.
12. I have not tested the resulting binary packages with piuparts.
I suggest you do it if you can afford it: discovering issues
before the QA team knocks at the door is nicer both for them, and
for you :)
Great work!
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
--
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/85eh59g7ja@boum.org
Bug#721845: ITP: flashproxy -- ephemeral browser-based pluggable transport for Tor
Hi, Ximin Luo wrote (12 Dec 2013 13:12:07 GMT) : The commits are now here: https://gitweb.torproject.org/debian/flashproxy.git $ git clone https://gitweb.torproject.org/debian/flashproxy.git git Cloning into 'git'... fatal: https://gitweb.torproject.org/debian/flashproxy.git/info/refs not valid: is this a git repository? zsh: exit 128 git clone https://gitweb.torproject.org/debian/flashproxy.git git ? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85eh5iurmt@boum.org
Bug#721845: ITP: flashproxy -- ephemeral browser-based pluggable transport for Tor
Ximin Luo wrote (12 Dec 2013 13:50:39 GMT) : https://git.torproject.org/flashproxy.git Thanks, I can clone from there... but I can find no debian/ directory in there. Where does the packaging bits live? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/857gbataes@boum.org
Bug#721845: ITP: flashproxy -- ephemeral browser-based pluggable transport for Tor
Ximin Luo wrote (12 Dec 2013 14:25:19 GMT) : Sorry, I meant this one: https://git.torproject.org/debian/flashproxy.git OK, now I only need to fine time to review this :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85vbyurvfw@boum.org
Bug#730439: ITP: ori -- a secure distributed file system
Hi, Description : a secure distributed file system I find it always scary to see people advertise some software as secure, especially without specifying what threat model it is about. Security is not a boolean, and something that's secure in a given threat model may be totally unsafe in another one. Perhaps the package description could be a bit more humble on this side, and instead of secure, express in a few words the kind of security that is offered? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85wqjwlt7c@boum.org
Bug#728669: ITP: goldbug -- secure fully decentralized instant messaging, chat and email client
Richard Sellam wrote (03 Nov 2013 23:56:41 GMT) : Description : secure fully decentralized instant messaging, chat and email client I'm warry of including secure in the package description. Without a detailed threat model, this word can create false impressions of security. -- 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/8561s81o1c@boum.org
Bug#728458: ITP: libmoox-late-perl -- easily translate Moose code to Moo
Package: wnpp Owner: intrigeri intrig...@debian.org Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org * Package name: libmoox-late-perl Version : 0.014 Upstream Author : Toby Inkster toby...@cpan.org * URL : https://metacpan.org/release/MooX-late * License : Artistic or GPL-1+ Programming Lang: Perl Description : easily translate Moose code to Moo Moo is a light-weight object oriented programming framework which aims to be partly compatible with Moose. However, the surface syntax of Moo differs somewhat from Moose. MooX::late provides some assistance by enabling a slightly more Moosey surface syntax. MooX::late makes it easier: - to port code that was initially written for Moose to Moo - to write Moo code that can later be converted to use the full Moose feature-set if needed. -- 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/85fvrgw51x@boum.org
Bug#728466: ITP: libtypes-path-tiny-perl -- Path::Tiny types and coercions for Moose and Moo
Package: wnpp Owner: intrigeri intrig...@debian.org Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org * Package name: libtypes-path-tiny-perl Version : 0.005 Upstream Author : David Golden dagol...@cpan.org * URL : https://metacpan.org/release/Types-Path-Tiny * License : Apache-2.0 Programming Lang: Perl Description : Path::Tiny types and coercions for Moose and Moo Types::Path::Tiny provides types and coercions useful for dealing with Path::Tiny objects as Moose or Moo attributes. It handles two important types of coercion: - coercing objects with overloaded stringification; - coercing to absolute paths. It also can check to ensure that files or directories exist. -- 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/85vc0cunfg@boum.org
Bug#728466: ITP: libtypes-path-tiny-perl -- Path::Tiny types and coercions for Moose and Moo
gregor herrmann wrote (01 Nov 2013 16:19:52 GMT) : Already in NEW (and in our repos); ITP is #726026. Thanks, and sorry for the noise. -- 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/854n7wulvg@boum.org
Bug#725309: RFP: teatimer - A tea brewing timer
Hi, Emilio Pozuelo Monfort wrote (26 Oct 2013 15:02:06 GMT) : I'd like to team-maintain this package under the GNOME team umbrella. Thoughts about this? I feel like we already have too many non-core packages that somebody packaged and eventually lost interest or just went MIA. I've been trying to reduce that and make things go the opposite way, so I don't like this, sorry. Fair enough, understood. Here's my plan, then: I'll maintain this extension on my own for a while, and if it proves to be well-maintained enough upstream and still seems to be a worthwhile addition to Debian, and once my record suggests I'm not going MIA, then I might propose team-maintenance again, and we'll see (if you're curious, see e.g. the GTK / GObject Introspection / etc. Perl bindings, that I'm maintaining as part of the Perl team, for an example of how I've been handling team-maintenance of packages that I'm primarily interested in). As a side note, my (limited) experience in the Debian Perl team is that most new members join us to maintain a new package or a few. Certainly, quite a few of them go MIA after a while, but that's also our main way to get new contributors, and some of them eventually get more involved in the team. I'm not saying *I* specifically was intending to become strongly invested in the GNOME team (ENOTIME), just sharing my experience that sometimes, when the team can handle it (I know that may be a hard pre-requisite), it's worth it to allow people to potentially add to the collective plate (if they disappear), if it brings a few active team members in. Anyway, thanks a lot for your work on GNOME in Debian! Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85iowjr25b@boum.org
Bug#725309: RFP: teatimer - A tea brewing timer
Hi, * Package name: gnome-shell-extension-teatime Version : 0~20131022.git6cac4a1 Upstream Author : Olaf Leidinger ol...@mescharet.de * URL or Web page : https://github.com/oleid/gnome-shell-teatime.git * License : MIT Description : tea brewing timer extension for GNOME Shell gnome-shell-extension-teatime is an extension for helping in brewing tea in GNOME Shell, featuring support for various configurable timers. I'd like to team-maintain this package under the GNOME team umbrella. Thoughts about this? Initial packaging: git://gaffer.ptitcanardnoir.org/gnome-shell-extension-teatime.git I also have a few minor bugfixes I'd like to see upstream merge before uploading this extension to Debian. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85wql5uykr@boum.org
Bug#725106: ITP: libdist-zilla-plugin-installguide-perl -- Dist::Zilla plugin to generate installation instructions
Package: wnpp Owner: intrigeri intrig...@debian.org Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org * Package name: libdist-zilla-plugin-installguide-perl Version : 1.21 Upstream Author : Marcel Grünauer mar...@cpan.org, Mike Doherty dohe...@cpan.org * URL : https://metacpan.org/release/Dist-Zilla-Plugin-InstallGuide * License : Artistic or GPL-1+ Programming Lang: Perl Description : Dist::Zilla plugin to generate installation instructions This plugin adds a very simple INSTALL file to the distribution, telling the user how to install this distribution. This plugin can be used in a Dist::Zilla configuration after [MakeMaker] or [ModuleBuild] so that it can determine what kind of distribution one is building, and which installation instructions are appropriate. -- 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/85eh85do9o@boum.org
Bug#725109: ITP: libdist-zilla-plugin-test-perl-critic-perl -- Dist::Zilla plugin to check your code with perlcritic
Package: wnpp Owner: intrigeri intrig...@debian.org Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org * Package name: libdist-zilla-plugin-test-perl-critic-perl Version : 2.112410 Upstream Author : Jerome Quelin * URL : https://metacpan.org/release/Dist-Zilla-Plugin-Test-Perl-Critic * License : Artistic or GPL-1+ Programming Lang: Perl Description : Dist::Zilla plugin to check your code with perlcritic The Dist::Zilla::Plugin::Test::Perl::Critic plugin adds a t/author/critic.t test file. It checks your code against best practices, using perlcritic. A custom perlcritic.rc may be provided. -- 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/8561thdmp3@boum.org
Bug#725112: ITP: libdist-zilla-plugin-test-notabs-perl -- Dist::Zilla plugin to make sure hard tabs are not used
Package: wnpp Owner: intrigeri intrig...@debian.org Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org * Package name: libdist-zilla-plugin-test-notabs-perl Version : 0.04 Upstream Author : Florian Ragwitz r...@debian.org * URL : https://metacpan.org/release/Dist-Zilla-Plugin-Test-NoTabs * License : Artistic or GPL-1+ Programming Lang: Perl Description : Dist::Zilla plugin to make sure hard tabs are not used The Dist::Zilla::Plugin::Test::NoTabs plugin runs at the gather files stage. It provides the file xt/release/no-tabs.t, a standard Test::NoTabs test. If needed, custom module and file finders may be provided by the user. -- 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/85txh1aqpn@boum.org
Bug#721845: ITP: flashproxy -- ephemeral browser-based pluggable transport for Tor
Ximin Luo wrote (04 Sep 2013 14:44:28 GMT) : Package: wnpp Severity: wishlist Owner: Ximin Luo infini...@gmx.com * Package name: flashproxy Version : 1.2 Upstream Author : David Fifield da...@bamsoftware.com I'm glad flashproxy is making its way into Debian! Thanks :) Cheers! -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85bo487hka@boum.org
Bug#719297: RFP: ruby-packetfu -- PacketFu is a mid-level packet manipulation library for Ruby
Jérémy Bobbio wrote (24 Aug 2013 16:10:59 GMT) : I'm on it. :) Awesome, thanks! Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85sixzau0o@boum.org
Bug#719297: RFP: ruby-packetfu -- PacketFu is a mid-level packet manipulation library for Ruby
Package: wnpp Severity: wishlist X-Debbugs-Cc: pkg-ruby-extras-maintain...@lists.alioth.debian.org, tails-...@boum.org * Package name: ruby-packetfu Version : 1.1.8 Upstream Author : Tod Beardsley * URL or Web page : https://github.com/todb/packetfu https://rubygems.org/gems/packetfu * License : BSD Description : PacketFu is a mid-level packet manipulation library for Ruby We at Tails [1] are using packetfu as part of our Cucumber-powered test suite. Teaser: you can help anonymity online today -- maintain packetfu in Debian, and help us automatically ensure that Tails does not leak any non-Tor connection :) [1] https://tails.boum.org/ Cheers, -- intrigeri -- 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/85txixu4wv@boum.org
Bug#719301: RFP: rjb -- RJB is a Ruby Java Bridge
Package: wnpp Severity: wishlist X-Debbugs-Cc: pkg-ruby-extras-maintain...@lists.alioth.debian.org, tails-...@boum.org * Package name: rjb Version : 1.4.5 Upstream Author : arton Tajima * URL or Web page : http://rjb.rubyforge.org/ * License : LGPL Description : RJB is a Ruby Java Bridge We at Tails [1] have been porting the Sikuli gem to use RJB instead of JRuby, as the latter is becoming totally unmaintainable for us. Teaser: help us streamline the Tails dev / test / release process, so that we spend less time preparing releases (every 6 weeks!), and have more time to develop useful features :) [1] https://tails.boum.org/ Cheers, -- intrigeri -- 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/85y589soan@boum.org
Bug#627362: jitsi: block ITP 627362 by RFS 695588
Hi, Bart Martens wrote (11 Dec 2012 04:20:26 GMT) : block 627362 by 695588 It seems that Jitsi was accepted, but not yet installed into the pool yet. Not being very familiar with the ftp-masters process, is it now only a matter of waiting a day or three, or is there anything else blocking Jitsi from entering the archive? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85mworckuy@boum.org
Bug#687966: RFP: askbot -- open source QA system, like StackOverflow, Yahoo Answers and some others
Hi, for the record: * Tails is also interested in this. * the Tor project has tried running this on Debian and listed missing dependencies: https://trac.torproject.org/projects/tor/ticket/5995#comment:31 Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/854nbpa8d9@boum.org
Bug#699107: ITP: TorBirdy -- configures Mozilla birds for use with Tor
Hi, Jérémy Bobbio wrote (03 Feb 2013 19:56:23 GMT) : Is there any reasons to keep this package out of the Debian Mozilla Extension team [1]? It usualy makes it easier when changes are required in all Mozilla extensions at once. As explained on IRC a while ago, I do concur. Anyhow, any news on this ITP? Suggestions (as of 264a0a24): * please set Vcs-Git and Vcs-Browser in debian/control * you'll want to bump years in debian/copyright at some point Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85bo9r7r2t@boum.org
Bug#695765: ITP: fsniper -- daemon to run scripts based on changes in files monitored by inotify
Arno Töll wrote (12 Dec 2012 13:19:14 GMT) : How is this better/different to incron(d) [1]? We also have inoticoming to deal with the simplest case. -- 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/85r4mv4bav@boum.org
Bug#694278: ITP: gpg-remailer -- GnuPG-enabled remailer for mailing lists
Hi, tony mancill wrote (24 Nov 2012 23:39:46 GMT) : * Package name: gpg-remailer [...] Description : GnuPG-enabled remailer for mailing lists Just curious: what are the gpg-remailer advantages over schleuder[1]? [1] http://packages.qa.debian.org/s/schleuder.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/858v9q1pnp@boum.org
Bug#690850: ITP: libdist-zilla-localetextdomain-perl -- Dist::Zilla plugin that adds support for managing l10n and i18n in Perl modules
Hi, Joenio Costa wrote (18 Oct 2012 14:29:22 GMT) : Owner: Joenio Costa joe...@colivre.coop.br * Package name: libdist-zilla-localetextdomain-perl I'm happy someone wants to maintain Dist::Zilla::LocaleTextDomain! Did you consider maintaining this package under the Debian Perl Group umbrella? Cheers! -- 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/858vb2vkbr@boum.org
Bug#690850: ITP: libdist-zilla-localetextdomain-perl -- Dist::Zilla plugin that adds support for managing l10n and i18n in Perl modules
Joenio Costa wrote (19 Oct 2012 18:31:46 GMT) : Did you consider maintaining this package under the Debian Perl Group umbrella? Sure! I'm getting help of gregor from Debian Perl Group. Nice to hear :) -- 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/85pq4etgd3@boum.org
Bug#689563: O: pdnsd -- Proxy DNS Server
Hi, I don't intend to adopt pdnsd myself, but I have made some bug triaging to make it clearer, to the potential adopter, where to start from. Basically, there are: * one packaging RC bug (#689537) that should be pretty trivial to fix (beware not to re-introduce #617913 in the process) * two important bugs that are waiting for feedback from the reporters * a handful of (mostly oldish) upstream bugs of normal severity, that should be fixed some day, but don't prevent most pdnsd users from being happy with it * a bunch of minor / wishlist requests Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85vcepyy5x@boum.org
Bug#662736: ITP: maxwell -- entropy-gathering daemon
Hi Pedro, Pedro I. Sanchez wrote (18 Jul 2012 03:01:19 GMT) : * Package name : maxwell [...] * Description : entropy-gathering daemon [...] There are a number of other ways to feed entropy to random (4). Yes, and as you for sure know, a few are in Debian already. The advantage of maxwell is that it is small, simple and only minimally hardware-dependent. The other methods also have advantages, and in many cases one of them will be preferable to this one. I would be delighted to be pointed to a place when these many cases, and reasons why/when other methods are preferable, are discussed in a bit more details :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85394pi6mk@boum.org
Bug#679470: ITP: libarchive-tar-wrapper-perl -- API wrapper around the 'tar' utility
Package: wnpp Owner: intrigeri intrig...@debian.org Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org * Package name: libarchive-tar-wrapper-perl Version : 0.16 Upstream Author : Mike Schilli c...@perlmeister.com * URL : http://search.cpan.org/dist/Archive-Tar-Wrapper/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : API wrapper around the 'tar' utility Archive::Tar::Wrapper is an API wrapper around the 'tar' command line utility. It never stores anything in memory, but works on temporary directory structures on disk instead. It provides a mapping between the logical paths in the tarball and the 'real' files in the temporary directory on disk. Contrary to Archive::Tar, this module allows to manipulate big archives in relatively tight memory conditions, as long as there is enough space on disk to hold temporary files. -- 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/85lij76omb@boum.org
Bug#678856: ITP: libsocket-perl -- networking constants and support functions
Package: wnpp Owner: intrigeri intrig...@debian.org Severity: wishlist X-Debbugs-CC: debian-p...@lists.debian.org * Package name: libsocket-perl Version : 2.002 Upstream Author : Larry Wall and others * URL : http://search.cpan.org/dist/Socket/ * License : GPL-1+ or Artistic Programming Lang: Perl Description : networking constants and support functions Socket provides a variety of constants, structure manipulators and other functions related to socket-based networking. The values and functions provided are useful when used in conjunction with Perl core functions such as socket(), setsockopt() and bind(). It also provides several other support functions, mostly for dealing with conversions of network addresses between human-readable and native binary forms, and for hostname resolver operations. Rationale: updating libio-socket-ip-perl and libio-async-perl to their last upstream version require an updated version of this now dual-life module. -- 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/851ul4r2bm@boum.org
Bug#642934: [PATCH] Add GnuTLS support to Aircrack-ng
Carlos Alberto Lopez Perez wrote (10 Jun 2012 22:48:00 GMT) : After a quick chat with Thomas on the IRC, he told me he is fine with Debian including this GnuTLS patch for aircrack-ng. this is good news. I will be publishing the package to debian mentors this week (ASAP). I will need a sponsor for the package. please keep me in the loop. -- 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/85ipeysida@boum.org
Bug#642934: [PATCH] Add GnuTLS support to Aircrack-ng
Hi, Thomas d'Otreppe wrote (08 Jun 2012 13:43:28 GMT) : Not yet as I'm solving another problem: http://aircrack-ng.blogspot.com/2012/05/forum-virus-details.html Good luck with that! I just need to test it but it looks good so I don't think it will need any modifications. As soon as trac/svn is up, I'll take care of this. Thanks for answering. Any kind of ETA? (Debian Wheezy should be frozen in the second part of June, so I'm trying to see what's blocking the inclusion of aircrack-ng in there. It'd be very sad to see Wheezy released without aircrack-ng, after all the awesome work that was put in it by you and others.) -- 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/85vcj17oe1@boum.org
Bug#642934: [PATCH] Add GnuTLS support to Aircrack-ng
Hi, Carlos Alberto Lopez Perez wrote (01 May 2012 05:07:45 GMT) : I have translated the OpenSSL functions used on Aircrack-ng to the GnuTLS counterparts. [...] I am attaching here the patch (is on top of r2153) Did anything happen on this front since then? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85d35abmtk@boum.org
Bug#642934: sponsorship for aircrack-ng
Hi, David Francos wrote (01 May 2012 12:15:15 GMT) : Thank you, I'll fix this as soon as possible, I've been forced to leave all this behind for a while, hope to be able to catch with it soon. Any chance you, or Carlos (who still owns the ITP bug) or anyone else fixes this in time for the Wheezy freeze? About the licensing, there seems to be still an issue, hope it gets resolved soon enough. To clarify, is this issue the one with the OpenSSL that Carlos raised in message #132? Given there's a patch that was apparently well tested, perhaps the patch could be applied to the Debian package, and this should not be blocking the upload to Debian? (Perhaps I missed something, merely trying to see what's *really* blocking on this front.) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/857gvibmhh@boum.org
Bug#675467: ITP: bilibop -- run Debian from external media
Hi, quid...@poivron.org wrote (04 Jun 2012 13:16:52 GMT) : This means such functions are unusable if you run Tails entirely into RAM (I believe with the 'toram' boot parameter, or something like that). In this mode, we don't need to arm the emergency shutdown watchdog, so we don't need to determine the underlying physical device, so we don't need bilibop. Bilibop might be useful in every other case. So, find the drive hosting the running system and protect it from user mistakes is what I call 'fix a security issue' or 'make the system more robust'. Sure. I can't wait using it in Tails. Are there any difficulties you think we may encounter in the process? I have tried today with the last release of Tails. It works fine but needs to modify two lines in the bilibop-common functions. Great. So the hard part will rather be to integrate this with existing, working features that *need* to modify the devices Tails runs from (such as: setup a persistence volume). But commands provided by bilibop-common (drivemap) and bilibop-rules (lsbilibop) work partially. This is due to important changes in base-files and udev packages. drivemap and lsbilibop could be easily backported to Squeeze but in the other hand I think they are not so important in the Tails context. Say me what you think about. My take on it is don't bother with these :) For Tails context/design, you should see in /usr/share/doc/bilibop-rules/examples/90-internal-drives.rules the rules titled A or C (forbid access to internal drives, even by root). Thank you. But what seems so good for me, maybe is not so good for the community? I've sent my comments, with my potential sponsor hat on, to the RFS bug. -- 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/85mx4ge8y0@boum.org
Bug#657076: Updating and maintaining barry in Debian / Ubuntu
Upstream tag: barry-0.18.3-2 Upstream diff: git log -p barry-0.18.3..barry-0.18.3-2 Release URL: http://sourceforge.net/projects/barry/files/barry/barry-0.18.3/sources/debian/barry_0.18.3-2.dsc Uploaded to sid, thanks! -- 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/85mx4ikspg@boum.org
Bug#675927: ITP: libmoosex-has-options-perl -- Succinct options for Moose
hi! matanya wrote (04 Jun 2012 02:10:41 GMT) : * Package name: libmoosex-has-options-perl do you want to maintain this package as part of the Debian Perl team? -- 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/85aa0jm1x7@boum.org
Bug#675467: ITP: bilibop -- run Debian from external media
Hi, quid...@poivron.org wrote (02 Jun 2012 13:05:42 GMT) : bilibop-common: shell functions to find the drive hosting the root filesystem (dm-crypt, LVM, loop devices, aufs and any combination of them are supported) This might be useful for Tails' implementation of wipe memory on shutdown. I have Tails installed on a USB key; the wipe memory on shutdown seems to work well, without need of bilibop-common or whatever. Nice to hear. However, we're generally happy to replace custom code with some generic code maintained by others than us, who seem to be experts in the specific area this code is about -- especially when our own quick hack quickly shows its limits in unusual installations of Tails. We try to cap our instance of the NIH syndrom to the bare minimum. bilibop-rules: udev rules to fix the removable drive hosting the running system, and all its partitions, as members of the 'disk' group I fail to understand how a drive can be a member of the 'disk' group. Please enlighten me. (Being offline, I can't read the mentionned bug right now, but still, the package description should make sense by itself, without needing to access online resources.) Boot on Debian, plug a USB/FireWire drive (key or HDD) on, and execute 'ls -l /dev/sd*': You should see /dev/sda and its partitions as members of the 'disk' group (and maybe also /dev/sdb* if there is a second internal HDD). Ah, you mean *owned* by the disk vs. floppy group. Now (and now that I've read the referenced bug) it's perfectly clear :) I don't think it's correct and clear to tell a drive is a member of a group. (fixes bug #645466). I think s/fixes/is a way to workaround/ would be more correct. Unfortunately, #645466 is likely to remain unfixed even once bilibop is in Debian :( For example, you told me about Tails. So, boot on it (the LiveUSB, of course) find the drive which your system is running from (here, we say /dev/sdb), and, as the normal user, just type 'shred -vzn0 /dev/sdb'. Now your 'secured' system is lost. Right. I'm glad we've learnt of this security issue. Thank you. I've added it to our bug tracker: https://tails.boum.org/bugs/writable_system_disk:_belongs_to_floppy_group/ Do you want to be credited for this discovery? (even if, formally speaking, you did not report it to us: had I not read debian-devel, I would probably not have learnt about it that soon, would I?) So, find the drive hosting the running system and protect it from user mistakes is what I call 'fix a security issue' or 'make the system more robust'. Sure. I can't wait using it in Tails. Are there any difficulties you think we may encounter in the process? Please note that I did not mean to suggest bilibop does not fix security issues or does not makes a system more robust: I was merely pointing out that 1. the description was not explaining why and how clearly enough to my taste; 2. I was interested and I wanted to know more. Your reply looks like a good source of inspiration to make the package description more thorough and precise. Other optional features for the desktop environment (based on Udisks). Such as? By setting: [...] As said above, this is optional, and only for convenience: hide partitions, or show them with icons and/or names different than the defaults, or make the user able or not to mount them from the filemanager with or without su/sudo password. As said in the documentation of the package, all this can be bypassed with pmount(1). This is not a security layer. Looks like this could be useful for Tails persistence feature :) You can download the source with: dget -x http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.1.dsc I'll have a look, hopefully in a few days. Don't hesitate pinging me in two weeks if needed. I have send a RFS: #675532 I'll consider sponsoring this package. I expect my decision to be mostly a function of whether there is some bilibop feature we can use as is in Tails. How much do you care about seeing bilibop shipped in Wheezy? (I presume not much, else you would have posted this ITP quite sooner, but who knows, I myself have not uploaded yet all new packages I want to see in Wheezy -- the difference being I won't have to argue with myself about packaging style and tools ;) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85txytqq14@boum.org
