Bug#986152: Offer of help
On Sat, Jan 21, 2023 at 09:58:13AM +0100, Romain Francoise wrote: > On Fri, Jan 20, 2023 at 11:59:44AM +, Jeremy Sowden wrote: > > The Developer's Reference, § 5.6.1, expresses the preference that when > > new binary packages are added to a source package, it should be > > uploaded to experimental, so I've updated the version and distribution > > in the change-log entry accordingly. > > But these are not *new* binary packages, so I don't think the upload > will go through NEW. In fact, I hope it won't because there's still the > freeze to consider and I'd really like the new package to be in > bookworm. Sort of. Whenever a source package produces a new binary package, whether that package exists in the archive already or not, it will land in NEW. For instance, this happens with libraries that bump SONAME and start shipping a new binary package as a result. Consider the source package foo which produces (among others) libfoo1. If the SONAME is bumped to 2 causing libfoo2 to be emitted by the foo source package instead of libfoo1, then that upload will land in NEW. The FTP masters take notice and this particular case is usually handled very quickly (since they don't have to do all the normal checks of a brand new source package), but they still have to check that the new binary package being created by the source package in question doesn't conflict with a binary package from another source package. Imagine an entirely different source package, foo2, that already produced the binary package libfoo2. Allowing an unchecked upload of foo to add the libfoo2 binary package to the archive when foo2 is already producing a libfoo2 package would be a Bad Thing(TM). This is where appropriate use of things like Breaks/Replaces/Conflicts can help streamline the process. Regards, -Roberto -- Roberto C. Sánchez
Bug#986152: Offer of help
On Fri, Jan 20, 2023 at 09:46:35PM +, Jeremy Sowden wrote: > On 2023-01-19, at 22:56:39 +0100, Romain Francoise wrote: > > On Thu, Jan 19, 2023 at 7:01 PM Jeremy Sowden wrote: > > > I've pushed all the work to my repo on Salsa: > > > > > > https://salsa.debian.org/azazel/shorewall > > > > > > Do you want to review it before I push to the shorewall-team repo? > > > > It all looks pretty good to me! In fact, it's a radical improvement > > over the previous packaging with seven source packages. > > > > [...] > > > > I have not yet actually tested the packages in my lab but please feel > > free to push your changes to the team repo, and I will do the final > > testing and upload over the week-end. I can also take care of opening > > the bugs to have the previous source packages removed from unstable. > > I was wondering about this shorewall-doc bug: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=266957 > > Once 5.2.8 is uploaded there won't be a shorewall-doc source package. > Shall I reassign it to shorewall? > > J. That's a good question. I think that the bug is actually assigned to the shorewall-doc binary package, not the shorewall-doc source package. Assuming that the shorewall source package will start to emit a shorewall-doc binary package, I think that the BTS will do the right thing and leaving the bug assigned to shorewall-doc is correct. In that case, the source package association of shorewall-doc will change, but its bugs will still belong to shorewall-doc (the binary package). If you think about it, this must be the case, as closed and archived bugs would end up being orphaned otherwise. Regards, -Roberto -- Roberto C. Sánchez
Bug#986152: Offer of help
On Sat, Jan 07, 2023 at 12:48:08PM +0100, Romain Francoise wrote: > On Tue, Jan 3, 2023 at 11:54 PM Jeremy Sowden wrote: > > I've imported my fork of Roberto's SF repo to Salsa: > > > > https://salsa.debian.org/azazel/shorewall > > > > I haven't touched it in 18 months, so I'll give it a polish when I have > > some time, and perhaps we can use it as a starting point. > > Thanks. I created a Salsa team and repo here: > https://salsa.debian.org/shorewall-team/shorewall and added you both > as co-owners. > > I felt more comfortable using Roberto's original SF repo as a starting > point, and merging in your changes after review. I can do that in the > next few days, the freeze is coming up very soon and I would like to > have the new upstream in bookworm. If you have further changes please > push them to your repo. > > I'll also configure the CI on Salsa to have all the usual QA tools run > automatically on each push. > > Did you find a practical way to do changes across all seven source > packages at once? For a bit of historical context, the current multi-branch structure from the SF repo is quite antiquiated. It is from a time before debhelper supported multiple .orig.tar.gz components. It might make sense to consider starting with a new repo, with a more sensible branch structure (one that works more easily with tools like gbp), and that makes use of the multi-tarball capabilities so that you have have all the source packages in view at the same time. Regards, -Roberto -- Roberto C. Sánchez
Bug#986152: Offer of help
On Mon, Jan 02, 2023 at 06:08:57PM +0100, Romain Francoise wrote: > Hi, > > [Cc'ing Roberto directly to make sure he's aware of this discussion.] > Thanks for that. I'm not sure I would have seen it otherwise. > I'm also a Shorewall[6] user and while the state of the package isn't > really alarming right now, I need it to be properly maintained going > forward. > My needs have been evolving the last few years and I have much less of a need for a tool like Shorewall these days. Additionally, I have never used some of the advanced features (e.g., Multi-ISP, tc, accounting, etc.). It would be good to have others involved in maintenance who are able to contribute in that way. > We could set up a pkg-shorewall team on Salsa and co-maintain the > packages there. Jeremy, would that work for you? > I see that the group has already been created and that I was added. At the moment I am not able to jump in to aid with the transition. I hope to clear some major items from my queue in the coming weeks and until then I will do what I can. I'd like to mention that there is already a Gitlab group for upstream Shorewall work (which has been essentially dormant for some time): https://gitlab.com/shorewall It might make sense to consider if there is any overlap and if any of the Salsa work might be better house under the Shorewall Gitlab group. I'll try to jump in a bit more helpfully next week. Regards, -Roberto -- Roberto C. Sánchez
Bug#883932: Source for sword-comm-mhc
On Tue, Nov 24, 2020 at 10:33:47AM -0500, Roberto C. Sánchez wrote: > > But the Salsa project page says the repository is empty. I will push > the code I have shortly. > I have pushed everything to the Salsa repository, including all branches (master, upstream, pristine-tar) and tags. Regards, -Roberto -- Roberto C. Sánchez
Bug#883932: Source for sword-comm-mhc
On Tue, Nov 24, 2020 at 03:41:40PM +0100, Bastian Germann wrote:
> sword-comm-mhc should be developed at
> https://salsa.debian.org/pkg-crosswire-team/sword-comm-mhc
>
That's strange, since according to the working copy on my machine, the
sources are already there:
roberto@miami:~/src/debian/sword-comm-mhc.git (master=)$ git remote -v
origin g...@salsa.debian.org:pkg-crosswire-team/sword-comm-mhc.git (fetch)
origin g...@salsa.debian.org:pkg-crosswire-team/sword-comm-mhc.git (push)
But the Salsa project page says the repository is empty. I will push
the code I have shortly.
> The work can be found at https://ccel.org/ccel/henry.
>
> ThML sources are at https://ccel.org/ccel/henry/mhc{,1,2,3,4,5,6}.xml
Regards,
-Roberto
--
Roberto C. Sánchez
Bug#914573: ITP: mongo-cxx-driver -- MongoDB C++ client library
I am still waiting. However, there are many packages still waiting in NEW, some for nearly one year, so I am not sure when mongo-cxx-driver might be approved. Regards, -Roberto On Sun, Oct 27, 2019 at 08:04:26PM +0100, Christophe CT. TROPHIME wrote: > Any news for this package? > > It seems to be in NEW but cannot find it elsewhere > > https://ftp-master.debian.org/new/mongo-cxx-driver_3.4.0-1.html > > Best. > C -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
Bug#903815: Bug#903880: Bug#903815: ITP: pw -- A simple command-line password manager
On Mon, Jul 16, 2018 at 02:36:17PM +0200, Dashamir Hoxha wrote: >On Mon, Jul 16, 2018 at 2:21 PM Holger Levsen <[1]hol...@layer-acht.org> >wrote: > > On Sun, Jul 15, 2018 at 12:41:36PM +0200, Carsten Schoenert wrote: > > Hmm, do you have tried to validate your shell code? > > [2]https://www.shellcheck.net/ > > I just pasted > > [3]https://raw.githubusercontent.com/dashohoxha/pw/master/src/pw.sh > into > > and got quite a lot of problematic remarks. > > I've also done this now and must say/add "ouch": > >I have already answered this. Only one of the suggestions might be useful. >If everything was clean, according to shellcheck, this wouldn't mean at >all >that the program is safe and secure and takes care of all the cases. >I know what is going on in my program better than the mindless shellcheck. > I've been following this thread and it is very difficult for me to understand why constructive criticism from others is so difficult for you to accept. In general, the community of Debian Developers is very concerned with producing a high quality distribution and also with supporting free software development. The fact that some have taken the time and interest to critique your work is very positive. Yet, you choose to perceive their critiques as an attack and then launch your own counter-attack. I don't mean to lecture, but your responses to several of the messages in this thread indicate that you are likely a younger/junior developer. That is not intended to be disparraging, but rather I am trying to understand the reason for the way in which you have responded in this thread. In my own case, I know that my attitude in response to critique was much like yours, when I was still a young developer who thought he knew it all. Over the years, though, I have come to understand that I know far less than I thought I knew when I was younger. That is, the world of programming knowledge far larger than I originally understood it to be. Even now, as a very experienced and senior developer, I frequently seek the advice and review of colleagues whenever I make significant changes to existing code, write new code, etc. I can tell you that I am a far better and more productive developer as a result. Another thing which seems to indicate that you are not particularly mature as a developer is the manner in which you quickly dismiss the results of static analysis. Certainly, there are instances where the tools do not fully understand the meaning of your code and provide false alarms. However, I have come to realize that static analysis is right for more than it is wrong. So, I have adopted the position that unless I can clearly articulate a good reason why the static analysis is wrong and my approach is better (and defend that reason to other programmers more senior than myself), I defer to the tool and fix the code. I do this in several programming languages. Additionally, the argument that you make, "If everything was clean, according to shellcheck, this wouldn't mean at all that the program is safe and secure and takes care of all the cases," is totally invalid. The fact that the tool fails to catch everything is not justification to automatically reject the things that it does catch. If the tool is consistently wrong, contact the developer of the tool with a sample of your code that you think the tool is incorrectly flagging, and convince the tool developer (using a technical and supported argument) why the tool should be updated. Your discussion with the tool developer might reveal to you that there is a defect in your own code that you did not understand. I encourage you, for your own benefit to accept the criticism from myself and others in the spirit in which it was intended: to help you produce a better free software tool and to improve as a developer. Regards, -Roberto -- Roberto C. Sánchez
Bug#903815: ITP: pw -- A simple command-line password manager
On Mon, Jul 16, 2018 at 03:14:20PM +0200, Dashamir Hoxha wrote: >On Mon, Jul 16, 2018 at 2:16 PM Philipp Kern <[1]pk...@debian.org> wrote: > > This clearly writes the unencrypted tarball out to disk. > >It writes to `/dev/shm` which is not disk. That is not a valid assumption. You have no way of knowing the device behind /dev/shm. > It writes to a random >temporary directory, so that it cannot be guessed. It removes >the unencrypted content as soon as the operation is performed. Unless the operation is atomic there is a possibility it can be interrupted. >All this happens almost instantly, it never stays unencrypted >for a long time. Ibid. > It is almost the same thing as using a pipe (|). >What is wrong here? It is not the same thing and it is based on several invalid/flawed assumptions. > I have been using it for 2-3 years and >never had a problem. > That doesn't make it correct code. I spend most of my day in code bases authored by other people. I consistently find bugs that have been in production, unreported, for 10 or more years. A bug is still a bug when it is found and identified, even if it has never manifested itself in the real world. If you doubt that, please review the recent news surrounding the SPECTRE and MELTDOWN vulnerabilities. Regards, -Roberto -- Roberto C. Sánchez
Bug#786810: ITA: xl2tpd -- layer 2 tunneling protocol implementation
On Fri, May 13, 2016 at 08:42:56PM +0200, Vincent Zweije wrote: > > It looks like things have got easier for me: > * Upstream has incorporated the changes you had in quilt patches, removing the > need for quilt. > * Upstream has removed the RFC text, removing the need for repacking. > * Upstream has modified its debian directory to *almost* work, except that the > changelog file is bogus. > > That last point doesn't matter really, as upstream's debian directory > is discarded by dpkg-source -x anyway. Still, their changes to their > debian directory can be taken over. > The main thing with the debian/ directory is that git-buildpackage expects there to be a "clean" upstream branch, usually called upstream and with no Debian-specific changes in it, and another Debian branch, usually called master and containing only Debian-specific packaging changes. I don't believe that upstream's repository enforces this distinction. That, along with the need to repack the source to remove the non-free RFC text, pushed me toward simply importing the upstream release tarballs (after they had been repacked) into my own repository and working with the code that way. > Am I correct in concluding that you were importing upstream releases > whenever they came out, and not using git to merge their sources? > That is correct. I was using uscan to download the release tarball (which got repacked by uscan) and then git-import-orig import it into my repository. > I'm considering stopping repacking upstream sources. Is there a concensus > in Debian on whether it is better not to repack and be as close to > upstream as possible, or to repack to get the debian directory out of > there and save some space? Or is it just left up to the maintainer? > I thin kthe consensus is to repack only when necessary. If an upstream tarball gets repacked, then it is no longer possible for a user to compare the hash of the .orig.tar.gz to the hash of the corresponding release tarball from upstream. It is desirable to have the .orig.tar.gz and upstream's release tarball be identical whenever possible. Eliminating a problematic debian/ directory is certainly a valid reason to repack. > Do you have a close contact with upstream, or should I go through the > regular channels? This in connection with forwarding the RC bug upstream. > The only person from upstream with whom I had regular contact has moved on a couple of years ago. I would recommend just approaching them through whatever normal public channels they have available. Regards, -Roberto -- Roberto C. Sánchez signature.asc Description: Digital signature
Bug#786810: ITA: xl2tpd -- layer 2 tunneling protocol implementation
Hi Vincent. On Wed, May 11, 2016 at 09:43:33PM +0200, Vincent Zweije wrote: > > In the mean time, I've cloned upstream git from > https://github.com/xelerance/xl2tpd.git and checked it out. It seems > to build fine. I still have to figure out what current bugs are fixed > upstream, I'll get onto that. > > There are some commits by you but I guess that is not the history that > you're talking about. I'd like to take a look at your repo. If you can > put it up somewhere I'll clone it. Do you mind if I make it public? > I'm sorry I missed your previous mail. I am apparently not subscribed to this bug. I have pushed my local xl2tpd repository here: http://anonscm.debian.org/cgit/users/roberto/xl2tpd.git/ Of course, you are welcome to make it public :-) As far as the upstream repository goes, upstream previously tried to always merge my Debian packaging into their repository. Of course, they did it on the master branch (probably owing to the fact that they were probably still on Subversion when they began this practice). In any event, it caused problems every time I tried to make a new upstream release. If you look in the debian/ directory if repo I just published, you will see a repack.sh script. That script removes upstream's debian/ directory and a non-free RFC text that they ship in their tarball. Let me know if you have any other questions or if you require any additional information. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#786810: O: xl2tpd -- layer 2 tunneling protocol implementation
Hi Vincent, > > I'm considering adopting. However: > That is excellent news. xl2tpd is still a valuable piece of software and I am pleased someone is interested in adopting. > * I don't know how to approach the RC bug yet > * I am not a debian developer > > How can we proceed? I suggest you have a look at the Debian Mentors [0] website. There is documentation there on how to get packages into Debian. If you like, rather than go through the normal process of soliciting a sponsor, you can contact me directly when you have an upload prepared and I will review it and sponsor your upload. For information on building packages, I wrote an article [1] several years ago that covers customizing an existing package (taking over an existing package is a very similar process). The only thing I would say is that I wrote that article before cowbuilder existed, so I suggest that you use cowbuilder instead of using pbuilder directly for your builds. Also, make sure to check out the documentation at the Debian Developers' Corner [2]. As far as the RC bug, you may want to contact upstream. I have found them to be responsive in the past, so that is likely a good starting point. Additionally, I have the complete package history in Git back to version 1.1.11. If you like, I can clone my local repository onto git.debian.org so that you can clone it from there and maintain the complete history. Let me know if you would like for me to do this. Also, if you have any questions about the package please don't hesitate to ask. Regards, -Roberto [0] https://mentors.debian.net/ [1] http://www.connexer.com/articles/debcustomize [2] https://www.debian.org/devel/ -- Roberto C. Sánchez signature.asc Description: Digital signature
Bug#652464: ITP: aguilas -- A web-based LDAP user management system
On Sat, Dec 17, 2011 at 06:08:35PM -0430, Luis Alejandro Martínez Faneyth wrote:
On 17/12/11 16:19, Sune Vuorela wrote:
$sel_q = SELECT * FROM NewUser
. WHERE mail=' . $mail . '
. AND uid=' . $uid . '
. AND token=' . $token . '
. ORDER BY token DESC LIMIT 0,1;
Thanks for having a look :)
Well, i perform a very strict validation before that query is made.
Lines 20 - 54:
http://code.google.com/p/aguilas/source/browse/NewUserDo.php#20
http://code.google.com/p/aguilas/source/browse/NewUserDo.php#54
You are still scared?
I would be. Bind variables exist for a reason. Aside from that, your
validation of email addresses is wrong:
// Invalid e-mail
} elseif (preg_match(/\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*/, $mail) ==
0) {
First off, there is nothing in the RFC that says that the email address
must start with a letter, which your regex requires. In addition to
that, you do not allow other allowed special characters:
!#$%'*/=?^_`{|}~(),:;@[\]
You also don't properly check for consecutive dots, so I could pass the
email a@foo.com and it pass your check, and still be wrong.
What you have done is reinvent the wheel, and badly at that.
If it were up to me, I would reject this package based on that one line
of code alone.
CODE IS POETRY
I find it terribly ironic that you have that satement in your email
signature.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
--
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/20111217225432.ga27...@connexer.com
Bug#652464: ITP: aguilas -- A web-based LDAP user management system
On Sat, Dec 17, 2011 at 07:02:35PM -0430, Luis Alejandro Martínez Faneyth wrote: On 17/12/11 18:24, Roberto C. Sánchez wrote: What you have done is reinvent the wheel, and badly at that. I coudn't find any other user friendly interface to manage user accounts from an LDAP. I should have been more clear. I was referring to the fact that there are lots of proven ways to validate email addresses in PHP. In fact, you don't even need any external library, you can just use filter_var(): http://php.net/manual/en/filter.examples.validation.php Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#639495: ITP: cpuset -- make using the cpusets facilities in the Linux kernel easier
On Sun, Aug 28, 2011 at 11:01:18PM +0200, Christian Kastner wrote: Can this be merged with #485827 (RFP: cpuset), or is this something else? Upstream URL of #485827 is dead, so I cannot tell. Christian, Thank you for the pointer. I checked the WNPP page prior to filing the ITP, and that bug (#485827) does not appear on the WNPP page. The bug you mention has been closed and is now archived. It is, in fact, the same cpuset (same upstream author), so I have unarchived it, reopened it, and merged the two bugs. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#639495: ITP: cpuset -- make using the cpusets facilities in the Linux kernel easier
On Sun, Aug 28, 2011 at 09:31:27PM -0300, Henrique de Moraes Holschuh wrote: How does it compare with hwloc? Does cpuset have any clue of the hardware topology like hwloc does? Looking at the hwloc page, it seems that cpuset does not have quite as robust a notion of the hardware topology as hwloc. Beyond that, I am not sure how it compares, having never used hwloc. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#549413: ITP: coinor-ipopt -- Interior-Point Optimizer, for general large-scale nonlinear optimization
On Sun, Oct 04, 2009 at 08:27:00AM +0200, Soeren Sonnenburg wrote: On Sat, 2009-10-03 at 18:43 -0400, Roberto C.Sánchez wrote: On Sun, Oct 04, 2009 at 12:05:21AM +0200, Soeren Sonnenburg wrote: it would be great if you would be willing to co-maintain it with Aramian and myself. We have been doing many of the coinor-* packages and I would love to see you join the team. Is there an Alioth project or a collab-main repository for the packages? The packages are all in a google-code svn http://code.google.com/p/bollin/source/browse/ I can give you r/w access to them, just send me your gpg key. This mail is signed with my GPG key, but the 0xB2B97BB1 if you need that. My key is in the Debian keyring. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#549413: ITP: coinor-ipopt -- Interior-Point Optimizer, for general large-scale nonlinear optimization
On Sat, Oct 03, 2009 at 09:47:21AM +0200, Soeren Sonnenburg wrote: Package: wnpp Severity: wishlist Owner: Soeren Sonnenburg so...@debian.org * Package name: coinor-ipopt Soeren, I just started working on packaging this last night and will have my package ready today. Did you already have a completed package? Would you be willing to turn over or share maintenance of this package? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#549413: ITP: coinor-ipopt -- Interior-Point Optimizer, for general large-scale nonlinear optimization
On Sun, Oct 04, 2009 at 12:05:21AM +0200, Soeren Sonnenburg wrote: it would be great if you would be willing to co-maintain it with Aramian and myself. We have been doing many of the coinor-* packages and I would love to see you join the team. Is there an Alioth project or a collab-main repository for the packages? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#518869: ITP: shorewall6 -- Shoreline Firewall (IPv6 version), netfilter configurator
On Mon, Mar 09, 2009 at 08:38:23AM +0100, Stefano Zacchiroli wrote: On Sun, Mar 08, 2009 at 08:34:23PM -0400, Roberto C. Sanchez wrote: Description : Shoreline Firewall (IPv6 version), netfilter configurator Uh? Can you please explain? Even though I'm not following the upstream evolution I'm a user of the shorewall package, which has IPv6 support even though disabled by default. Why we now need a separate package now? Upstream releases now the following packages for 4.2.x: shorewall-common shorewall-docs shorewall-lite shorewall-perl shorewall-shell shorewall6 shorewall6-lite shorewall6 depends upon shorewall-perl (and consequently shorewall-common) in order to work properly. It is a different rules engine/compiler that handles IPv6 packet filtering. It was implemented separately because it is in many ways much simpler than IPv4 packet filter (e.g., there is no NAT in IPv6 and IPsec is part of the spec instead of requiring encapsulation). Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#507400: [DRE-maint] Bug#507400: ITP: libi18n-ruby -- I18n and localization solution for Ruby
On Sun, Nov 30, 2008 at 09:42:39PM -0600, Gunnar Wolf wrote: Roberto C. Sanchez dijo [Sun, Nov 30, 2008 at 04:11:08PM -0500]: Package: wnpp Severity: wishlist Owner: Roberto C. Sanchez [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libi18n-ruby Version : 0.1.1~git20081120 Upstream Author : The Ruby i18n Team [EMAIL PROTECTED] * URL : http://rails-i18n.org/ * License : MIT/X Programming Lang: Ruby Description : I18n and localization solution for Ruby Implementation of the Ruby on Rails I18n core api. Ugh. Count me in as interested... But count me in as disappointed. From the (admittedly little) I have seen... The Rails i18n API is a huge step backwards from using Gettext for application translations :-( Still, if we want to further Rails' support in Debian, we have to support this. So, will you package this under the pkg-ruby-extras repository? I'm in for it. I know what you mean. It was very easy and quick to package, though, and it is currently waiting in NEW. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#487593: ITP: cil -- command line issue tracker
On Mon, Jun 23, 2008 at 09:50:02AM +1200, Francois Marier wrote: Package: wnpp Severity: wishlist Owner: Francois Marier [EMAIL PROTECTED] * Package name: cil Version : 0.2.0 Upstream Author : Andy Chilton [EMAIL PROTECTED] * URL : http://www.kapiti.geek.nz/software/cil.html * License : GPL Programming Lang: Perl Description : command line issue tracker 'cil' allows easy command-line creation of an issue tracker. It saves each issue locally and in plain text. Commands are given such that these issues can be added, edited and listed easily. I'm curious about something. I use ditrack and I am wondering what differences/advantages cil has over ditrack. Are you aware of any? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#480478: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository
On Sat, Jun 21, 2008 at 07:34:59PM +0200, Holger Levsen wrote: Hi, On Saturday 21 June 2008 15:52, Alexander Wirt wrote: I'm still not that sure if its a good idea to add a non-offical debian repo keyring into the archive... Nobody is forced to install it?! And AFAICS we regulary recommend backports.org to users, who need newer software. So I think it should be in. But backports.org is still unofficial. If it were permitted, then what would happen when other unofficial repository maintainers want to package their repository keyrings? Will those be allowed or disallowed? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#483483: Acknowledgement (RFA: releaseforge -- alternative to SourceForge's File Release System (FRS))
I have maintained releaseforge in svn the whole time I have been maintainer. If someone interested in adopting would like the entire svn history, please let me know and I would be glad to provide it. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#483484: Acknowledgement (RFA: vncsnapshot -- A utility that takes JPEG snapshots from VNC servers)
I have maintained vncsnapshot in svn the whole time I have been maintainer. If someone interested in adopting would like the entire svn history, please let me know and I would be glad to provide it. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#480035: ITP: libruby-rack -- A modular Ruby webserver interface
On Wed, May 07, 2008 at 10:49:56AM -0700, Sebastien Delafond wrote: Package: wnpp Severity: wishlist Owner: Sebastien Delafond [EMAIL PROTECTED] * Package name: libruby-rack I believe the convention would indicate that the proper name is librack-ruby. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#479238: ITP: res -- OCaml library for automatically resizing contiguous data structure
On Sun, May 04, 2008 at 08:44:57AM +0200, Stefano Zacchiroli wrote: On Sun, May 04, 2008 at 12:27:29PM +1000, Ben Finney wrote: Please change this to a package name that is less generic, and conforms with other OCaml library packages. 'libres-ocaml' would be better. This is the source package name, as in all ITPs, not the binary package name. No OCaml package has a source name like libFOO-ocaml, they all have *binaries* called libFOO-ocaml-dev. Well, we run into the same thing with the Debian Perl Group. For instance, take the CPAN module Relative.pm. Should the source package be called relative? That would be far too generic. The binary package is definitely called librelative-perl. But then, so is the source package. Having a different name from upstream has never been a problem. In fact, for something like language libraries, especially when they originate from some sort of common language repository like CPAN or CRAN or whatever if OCaml has something similar, it is probably good to have some sort of common naming scheme. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#474279: ITP: libdevel-profile-perl -- tell me why my perl program runs so slowly
On Fri, Apr 04, 2008 at 09:29:33PM +0300, Niko Tyni wrote: On Fri, Apr 04, 2008 at 01:41:06PM -0400, Roberto C. Sanchez wrote: * Package name: libdevel-profile-perl Description : tell me why my perl program runs so slowly The Devel::Profile package is a Perl code profiler. This will collect information on the execution time of a Perl script and of the subs in that script. This information can be used to determine which subroutines are using the most time and which subroutines are being called most often. . To profile a Perl script, run the perl interpreter with the -d debugging switch. The profiler uses the debugging hooks. . So to profile script test.pl the following command should be used: . perl -d:Profile test.pl . When the script terminates (or periodicly while running) the profiler will dump the profile information to a file called prof.out. This file is human-readable, no additional tool is required to read it. Hi, what's the difference to Devel::DProf, bundled with the Perl core? The fact that the output file is human-readable? That and that it works with XS modules, which DProf does not. Incidentally, Joey Hess already packaged this and it is in NEW, so I have closed the ITP. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#474036: ITP: xnetcardconfig -- tool to configure your network cards using an easy wizard
On Wed, Apr 02, 2008 at 11:05:46PM +0200, Philippe Coval wrote: Package: wnpp Severity: wishlist Owner: Philippe Coval [EMAIL PROTECTED] * Package name: xnetcardconfig Version : 0.2.1 Upstream Author : Benedikt Meurer [EMAIL PROTECTED] * URL : http://www.example.org/ Where is the package really hosted upstream? * License : GPL Programming Lang: Ruby Description : tool to configure your network cards using a wizard GUI It's just a ruby script to be used along sudo. Note that I am about to upload the package to debian mentors and start looking for a sponsor. If it us just a ruby script, is it sensible to use an entire package for it? What about trying to get it included in another package that has similar functionality already? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#470621: ITP: nxcl -- NX X compression client library
On Thu, Mar 13, 2008 at 03:08:39PM +0100, Michael Biebl wrote: Just curious: One of the major complaints about NX (iirc) and the reason why it wasn't packaged for Debian yet, is that it basically was a fork of the complete Xorg/Xfree86 sources (which understandably didn't make our security team happy). Is nxcl a reimplementation that solves this problem? Does it allow to implement the NX server as an extension for Xorg? Yes. Thay also fork openssh, CUPS and other stuff. The submitter is advised to check the mailing list archives of the pkg-nx group on Alioth. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#462027: ITP: libactiverecord-ruby -- library that ties database tables to classes in Ruby
On Mon, Jan 21, 2008 at 09:35:06PM -0500, David Nusinow wrote: On Mon, Jan 21, 2008 at 09:19:01PM -0500, Roberto C. Sanchez wrote: Package: wnpp Severity: wishlist Owner: Roberto C. Sanchez [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libactiverecord-ruby Version : 2.0.2 Upstream Author : David Heinemeier Hansson [EMAIL PROTECTED] * URL : http://ar.rubyonrails.com/ * License : MIT Programming Lang: Ruby Description : library that ties database tables to classes in Ruby Implements the ActiveRecord pattern (Fowler, PoEAA) for ORM. It ties database tables and classes together for business objects, like Customer or Subscription, that can find, save, and destroy themselves without resorting to manual SQL. Have you spoken with the rails package maintainer about this and your other ITP? Having duplicate copies of the same code lying around in the archive is something the security team has said they are actively discouraging. Splitting these out from the rails package seems like the smarter way to go. In fact, I have not. I have been asked to package these Ruby modules and my methodology for determining whether or not they were in Debian involved checking for current/previous WNPP bugs about them and then checking for packages already in Debian with similar names. Let's just say that I am still in the getting started phase with Ruby. However, I will contact them before I do anything else. Thanks for the info. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#459208: ITP: anyterm -- A terminal emulator on a Web page using Javascript and an Apache module
On Fri, Jan 04, 2008 at 05:57:42PM +0200, Mohammed Sameer wrote: Package: wnpp Severity: wishlist Owner: Mohammed Sameer [EMAIL PROTECTED] * Package name: anyterm Please consider closing this ITP. First, I had an ITP [0] open for quite a while. You can read there for some lengthy conversation of the problems you will encounter with respect to getting login to work properly with anyterm. In short, there is an excerpt from a conversation in #debian-devel regarding the issue which indicates that getting acceptance from the security team may be problematic. Additionally, you will note in my last message to #311597, that anyterm has been superseded by ajaxterm [1] and webshell [2]. If you look, you will see that ajaxterm is already in Debian [3]. As far as webshell, its open bug is only an RFP. I recommend that you first look at ajaxterm and see if it fits your needs. If so, then excellent. If not, then please consider packaging webshell. Since the WNPP bug open against it is an RFP, you can simply take ownership of it and change its title to an ITP. If you still feel that you must package anyterm, then please read the log of #311597 carefully and also please consider adopting rote [4] away from me. The rote package is needed for anyterm and is very low maintenance. However, I do not use it myself. I just kept it around in the event someone else came along and wanted to package anyterm. Also, I have packages of version 1.1.5 of anyterm. If you want them, I will happily email you the source package or place them somewhere where you can download them. They work but should still be considered a work in progress, which is why I never released them officially. Also, as a final recommendation, please merge your current anyterm ITP with the old one so that the information in the old bug log is not lost. Regards, -Roberto [0] http://bugs.debian.org/311597 [1] http://bugs.debian.org/366285 [2] http://bugs.debian.org/435219 [3] http://packages.debian.org/ajaxterm [4] http://packages.qa.debian.org/r/rote.html -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#459208: ITP: anyterm -- A terminal emulator on a Web page using Javascript and an Apache module
Don't worry. I don't feel like my toes were stepped on. I just did not want for you to have to unnecessarily pass the same headaches I did. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#397533: How soon for some wxPerl packages?
Jose, I saw that you have taken ownership for the wxPerl ITP. Do you have any idea how soon we can expect the packages in Debian? If not, I'd like to know if I can help or create some official packages myself. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#449260: ITP: zekr-quran-translations-fa -- Zekr Quran Persian translations
On Sun, Nov 04, 2007 at 09:45:27AM -0500, Mohammad Derakhshani wrote: Package: wnpp Severity: wishlist X-Debbugs-CC: [EMAIL PROTECTED] * Package name: zekr-quran-translations-fa Version : 1.1.dfsg How does this Upstream Author : Mohsen Saboorian [EMAIL PROTECTED] * URL : http://siahe.com/zekr * License : Only free for non-commercial purposes Mesh with this^ ?? Am I missing something? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#448733: Please keep in mind that upstream is probably dead
Anyone adopting Dillo should also keep in mind that upstream is basically dead, or at least in a very deep freeze. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#446644: Bug#446646: ITP: shorewall4-lite -- Shoreline Firewall, netfilter configuration tool (lite version)
On Tue, Oct 16, 2007 at 12:28:23PM +0200, Holger Levsen wrote: Hi, On Sunday 14 October 2007 19:00, Roberto C. Sanchez wrote: * Package name: shorewall4-lite First of all, why do you propose shorewall4 packages instead of just upgrading shorewall to version 4? I have already closed this ITP. I am simply going to setupa migration to version 4 of shorewall based on the current packages. Description : Shoreline Firewall, Netfilter configurator (lite version) The shorewall4-lite package is designed to allow you to maintain all Shorewall configuration information on a single system within your network. I dont see whats special or lite about this, this is just the way shorewall works :-) Basically, You only need one system with a full shorewall install. This machine can then generate a script that can be executed on a machine with shorewall-lite. Thus, you can install the full shorewall on a test/development server and then shorewall-lite on the production machines, or something like that. But thats probably related to my questions about shorewall4-perl and -shell: their proposed long description ends with: This version of Shorewall includes a compiler written in perl|shell. - does that mean, that shorewall is a general purpose compiler now? Wow! ;) Please enhance the description to describe what kind of compiler that is and what its used for. It already says that it is for configuring netfilter. I'm not certain how much clearer I can make it. I copy/pasted from the current package descriptions, which have been fine for quite a while. Also those two packages claim their programming language is sh - I wonder if this is right... (maybe it is, and the compiler written in sh compiles perl or shell code... and compiles it to iptables code?!) The sh for the -perl package was a mistake. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#446645: ITP: shorewall4-perl -- Shoreline Firewall, netfilter configuration tool (perl-based)
On Sun, Oct 14, 2007 at 12:59:06PM -0400, Roberto C. Sanchez wrote: Programming Lang: sh Description : Shoreline Firewall, Netfilter configurator (perl-based) Let's make that perl so that it makes sense :-) Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#446645: ITP: shorewall-perl -- Shoreline Firewall, netfilter configurator (perl-based)
retitle 446645 ITP: shorewall-perl -- Shoreline Firewall, netfilter configurator (perl-based) thanks On Sun, Oct 14, 2007 at 12:59:06PM -0400, Roberto C. Sanchez wrote: * Package name: shorewall4-perl Name change for the same reason as documented in #446644. The perl-based version of Shorewall is not in the standard upgrade path. However, it will still be available to those who would like to switch. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#446657: ITP: shorewall-common -- Shoreline Firewall, netfilter configurator (common files)
retitle 446657 ITP: shorewall-common -- Shoreline Firewall, netfilter configurator (common files) thanks On Sun, Oct 14, 2007 at 02:06:55PM -0400, Roberto C. Sanchez wrote: * Package name: shorewall4-common Another package name change. Check #446644 and #446645 for details. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#446644: ITP: shorewall-shell -- Shoreline Firewall, netfilter configurator (shell-based)
retitle 446644 ITP: shorewall-shell -- Shoreline Firewall, netfilter configurator (shell-based) thanks On Sun, Oct 14, 2007 at 12:57:07PM -0400, Roberto C. Sanchez wrote: * Package name: shorewall4-shell OK. Changing the package name since we don't still want to be dragging around a 3.4 release of Shorewall when Lenny releases. This package will provide the upgrade path to those who are using the current shorewall 3.x packages. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#445998: ITP: eaccelerator -- PHP accelerator, optimizer, and dynamic content cache
On Tue, Oct 09, 2007 at 09:24:14PM +0200, Tim Dijkstra wrote: On Tue, 09 Oct 2007 21:29:38 +0400 Alexander Gerasiov [EMAIL PROTECTED] wrote: Package: wnpp Severity: wishlist Owner: Alexander Gerasiov [EMAIL PROTECTED] * Package name: eaccelerator Version : 0.9.5.2 Upstream Author : eaccelerator team http://eaccelerator.net/wiki/Team * URL : http://eaccelerator.net * License : GPL Programming Lang: C Description : PHP accelerator, optimizer, and dynamic content cache Some dummy packages available for now in my repository at http://gq.net.ru/debian I'm going to upload it after fixing some packaging issues. Feel free to kick me by mail, if I'm too slow. Are the license issues finally solved then? Last time I checked binaries were not distributable, see for example: http://www.mailarchives.org/list/debian-devel/msg/2005/08164 grts Tim Also, in one of the many discussions about this piece of software it came out that original author of turck-mmcache (the software on which eaccelerator is based) now works for Zend. Zend produces a proprietary (and expensive) accelerator-sort of product for PHP. It is doubtful that they would enable the distribution of something that they would see as competing with their product. I seem to recall that the people who took over eaccelerator had it in mind to do a complete rewrite of the eccalerator code to break any link with turck-mmcache, allowing them to relicense eaccelerator. If that rewrite is complete, then the software may be distributable. However, I have not looked into it for quite a while. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#445866: ITP: perforce -- closed source revision control system
On Mon, Oct 08, 2007 at 11:15:38PM +0200, Steinar H. Gunderson wrote: On Mon, Oct 08, 2007 at 03:41:21PM -0400, Roberto C. Sánchez wrote: Given the great abundance of revision control systems already packaged for Debian, what is the point of adding another? I don't see the relevance of this argument, really, but if you really think it's a problem: What if someone needed to access an existing Perforce repository? I did not realize that this was only for the client. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#445866: ITP: perforce -- closed source revision control system
On Mon, Oct 08, 2007 at 07:30:09PM +0100, Sam Clegg wrote: Package: wnpp Severity: wishlist Owner: Sam Clegg [EMAIL PROTECTED] * Package name: perforce Version : 2007.2-2 Upstream Author : Perforce Inc. [EMAIL PROTECTED] * URL : http://www.perforce.com/ * License : proprietary Programming Lang: binary only (with bindings in Perl, Python, etc.) Description : closed source revision control system Given the great abundance of revision control systems already packaged for Debian, what is the point of adding another? Especially when it is non-free. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#391473: Next steps in systemimager maintenance?
Dann, I am interested to know what you feel are the next steps in the transition for systemimager maintenance. I am still interested in maintaining the packages or leading the team that does. In glancing at the bug reports page, it looks like you have been keeping up with forwarding and tagging the bugs. Based on that, I am going to guess that the bugs are pretty well already triaged. Is that a fair assessment? If there is anything else that I have missed in order to get started, please let me know. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#255850: Ping to WNPP bugs
This is a ping to my WNPP bugs. I am still alive, but have been recently been tasked with quite a bit of travel for work. My time to work on these will be limited in the coming weeks, but I still plan on getting to them. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#391473: Team maintenance of systemimager
fyi, systemimager packaging is still being developed here: svn://svn.systemimager.org/svn/systemimager-debian/ Oh. I was not aware of that. There are already lists for development and for monitoring commits, and there is active packaging development (mostly from Geoffroy Vallee these days). Is this for upstream development or for Debian specific stuff? Do you have links for these lists? I'm all for team maintainance - but I really want to see a smooth transition. I don't think we need to migrate to alioth when we already have an active development location. And - though I'm excited to see the interest, I'm uncomfortable handing this over to a group of people from whom I don't recall seeing any significant patches (no offense intended). I also would like to see a smooth transition. I can agree that an immediate move should not be force if there is already an established location. However, I think that migrating the Debian-specific stuff to Alioth has a number of benefits and I think it should be a goal once the transition has stabilized. I take no offense at your discomfort. I have not contributed to systemimager in the past, however I find myself using it more and more. Thus, I'd like to get involved now. I can't speak for the other interested parties. However, I can tell you that there is no need to worry about my abilities. I maintain or actively participate in the team maintenance of 17 packages. Additionally I have been taking a more active role in QA work and even started sponsoring. http://qa.debian.org/[EMAIL PROTECTED] http://qa.debian.org/[EMAIL PROTECTED] http://qa.debian.org/developer.php?login=roberto My preference is to continue working where we are, and for developers to send patches to the devel list for review. Overtime I can grant new developers commit access based upon the quality of their contributions. That sounds OK. But again, I still think that the ultimate goal should be a move to Alioth. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#428467: ITP: balance -- Surprisingly successful load balancing solution and generic tcp proxy
On Mon, Jun 11, 2007 at 06:53:27PM -0500, Rafael D'Leon wrote: Package: wnpp Severity: wishlist Owner: Rafael D'Leon [EMAIL PROTECTED] * Package name: balance Version : 3.35 Upstream Author : Thomas Obermair ([EMAIL PROTECTED]) * URL : http://www.inlab.de/balance.html * License : GPL Programming Lang: C Description : Surprisingly successful load balancing solution and generic tcp proxy I would remove Surprisingly successful from the short and long descriptions. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#428212: ITP: linky -- an Iceweasel extension to handle web and image links
On Sat, Jun 09, 2007 at 06:21:11PM -0500, Steve Greenland wrote: On 09-Jun-07, 17:41 (CDT), Joao Eriberto Mota Filho [EMAIL PROTECTED] wrote: * Package name: linky Version : 2.7.1 Upstream Author : Henrik Gemal [EMAIL PROTECTED] * URL : http://gemal.dk/mozilla/linky.html * License : MPL-1.1 Description : an Iceweasel extension to handle web and image links Aren't iceweasel extension packages supposed to be named 'iceweasel-foo'? (No idea if there's actual policy, just looking at the existing packages) Thus Package name : iceweasel-linky I was thinking something similar. I am sponsoring Arnaud Renevier for his noscript package. Initially, he called it just noscript. It was rejected by the ftp-masters as too generic. Arnaud renamed it to mozilla-noscript and that was accepted. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#358799: Adoption of l2tpd/packaging of xl2tpd
package wnpp retitle 358799 ITA: l2tpd -- A layer 2 tunneling protocol implementation. thanks Hello, I travel quite a bit and have really felt the need for a good VPN solution while I am on the road. I was using l2tpd (and now xl2tpd) in order to make configuration from the client perspective as simple as possible (i.e., it facilitates easily switching between devices as I travel). To that end, I'd like to adopt l2tpd (in order to turn it into a dummy package and facilitate a transition to xl2tpd). The old l2tpd has not seen any activity for a while and it appears that upstream is also still dead. I have already built a preliminary Debian package which I am testing out on my own system. Incidentally, a SourceForge or Gforge project or something like that to facilitate upstream development/support/bug reporting and so on would be good. I have already filed an ITP (bug #427113) [0] for the xl2tpd package. My intent is have that one conflict/replace the l2tpd package. The only thing left for me to implement is handling the migration of the configuration and secrets. Regards, -Roberto [0] http://bugs.debian.org/427113 -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#423911: ITP: citadel -- Citadel.org is an highly integrated Groupware Platform with a Web 2.0 enabled Webinterface, but also providing SMTP, IMAP, POP3 and GroupDAV access to its content.
On Tue, May 15, 2007 at 12:23:06AM +0200, Wilfried Goesgens wrote: Description : Citadel.org is an highly integrated Groupware Platform with a Web 2.0 enabled Webinterface, but also providing SMTP, IMAP, POP3 and GroupDAV access to its content. Ahh! The short description is far too long. Try this: a groupware platform offering access via the web and standard protocols Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#411403: Do you still need a sponsor for noscript?
On Fri, May 11, 2007 at 10:11:23AM +0200, arno wrote: Roberto C. Sánchez wrote: I looked at your GPG key. However, it does not appear to be signed by a Debian developer. Are you able to get your key signed? By your email it looks like you are in France. There are quite a few keysigning offers there: https://nm.debian.org/gpg_offer.php Hi, my key has been signed by a debian developer now. It is key 0x2701B2B3 available on pgp.mit.edu I've uploaded on new version of noscript to mentors to change my email adress (and also to correct an error I made). OK. I will look at it tomorrow or Sunday. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#411403: Do you still need a sponsor for noscript?
On Fri, May 11, 2007 at 10:11:23AM +0200, arno wrote: Hi, my key has been signed by a debian developer now. It is key 0x2701B2B3 available on pgp.mit.edu I've uploaded on new version of noscript to mentors to change my email adress (and also to correct an error I made). OK. I got your key and verified that it is signed by a current Debian Developer. A few things about your package: - First, there has a been a new upstream release as of 5/2/2007, you should update. (Please also see the note below about your changelog.) - The md5sums of the contents of the .orig.tar.gz don't match the md5sums of the contents of the .xpi. (I understand that you had to tar up the .xpi, which is why I did not just check the sums of the .xpi and the .orig.tar.gz. However, the chrome/noscript.jar and install.rdf files differ. The difference in the install.rdf is a single character in a version string. The noscript.jar files differ, but all of their contents are the same. This is just something of which you need to be aware since you must always repackage your upstream release.) - Your changelog needs fixing. You have many entries, when in fact this would be the first one to make it to the archive. Unless you have widely released the package already, you should just have a single changelog entry Initial release. (Closes: #411403). - I think you are going the long way about repackaging the upstream release. The uupdate command supports zip files. I think that if you simply download the .xpi, rename it to .zip and use uupdate, it will figure everything out for you. I would play around with that some, as it might save you time in the future. - In your debian/copyright file, the URL which it mentions from where you obtained the software gives a 404. The new URL appears to be https://addons.mozilla.org/firefox/722/ - I really like how you got rid of all the crap sites from the pre-packaged whitelist. However, this might confuse users who come from using this somewhere else. It is best if you add a README.Debian file and make note of which domains which are normally whitelisted that you have removed. - Your debian/rules file is very clean. (It looks much nicer than my first few packages :). - I like that you use dpatch and don't change the package files themselves. Personally, I think the .diff.gz should never touch anything outside of the debian/ directory. - Your watch file works. However, be aware that the site to which you direct it does not have any release listed for more than two months. If you can find a better one, that would be good. I think that since the watch file supports parsing html links, you could point it at the noscript.net download page. There is a direct download link on that page. - The package is lintian clean and linda clean. That is excellent. It also passes piuparts. If you do not already do so, make sure that you run these three tools on all your packages. If you fix up these issues, I would be happy to sponsor this package for you. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#411403: Do you still need a sponsor for noscript?
On Sun, May 06, 2007 at 03:23:29PM +0200, arno wrote: My accounts were recently created and so I am now able to sponsor uploads. Do you still need sponsorship? Hi, yes, I'm still looking for a sponsor. I have uploaded a new version on mentors today. thank for your interest I looked at your GPG key. However, it does not appear to be signed by a Debian developer. Are you able to get your key signed? By your email it looks like you are in France. There are quite a few keysigning offers there: https://nm.debian.org/gpg_offer.php Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#411403: Do you still need a sponsor for noscript?
Arno, My accounts were recently created and so I am now able to sponsor uploads. Do you still need sponsorship? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#416929: ITP: perl-doc-html -- Perl documentation suitable for viewing with a web browser
On Sat, Mar 31, 2007 at 08:43:30PM +0200, Florian Weimer wrote: * Roberto C. Sanchez: This is the same documentation as provided by the perl-doc package. However, it has been formatted into HTML, making it suitable for veiwing with a local web browser or for serving up on an intranet for multiple users. Can't you build this from the Perl sources? Why is another package needed? The perl INSTALL file says the following: HTML pages Currently, the standard perl installation does not do anything with HTML documentation, but that may change in the future. Further, some add-on modules may wish to install HTML documents. The html Configure variables listed above are provided if you wish to spec- ify where such documents should be placed. The default is none, but will likely eventually change to something useful based on user feedback. That makes me think that the answer is no. If I have missed something, please let me know. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#416929: ITP: perl-doc-html -- Perl documentation suitable for viewing with a web browser
On Sat, Mar 31, 2007 at 09:44:48PM +0200, Florian Weimer wrote: I should say that I meant source package, not binary package. IMHO, the perl-doc-html binar ypackage should be built from the perl source package. Right. I looked in the perl source package, which is where I found the snippet in my previous mail. It appears to me that the perl source package's included build system won't build the HTML documentation. Again, if I misread or overlooked something, please let me know. (I am still a Perl newbie :-) Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#255850: help needed?
On Wed, Mar 28, 2007 at 04:30:50PM +0200, Bernd Zeimetz wrote: Heya, as I plan to use NX please let me know if there's anything I can help with. Are your packages in alioth's svn? Not yet. This semester finishes next month and I am not planning on taking any classes over the summer, so I plan to have more time to dedicate to this soon. Thanks for your interest. I'll let you know. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#416005: ITP: xgawk -- Extensible AWK, with XML and PgSQL support
On Fri, Mar 23, 2007 at 10:35:12PM +0100, Pawel Wiecek wrote: Package: wnpp Severity: wishlist Owner: Pawel Wiecek [EMAIL PROTECTED] * Package name: xgawk Version : 3.1.5-beta.20060401 Upstream Author : Andrew J. Schorr [EMAIL PROTECTED] Juergen Kahrs [EMAIL PROTECTED] * URL : http://home.vrweb.de/~juergen.kahrs/gawk/XML/ * License : GPL, version 2 Programming Lang: C Description : Extensible AWK, with XML and PgSQL support Hmm. The name xgawk makes me think of an X-based program. Would xmlgawk be an acceptable name? I know that there is no strict policy on the matter, but I think it has the potential to cause confusion. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
