Bug#963594: ITP: golang-github-jsimonetti-rtnetlink -- low-level access to the Linux rtnetlink API
Hi Benjamin, sorry for not answering your pings before! Thanks for taking this on! It was indeed a bit stalled on my side :( Cheers, Leo On Tue, Jan 11, 2022 at 2:23 PM Benjamin Drung wrote: > > Hi, > > On Wed, 24 Jun 2020 09:49:04 +0200 "Leo Antunes" > wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Leo Antunes > > Control: block 963592 by -1 > > > > * Package name: golang-github-jsimonetti-rtnetlink > > Version : 0.0~git20200505.3ee32e7-1 > > Upstream Author : Jeroen Simonetti > > * URL : https://github.com/jsimonetti/rtnetlink > > * License : Expat > > Programming Lang: Go > > Description : Package rtnetlink provides low-level access to > the Linux rtnetlink API. > > > > Package rtnetlink allows the kernel's routing tables to be read and > > altered. Network routes, IP addresses, Link parameters, Neighbor > setups, > > Queueing disciplines, Traffic classes and Packet classifiers may all > be > > controlled. It is based on netlink messages. > > . > > A convenient, high-level API wrapper is available using package rtnl > > (https://godoc.org/github.com/jsimonetti/rtnetlink/rtnl). > > . > > The base rtnetlink library explicitly only exposes a limited low- > level > > API to rtnetlink. It is not the intention (nor wish) to create an > > iproute2 replacement. > > Since there were no progress on this ticket, I just high-jacked it (to > be able to drop the vendored libs in prometheus-node-exporter). > rtnetlink is uploaded to the NEW queue and published on > https://salsa.debian.org/go-team/packages/golang-github-jsimonetti-rtnetlink > Please add yourself to the Uploaders. > > -- > Benjamin Drung > > Senior DevOps Engineer and Debian & Ubuntu Developer > Compute Platform Operations Cloud > > IONOS SE | Revaler Str. 30 | 10245 Berlin | Deutschland > E-Mail: benjamin.dr...@ionos.com | Web: www.ionos.de > > Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 > > Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning > Kettler, Arthur Mai, Britta Schmidt, Achim Weiß > Aufsichtsratsvorsitzender: Markus Kadelke > > > Member of United Internet >
Bug#856524: RFA: libpst - library for reading Microsoft Outlook PST files
Hi Paul, On Sun, Dec 15, 2019 at 5:44 AM Paul Wise wrote: > We started using libpst at work and I just got approval to adopt the > package. I'll start by adding myself to uploaders and committing some > packaging updates to the Debian git repository. Are you OK with me > adopting the package and do you want to co-maintain the package? I'd be very glad to finally hand this over to someone with the time this little package deserves! Feel free to just take it over completely. If and when the occasion presents itself, I'm sure we'll find a quick way for me to start helping again. Cheers, Leo
Bug#933820: WIP
Hi Lee, Unfortunately this stalled a bit since my request to join the DMPT[0] apparently went under the radar. I'll ping the lists and see if I can get the ball rolling again. Cheers, Leo [0] https://lists.debian.org/debian-python/2019/08/msg00152.html On Sun, Dec 8, 2019 at 4:03 PM Lee Garrett wrote: > > Hi Leo! > > On Sun, 4 Aug 2019 03:41:05 +0200 "Leo \"Costela\" Antunes" > wrote: > > FYI, some WIP is on: https://salsa.debian.org/costela/hcloud-python > > This will hopefully be moved to the python-modules group eventually. > > > > Cheers > > is there any progress on the ITP of python3-hcloud? It sounds like a > useful package to me. :) > > Greetings, > Lee
Bug#933820: WIP
FYI, some WIP is on: https://salsa.debian.org/costela/hcloud-python This will hopefully be moved to the python-modules group eventually. Cheers
Bug#907501: Acknowledgement (ITP: golang-docker-go-docker -- official go SDK for docker)
FYI: the current version doesn't build because it relies on unreleased code in golang-github-docker-distribution-dev. WIP can be found here: https://salsa.debian.org/costela/golang-docker-go-docker On Tue, Aug 28, 2018 at 10:00 PM Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 907501: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907501. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > As you requested using X-Debbugs-CC, your message was also forwarded to > debian-de...@lists.debian.org > (after having been given a Bug report number, if it did not have one). > > Your message has been sent to the package maintainer(s): > w...@debian.org > > If you wish to submit further information on this problem, please > send it to 907...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 907501: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907501 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems >
Bug#731534: RFP: chapel -- imperative programming language with focus on parallelism
Package: wnpp Severity: wishlist * Package name: chapel Version : 1.8.0 Upstream Author : Cray Inc. * URL : http://chapel.cray.com * License : BSD Programming Lang: C Description : imperative programming language with focus on parallelism Chapel is an emerging parallel programming language whose design goal is to make parallel programming more productive, from high-end supercomputers to commodity clusters and multicore desktops and laptops. . Chapel supports a multithreaded execution model via high-level abstractions for data parallelism, task parallelism, concurrency, and nested parallelism. . Chapel supports global-view data aggregates with user-defined implementations, permitting operations on distributed data structures to be expressed in a natural manner. In contrast to many previous higher-level parallel languages, Chapel is designed around a multiresolution philosophy, permitting users to initially write very abstract code and then incrementally add more detail until they are as close to the machine as their needs require. Chapel supports code reuse and rapid prototyping via object-oriented design, type inference, and features for generic programming. -- 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/20131206113623.28409.6174.reportbug@motion.local
Bug#491723: StatusNet package upload?
[taking Andreas out of the loop, hope this is fine] Hi, On 28/01/13 22:04, Daniel Pocock wrote: Leo, Brenda, can either of you let us know about this package? Oh man... at one point I really thought I would get this package in good shape, but after Roland's poke I merged from upstream and noticed there were a LOT of changes which made my packaging work pretty much useless, so it got put way back in the TODO list. My mistake for not updating the bug to reflect this! Please consider this package free for the taking! Evan, I notice in the bug trail you are a DD too, so maybe you would like to upload yourself if you think it is ready? If nobody else was able to, I was going to consider sponsoring it myself. As I said, the latest work in the git repo [0] is unfortunatelly very out-of-date with regards to recent changes upstream, so I don't think it can just be uploaded as-is. I imagine someone with a bit more time and dedication than myself could get it in shape in a few hours/days. Please feel free to give it a try! If pkg-xmpp is not optimal for the package, do you think it might be worthwhile forming another group for maintaining this and maybe similar packages or add-ons? IMHO a different group sounds more appropriate, but the pkg-xmpp people should probably be asked if their interested. Better some slightly-off-topic team working on it than nobody at all! ;) Cheers [0] http://anonscm.debian.org/gitweb/?p=collab-maint/statusnet.git -- Leo costela Antunes [insert a witty retort here] -- 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/510d9a3a.2020...@debian.org
Bug#677750: RFH: gnokii -- Datasuite for mobile phone management
Package: wnpp Severity: normal Hi, I haven't had the need to use gnokii for years and am currently a bit too swamped with Real Life™ to dedicate the necessary time to its packaging, even though it's relatively low-maintenance. If there's anyone out there who still uses gnokii and has the time to lend a hand, your help would be really appreciated! Cheers Leo -- 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/20120616173614.3778.98541.reportbug@inertia.local
Bug#491723: debian/copyright for statusnet
On 23/03/12 22:25, Roland Mas wrote: I was somewhat bored and I wanted to play with config-edit stuff; since I'm also eager to see statusnet enter Debian officially, I spent some time reading copyright notices and transcribing them. Here's what git produced (I have no idea if it's actually useful as is, but at least there's a patch in there): Thanks a lot for the work! I also needed a poke to go back to working on this, so I'll take a look at the patch this week and try to get the missing pieces in place for an upload soon-ish. Cheers -- Leo costela Antunes [insert a witty retort here] -- 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/4f706821.8080...@debian.org
Bug#663017: ITP: transmission-remote-cli -- ncurses interface for the Transmission BitTorrent daemon
On 08/03/12 13:59, Jonathan McCrohan wrote: Shouldn't it be included in the transmission-cli package instead? I guess it could be included in transmission-cli. I thought transmission-remote-cli would be better suited to its own package because it a third-party transmission tool, and not part of the transmission project itself [1]. I agree it's probably better to have its own package. I also have an ITP for transmission-remote-gtk, which is in a similar situation. That being said: I haven't checked the source, but I'm a bit curious about its use of transmission-remote. Does it depend on specific input/output formats? Did upstream at some point declare a stable API for using transmission-remote in scripts? I'm just worried this might be a small nightmare to maintain in the long run... Cheers -- Leo costela Antunes [insert a witty retort here] -- 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/4f58c0e5.4070...@debian.org
Bug#660654: ITP: binwalk -- tool for searching binary images for embedded files and executable code
Package: wnpp Severity: wishlist Owner: Leo 'costela' Antunes cost...@debian.org * Package name: binwalk Version : 0.4.2 Upstream Author : Craig Heffner heffne...@gmail.com * URL : http://code.google.com/p/binwalk/ * License : Expat Programming Lang: C Description : tool for searching binary images for embedded files and executable code Binwalk is a tool for searching a given binary image for embedded files and executable code. Specifically, it is designed for identifying files and code embedded inside of firmware images. Binwalk uses the libmagic library, so it is compatible with magic signatures created for the Unix file utility. . Binwalk also includes a custom magic signature file which contains improved signatures for files that are commonly found in firmware images such as compressed/archived files, firmware headers, Linux kernels, bootloaders, filesystems, etc. -- 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/20120220163751.28342.16700.reportbug@motion.local
Bug#491723: Status.net Debian Package
Just a FYI: The package is almost ready, the only thing missing before I can do an official upload is the debian/copyright file. There's a lot of manual work involved and I can't seem to find the time to sit down and do it (and honestly, the motivation isn't exactly brimming for this specific kind of work! ;) ). If anyone would like to give it a final push, I'd really appreciate the help! Feel free to take a look at the current code at: git://git.debian.org/~costela/statusnet.git Cheers -- Leo costela Antunes [insert a witty retort here] -- 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/4edfe0a9.1000...@debian.org
Bug#630789: ITP: transmission-remote-gtk -- GTK remote control for the Transmission BitTorrent client
Package: wnpp Severity: wishlist Owner: Leo 'costela' Antunes cost...@debian.org * Package name: transmission-remote-gtk Version : 0.5.1 Upstream Author : Alan Fitton a...@eth0.org.uk * URL : http://code.google.com/p/transmission-remote-gtk/ * License : GPL-2+ Programming Lang: C Description : GTK remote control for the Transmission BitTorrent client [from the site:] transmission-remote-gtk is a GTK application for remote management of the Transmission BitTorrent client via its RPC interface. * remotely add (file/url), start, stop, remove, remove delete, verify, reannounce torrents. * works as a .torrent handler (eg. from a web browser). * set torrent properties such as speed, seed, peer limits, file priorities, add/edit/remove trackers. * change remote settings like global limits, download directory, and connectivity preferences. -- 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/20110617114349.29186.24551.reportbug@motion.local
Bug#623982: RFA: camorama
Package: wnpp Severity: normal Camorama hasn't really been maintained since 2007 and has been largely supplemented by cheese[0]. It's been in the bottom of my priorities list for a while, so it's only fair it gets taken care of, by someone who has a genuine interrest in it (assuming there is someone out there who fits this role). Cheers Leo costela Antunes [0] http://packages.qa.debian.org/c/cheese.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/20110425010417.28562.18093.reportbug@motion.local
Bug#491723: Status.net Debian Package
On 30/03/11 20:54, Marcelo Jorge Vieira wrote: What do you think about upload status.net package to experimental? Yeah, I was waiting for some manifestation of approval or otherwise from Evan or Brenda, but since nobody seems to have anything against it, I'll upload it in the coming week. Cheers -- Leo costela Antunes [insert a witty retort here] -- 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/4da2173a.9000...@debian.org
Bug#491723: Status.net Debian Package
Hi, First of all thanks for taking a look at the package! On 27/10/10 00:54, Brenda Wallace wrote: The previous repo was a clone of the main project, plus debian folder+Makefile. If you have a process for managing merging fixed, then no problem. you're going to put tarballs over top? I'm not sure if this is what you mean by tarballs, but I forgot to mention one thing: I never really understood the need for pristine-tar in git-buildpackage, so I left it out. AFAICT you can accomplish the exact same thing by exporting the upstream/X.Y.Z branch, but please let me know if there's actually missing functionality. Should be pretty easy to include the pristine-tars later on. I also didn't see any problem with the merging from upstream, but probably because I'm not working on a clone and instead using a simple git-import-orig to directly merge everything from the released tarball into the repo. I believe this is the sanest way to keep the debian repo, i.e. logically separate from the upstream repo. We just perform merges - actually imports - from upstream when there's a release, so debian packaging work and upstream development work have well defined boundaries. Working with apache+mysql outta the deb would be enough for first iteration. I'm a big lighttpd fan so i'll give it a test. Thanks! I personally use lighty too, but I just didn't get around to testing it yet. Having none of the daemons set up is reasonable. They become necessary when wanting to scale and/or add the fancy features. Perfect. This makes our lives significantly easier! :) I think you want to do a make clean, and then remove some compiled files from the git repo As mentioned above, I believe the best way to manage the debian repo is by importing upstream releases, keeping them as close as possible to the upstream state and keeping changes inside the /debian dir as much as possible. Specially since this makes for a more straightforward structure for people who want to work with or build the package directly from the orig.tar.gz + debian.tar.gz, instead of from the repo. This has the not-so-neat side-effect that some useless files which are included in the upstream tarball have to remain in the repo. I obviously don't mean to dictate other people's workflow and certainly don't want to alienate anyone from helping out with the packaging work, but the practicalities from a debian-maintainer perspective IMHO overweight the small size increase in the repo. Cheers -- Leo costela Antunes [insert a witty retort here] -- 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/4cc81f15.6030...@debian.org
Bug#491723: Status.net Debian Package
Hi again, On 23/09/10 14:28, Leo 'costela' Antunes wrote: Can we work together on this? Sure! Absolutely! Starting next week I'll take a look at the git.d.o code and see if I can help out with anything. I'll also be around #statusnet. After some delays, I've finally managed to sit down and work on the package. I have a very preliminary, though apparently fully-functional[0] version up here[1]. I also took the liberty of starting a new git-repo, currently here[2], just because I wanted a better notion of what had to be done (I did however take a lot of the files from the old repo). If you're ok with it, I'd replace the one currently in collab-maint with mine and we can all keep working together from there. There are still a couple of open questions: - how much automatization do we want with the configuration? I personally think the current level isn't that bad, that is: a single a2ensite statusnet.conf (in case of apache) is enough to have an instance working on localhost. I still haven't tested this with lighttpd though... - debian/copyright needs a big overhaul before any official upload (that's a boring part I didn't have enough willpower to tackle til now) - all libs in extlib which aren't currently separately packaged have been included in the binary. I don't think this is particularly bad, but the ftp-masters will obviously have the final word. Worst case scenario I could try packaging them all individually. - I'm unfortunately only very superficially familiar with statusnet, so I need some help sorting out what to do with all the scripts and pseudo-daemons in the package. Which of them do you think would be worth having work out-of-the box? (maildaemon, for instance, is something I think would probably be too hard to get right) I'd really appreciate some comments and tests. Cheers [0] haven't tested the plugins yet [1] http://people.debian.org/~costela/packages/ [2] git://git.debian.org/~costela/statusnet.git -- Leo costela Antunes [insert a witty retort here] -- 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/4cc4afbc.2060...@debian.org
Bug#600877: RFA: tedia2sql -- Converts a Dia diagram to various SQL dialects
Package: wnpp Severity: normal This package has been neglected for a while and upstream seems dead. Currently the upstream site shows a recommendation for users of Dia = 0.97 to use libparse-dia-sql-perl. The package has been removed from Squeeze on the grounds that it simply doesn't work with the released version of Dia and if nobody declares interest in maintaining it (which might include playing upstream) in the few months after the release from Squeeze, I'll probably request its removal. Cheers -- Leo costela Antunes [insert a witty retort here] -- 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/4cbf5d6b.7030...@debian.org
Bug#491723: Status.net Debian Package
On 23/09/10 04:57, Evan Prodromou wrote: So, I realize my previous email was too confrontational. Maybe a bit... :) I guess what I'm saying is there are some tough issues; I'd like to get them resolved; and it will take a number of people to do it. That's what I imagined. Don't take me wrong, I didn't assume it'd be easy or that you'd been slacking, it just seemed like the ITP could use a fresh and distanced look. After all, this isn't just some weekend project for you! :) Can we work together on this? Sure! Absolutely! Starting next week I'll take a look at the git.d.o code and see if I can help out with anything. I'll also be around #statusnet. Cheers -- Leo costela Antunes [insert a witty retort here] -- 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/4c9b47e4.7060...@debian.org
Bug#491723: Status.net Debian Package
Hey, Just another ping regarding the Status.net Debian package. The ownership of the bug has been bouncing around for the last few months without any visible manifestation of progress, so I thought I might try my hand at it, but before that I wanted to make sure there's no ongoing work by someone else. So, any concrete objections? Cheers -- Leo costela Antunes [insert a witty retort here] -- 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/4c9aa7fd.7000...@debian.org
Bug#566550: ITP: ttf-femkeklaver -- simple handwriting font
Package: wnpp Severity: wishlist Owner: Leo 'costela' Antunes cost...@debian.org * Package name: ttf-femkeklaver Version : 1.0 Upstream Author : Femke Klaver appelkruimelvlaaimetslagr...@hotmail.com * URL : http://www.1001fonts.com/font_details.html?font_id=3180 * License : CC-BY-SA 3.0 Description : simple handwriting font A simple handwriting font with strong repeated tracing. -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496586: Numptyphysics Debian package
Hi, Thank you both Thomas and Tim for taking the time to address my points! The package is currently being uploaded to Debian. I imagine your focus on the Maemo platform will mean most Debian bugs won't really interest you guys, but as long as I can muster up some platform-agnostic patches, would you consider them for inclusion? Case in point: I've already patched the source to optionally use fontconfig instead of the hardcoded font file (I'm distributing this font separately, though, to keep the game's visual identity intact). Another thing I'm working on is a patch to enable building with the system-wide libbox2d, but this still needs some work before it can be integrated. Would such changes be accepted? Thomas Perl wrote: 2) In order to be able to include it in Debian, we need the copyright statement for zoomer.cpp. It seems to be heavily based on this file[1], but I can't tell if you incorporated code from other sources. I don't know - Tim should be able to clarify this one. I was able to trace this file back here: http://www.ferzkopp.net/joomla/software-mainmenu-14/4-ferzkopps-linux-software/19-sdlgfx I have put a note to this effect in the Debian package, but it would be nice if you could include a standard license header to the file, tracing back its roots (LGPL 2.1, copyright Andreas Schiffer). Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496586: Numptyphysics Debian package
Hi, I'm trying to package Numptyphysics in Debian, but I've come across a few issues. 1) There doesn't seem to be a better way to contact the developers than personal emails. I though about emailing the list[0], but the fact that there is only one unresponded email with patches that didn't get included made me think this might not be the best idea. Is there any less intrusive way to get in contact which you eventually read/respond? 2) In order to be able to include it in Debian, we need the copyright statement for zoomer.cpp. It seems to be heavily based on this file[1], but I can't tell if you incorporated code from other sources. 3) This is not really a problem, but would be nice to have proper info in the AUTHORS, NEWS/ChangeLog and perhaps even README files. Hope you have a few minutes to answer. Thanks for your time! Cheers [0] https://garage.maemo.org/pipermail/numptyphysics-users/ [1] http://www.google.com/codesearch/p?hl=en#6GZ0CBipego/vendor/freesci/stable/src/wince/SDL_rotozoom.c -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496586: Numptyphysics status update
Hi, Just a status update on numptyphysics: Waiting for upstream's answer regarding the licensing of zoomer.cpp. Waiting for the femkeklaver.ttf font's upstream to re-license it, which seems possible, judging from the emails exchanged so far. The font has been split to a separate package, on which numptyphysics depends. Current preliminary signed packages available here: http://people.debian.org/~costela/packages/numptyphysics/ Gabriele, as you may notice, these packages have you set as Uploader. Should I keep it that way? :) Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496586: Processed: owner
[I'm re-adding the CCs to the bug logs, just to let people know what's going on. Hope that's not a problem.] Gabriele Giacone wrote: Sorry Leo, I thought that bug owner was Tobias. Any problems for you, if I take the ITP ? No problem, but how about co-maintaining? Have you gotten rid of the segfault problem on amd64? I checked it a couple of weeks back and there was absolutely no activity in upstream SVN... I'm afraid whoever takes this might have to do some heavy C++ patching eventually... Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562128: RFA: pearpc - PowerPC architecture emulator
Package: wnpp Severity: normal Hi, I haven't used this in years and it never really got to a very usable state. It's apparently dead upstream and the code-rot is probably severe. I plan to keep it on life-support, just to make the QA team's life a bit easier, but just the bare minimum. If it doesn't get taken up in a few months, I'll probably recommend its removal from the archive, considering its low popcons score. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543277: ITP: wiipresent -- control applications with your wiimote
To whom it may concern: Currently talking with upstream to make the build system more portable and trying to remove some hard-coded stuff before packaging. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543277: ITP: wiipresent -- control applications with your wiimote
Package: wnpp Severity: wishlist Owner: Leo costela Antunes cost...@debian.org * Package name: wiipresent Version : 0.7.5.2 Upstream Author : Dag Wieers d...@wieers.com * URL : http://dag.wieers.com/home-made/wiipresent/ * License : GPLv2 Programming Lang: C Description : control applications with your wiimote wiipresent is a program to control applications using your wiimote. It was originally developed for giving presentations with your wiimote, but can also be used to control your mouse-pointer and various applications. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543285: ITP: libwiimote -- a simple wiimote library
Package: wnpp Severity: wishlist Owner: Leo costela Antunes cost...@debian.org * Package name: libwiimote Version : 0.4 Upstream Author : Joel Andersson b...@kth.se, Chad Phillips c...@chadphillips.org * URL : http://libwiimote.sourceforge.net/ * License : GPLv2 Programming Lang: C Description : a simple wiimote library Libwiimote is a C-library that provides a simple API for communicating with the Nintendo Wii Remote (aka. wiimote). -- This is currently being pulled in by wiipresent's ITP[0]. [0] http://bugs.debian.org/543277 -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496586: i386 build?
Hi, jedd wrote: Any chance you could be so kind as to publish a i386 build in the interim? Okay if not, but much thanks if you can. Sure, I'll try to do it a bit later today. Please let me know if you encounter the same segfault I ran into. Is it weird that the build process isn't terribly Debian-friendly given this was a maemo app (and that's Debian-based). Maemo is only loosely Debian-based and it doesn't really enforce the same standards when it comes to the quality of packaging, specifically regarding portability, so you can actually get away with having a kludgy build-system that only works in very specific architectures and systems. But in this specific case it's not so bad, specially since upstream did a complete revamp of the build-system. As a side note, I still haven't heard back from upstream and still lack the time to debug the C++ code myself (I'm not particularly fluent with C++), so it might take a while to get this package in... Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490438: ITP: libawl-php -- Andrew's Web Libraries - PHP Utility Libraries
Hi, Is there a reason for this bug to be open? It should have been closed by the first upload of AWL[0], right? Cheers [0] http://packages.qa.debian.org/a/awl.html -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496586: Status
For the record, I decided to package SVN trunk cause it already has a revamped build-system (perhaps the one made by Miry?) and am currently waiting on feedback from upstream regarding a show-stopper segfault. Preliminary semi-working packages, patched to use the system-wide version of libbox2d, are available here: http://people.debian.org/~costela/packages/numptyphysics Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496586: numptyphysics -- crayon based physics puzzle game
Hi Miry, Yaroslav, I see you guys haven't really talked about numptyphysics for a while. Are any of you still interested in packaging it? If it's ok with you, I'd try packaging it, even though I've just taken my first look at the code. Miry, you said you had almost-working packages. How far did you get? Did you go around the hard-coded Makefile? I considered remaking the build-system and sending it upstream, but I have no idea how receptive he'd be, considering the apparently aggressive optimizations made specifically for the Maemo platform... Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513846: ITP: pidgin-awayonlock -- pidgin plugin to set as away on screensaver activation
Hey, Jon Dowland wrote: One way to achieve the same thing is to set a buddy pounce on yourself which activates when you change status and triggers a shell script that invokes gnome-screensaver-command --lock or xscreensaver-command -lock or whatever. Harder is setting status back to available when you unlock. That's an interesting idea, but it means - if I got it right - pidgin activates gnome-screensaver and not the other way around. This has the problem of having to get used to two different actions to lock your screen, depending on whether pidgin is active or not. Cheers -- Leo costela Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513846: ITP: pidgin-awayonlock -- pidgin plugin to set as away on screensaver activation
Package: wnpp Severity: wishlist Owner: Leo costela Antunes cost...@debian.org * Package name: pidgin-awayonlock Version : 0.1 Upstream Author : Leo costela Antunes l...@costela.net * URL : http://costela.net/projects/awayonlock * License : GPL-3 Programming Lang: C Description : pidgin plugin to set as away on screensaver activation Away-on-Lock is a simple plugin for pidgin (or any other libpurple-based IM client) to change your status when the screensaver gets activated. It currently supports only gnome-screensaver. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#502799: ITP: python-beepy -- implementation of the Blocks Extensible Exchange Protocol (BEEP)
Package: wnpp Severity: wishlist Owner: Leo costela Antunes [EMAIL PROTECTED] * Package name: python-beepy Version : 0.6.2 Upstream Author : Justin Warren [EMAIL PROTECTED] * URL : http://beepy.sourceforge.net/ * License : MIT Programming Lang: Python Description : implementation of the Blocks Extensible Exchange Protocol (BEEP) BEEPy is a python implementation of the Blocks Extensible Exchange Protocol. It makes use of the twisted framework to provide low-level socket communication over TCP. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489320: ITP: trac-accountmanager -- Account management plugin for Trac
Package: wnpp Severity: wishlist Owner: Leo 'costela' Antunes [EMAIL PROTECTED] * Package name : trac-accountmanager Version : 0.11 Upstream Author : Matthew Good * URL : http://trac-hacks.org/wiki/AccountManagerPlugin * License : THE BEER-WARE LICENSE Programming Lang: Python Description : Account management plugin for Trac Offers several features for managing user accounts: - allow users to register new accounts - login via an HTML form instead of using HTTP authentication - allow existing users to change their passwords or delete their accounts -- end description -- This wnpp bug will be blocked by #463201, since I intend to package it for Trac 0.11 only (else I'd have to package the WebAdmin module, which is included in 0.11) Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Bug#427474: Some work done
tags 427474 help -- Hey, I've got a preliminary version up[0], but I'm running into a very strange problem. It doesn't run until I #touch /usr/share/python-support/gourmet/gourmet/gglobals.py The error reported before the touch is: error Traceback (most recent call last): File /usr/bin/gourmet, line 34, in ? import gourmet.GourmetRecipeManager File /var/lib/python-support/python2.4/gourmet/GourmetRecipeManager.py, line 5, in ? import keyEditor, valueEditor, batchEditor File /var/lib/python-support/python2.4/gourmet/batchEditor.py, line 4, in ? import ratingWidget, timeEntry, cb_extras File /var/lib/python-support/python2.4/gourmet/ratingWidget.py, line 144, in ? star_generator = StarGenerator() File /var/lib/python-support/python2.4/gourmet/ratingWidget.py, line 45, in __init__ self.set_img = Image.open(set_image) File /usr/lib/python2.4/site-packages/PIL/Image.py, line 1888, in open fp = __builtin__.open(fp, rb) IOError: [Errno 2] No such file or directory: '/var/share/gourmet/gold_star.png' /error I couldn't figure out the problem so I'm giving up for now. If I get any leads on this I'd gladly take this up again. Cheers [0] http://people.debian.org/~costela/ -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Bug#465204: ITP: fusil -- Fuzzing program to test applications
Pierre Chifflier wrote: Fusil project is a fuzzing program for any project type (remote process, fake HTTP server, fuzz network socket, etc.). Fusil implementation is based on multi-agent system architecture. Fusil is able to crash ClamAV, Image Magick, libc printf(), Mplayer, PHP, RPM, xterm, libc gettext, libc environment variables, libpoppler (pdf), vim, etc Just my $0,2: I don't think it's practical, and maybe misleading, to cite a list of current application against which fusil can cause a crash. This list seems too volatile to be of any real use. Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent
John H. Robinson, IV wrote: Joerg Jaspert wrote: There are *way* better MTAs [than qmail] out there that dont need tons of patches applied just to fulfill basic requirements for a MTA. No, there are not. There are certainly many others that don't need patches to fulfill basic requirements for an MTA, but whether they are better or not is irrelevant for us, given Qmail's level of widespread adoption. There's no discussion that there are still many people interested in having it available. After all, it's not like it's a 100 line C program with 10 totally compatible alternatives... unfortunately! :-) Cheers. -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Bug#453680: ITP: djbdns -- Replacement for BIND, written by Dan Bernstein
[cc'ing Adam to bring this to the bug log] Robert Edmonds wrote: Supposedly DJB has released all of his code into the public domain. If this is really the case and passes DFSG, I plan to package djbdns assuming Adam McKenna (maintainer of djbdns-installer) doesn't want to. Perhaps you could have talked to Adam before filling an ITP? You could even arrange some sort of co-maintainance, if you already have some work done. And just for the record, to back your claims, as of now Qmail's page[0] says: I hereby place the qmail package (in particular, qmail-1.03.tar.gz, with MD5 checksum 622f65f982e380dbe86e6574f3abcb7c) into the public domain. Cheers and good luck with the package [0] http://cr.yp.to/qmail/dist.html -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Bug#404862: libical status
Hi, Are there any news regarding this package? Could it possibly be uploaded alone, before Citadel? My package (gnokii) has a feature that depends on this lib and I wanted to enable it if possible. Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Bug#404862: libical status
Fathi Boudra wrote: submitted to my sponsor today: http://fboudra.free.fr/debian/libical_0.27-1/ you can expect to have it soon in the archive. Thanks! If your sponsor is - for whatever reason - unable to do it, just let me know and I can sponsor it for you! Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Bug#374088: Status?
Hi,What's the status of this package? Why was it rejected from the NEW queue?Is there something you could use some help with?Cheers-- Leo Antunes [EMAIL PROTECTED] | [EMAIL PROTECTED]
Bug#322091: Bluefish
On Qui, 2005-08-25 at 02:33 +0200, Daniel Leidert wrote: But that was not the problem you mentioned at the beginning of this discussion. My upstream archive contained the directory 'bluefish-1.0.3.orig' (which is normal, see e.g. cvs-buildpackage or dh_make), the upstream tarball the directory 'bluefish-1.0.3'. This made the difference in size, not the fact, that I run aclocal or autoconf. I run them during the rules/clean target. Of course, I can avoid this. But normally I like to have updated scripts. To not increase diff's size, I can run it, before I run dh_make. That is common practice. But then you will not be able to build the package against the upstream tarball. (...) In general, I have no problem with that. This practice follows suggestions in /usr/share/doc/autotools-dev/README.Debian. I can change to run it only once. But then I have to do it, before I start the packaging process (means: before I run dh_make). But in this case, your practice, to build the package against the upstream tarball and not the .orig.tar.gz will fail. You've been avoiding the main point. It doesn't matter what lesser reasons you have, if you don't strictly NEED to repackage it, DON'T do it. See Policy 4.3 or the recent email to d-d-a[1]: quote * Do not repackage your orig.tar.gz unless you have to. If you need to remove files due to license issues - OK. But for example to have the directory in the tarball named pkgname-ver you DO NOT repackage. dpkg-source completly doesn't care for that. /quote And the fact is, as I quickly proved by packaging it myself: you don't NEED to repackage, you don't NEED to re-automake/libtoolize/etc it. It works perfectly without ANY of these. Keeping the diff size down is not a strong enough argument to warrant any change to source and running automake/libtoolize/etc in the clean target is one of the perfect situations to screw the autobuilders, so it's also something to whatch out for. And as a side note, dh_make is not supposed to be used everytime with new upstream, it's supposed to be used once at the first package creation and then use other tools to update the upstream source, like uupdate or even manually (my case). Cheers [1] http://lists.debian.org/debian-devel-announce/2005/08/msg00011.html -- Leo Antunes [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#322091: Bluefish
On Ter, 2005-08-23 at 04:15 +0200, Daniel Leidert wrote: Uploaded to my server. See http://debian.wgdd.de/temp/bluefish/ for source files. debian/control states, that you are the Uploader. Has this package been generated with a different source file? I tried using the source file from the official site and it bails because of a size difference. Can you re-build it with the pristine sources? Cheers -- Leo Antunes [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#322091: Bluefish
On Ter, 2005-08-23 at 23:14 +0200, Daniel Leidert wrote: Never seen this practice before. And it can be problematic, if you think about the practice of handling outdated automake/autoconf/intltool/gettext scripts/files. One possibility to handle this situation is, that the necessary applications are run once in the upstream source _before_ beginning the packaging process. So the scripts can be updated without increasing the size of the diff.gz. In this case, your practice will always fail. You shouldn't need to run anything other than './configure make make install' (with a few tweaks) on a recently extracted tarball to install it system-wide. Automake/autoconf/intltool/etc, should be run _prior_ to release, and shouldn't be outdated (but if they are, that's an upstream problem, not Debian, even though we can - and some times should - work around it). The original tarball generates a perfect package with very simple changes, take a look at: http://people.debian.org/~costela/debian/ You can download the dsc, diff and changes files from this site and the tarball from upstream and run 'dpkg-source -x bluefish_1.0.3-1.dsc'. It's clean, simple and cruft-free[1]. And already has you set up as the maintainer. BTW, since you have upstream access, it would be a good idea to remove the Debian dir from releases, as soon as possible. Cheers [1] The debian directory only needs these files: README.Debian, bluefish.manpages, compat, copyright, rules, bluefish.1, changelog, control, patches. The rest is left-over from upstream, since diff doesn't handle deleted files (illustrating another good reason not to have the /debian dir upstream) -- Leo Antunes [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#322091: Bluefish
On Qua, 2005-08-10 at 16:25 +0200, Daniel Baumann wrote: Just one hour ago, I did the 1.0.2 package, I'll upload it to my webserver when I come home this evening :) However, I would like to maintain it for real, so can I persuade you for a co-maintainership? Independently from that, I would be happy if you can sponsor the upload, as my normal sponsor is very busy atm. Well, we got a mess here... I uploaded 1.0.2 last night, as my last NMU for Evo, before he proposed for me to take over the package. So you're gonna have to wait till the next version to take this over. Even so, I'll gladly take a look at your package anyway, let me know when it's up. I don't think this package is complicated enough to actually need co-maintainership, but it wouldn't harm. We can look at it again when a new version pops up, or some new bug comes along. Cheers -- Leo Antunes [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#322091: Bluefish
[it took me a while to understand it was a different 'Daniel' ;-) ] On Qua, 2005-08-10 at 18:48 +0200, Daniel Leidert wrote: Short advice: The source contains obsolete bluefish_icon1.xpm and doubled (bluefish.)postinst and (bluefish.)postrm. Cool, I didn't want to step on Evo's shoes by removing stuff I didn't think was usefull (but could have been somehow), so this cleaned up version could be your first official upload. 1.0.3rc1 is out. I don't think it's a good idea to upload RC-level versions, unless you're pretty sure these versions are just for really minor bug solving. Else they might end up generating unecessary and duplicated bug reports, IMHO. But I would suggest an alternative solution: I am member of the upstream authors team and I am maintaining the Debian packaging files since a while. Further I (try to) fix the mentioned bugs for bluefish directly in the upstream. It is really no big deal to package bluefish. So maybe it is a good or even the best solution, if I take over the maintainership, because I am directly involved in upstream. I am no DD so I would need a sponsor. If you have questions about my skills, please ask. My (unofficial) packaging work for Debian can be found at http://debian.wgdd.de/debian/. Please think about this offer and tell me your opinion. In this case I think it's really a good idea for you to be the maintainer. OTOH, it's generally regarded[1] as the best option not to include the debian dir upstream, so it would be nice to remove it, if possible. Is the version on your (Daniel Leidert's) site already cleaned up? Just as a side question: Daniel Baumann is already in queue to become a DD, what about Daniel Leidert? This is not really important, it's mainly just curiosity so I can understand the future 'modus operandi' for the uploads (Will I - or any other DD, for that matter - have to sponsor each and every upload?). Cheers [1] allright, I'm to lazy to find the links to the discussions regarding this, but I can find it if you rally want to know =] -- Leo Antunes [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#322091: Bluefish
On Qua, 2005-08-10 at 21:48 +0200, Daniel Leidert wrote: Is the version on your (Daniel Leidert's) site already cleaned up? These packages always contain some additional stuff (to send bug-reports regarding my packages to me and not to the official BTS). The files in the upstream source should be clean, so you only need to add a new Changelog entry. Allright then, when you get a clean version for upload into Debian, just let me know and I'll sponsor it, no problem. ...As long as I'm free to bug you about new versions, just like I did with Evo (and ended up building and uploading them myself, anyway) :-) Cheers -- Leo Antunes [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#248783: ITP: pearpc -- Architecture-independent PowerPC platform emulator
On the site they have this kind of information. Cheers On Dom, 2004-05-16 at 21:49, Dan Weber wrote: Leo Costela wrote: Package: wnpp Severity: wishlist * Package name: pearpc Version : 0.1 Upstream Author : Sebastian Biallas [EMAIL PROTECTED] * URL : http://pearpc.sourceforge.net * License : GPL Description : Architecture-independent PowerPC platform emulator PearPC is an architecture-independent PowerPC platform emulator capable of running most PowerPC operating systems. Supported host platforms: POSIX-X11 (Linux, ...), Win32 How is general performance? Any screenshots? Dan Weber -- Leo Costela [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] you must cut down the mightiest tree in the forest... with... a herring! signature.asc Description: This is a digitally signed message part
Bug#243838: ITP: knockd -- Small port-knocker server
On Qui, 2004-04-15 at 07:10, Hamish Moffatt wrote: Leo, is it specific to Ethernet interfaces? If not it would be better to say network interface than ethernet. Yes, the code is specific to ethernet or at least uses ethernet headers, for now. I'm actually doing some heavy patching to add some other features, but making it link-layer protocol independent is not on my list, yet. It might be on upstream's, though. Thanks for pointing that out anyway, I hadn't even thought of the possibility of using it through other mediums. Cheers -- Leo Costela [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] you must cut down the mightiest tree in the forest... with... a herring! signature.asc Description: This is a digitally signed message part
Bug#243838: ITP: knockd -- Small port-knocker server
On Qui, 2004-04-15 at 10:14, Hamish Moffatt wrote: That is surprising given that it is looking for certain TCP or UDP packets. It's actually a small change, but I don't feel like doing it right now ;-) There are other interfaces where it might be useful especially ppp. Agreed, I'll look into it, if upstream doesn't beat me to it AND if he accepts my patches (my first package is patched during Debian packaging, but I sent it upstream, hopefuly it'll be incorporated) FYI, I've made packages available at: http://people.costela.org/~costela/ They'll probably stay there for some days before being uploaded to the official archive. Cheers -- Leo Costela [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] you must cut down the mightiest tree in the forest... with... a herring! signature.asc Description: This is a digitally signed message part
Bug#202419: any idea of hwen this will be uploaded?
Hi AM! =] I'm really delayed with this package, because of real-life issues, but I think I'll have it up at http://people.d.o/~costela/ by the weekend (I had promised upstream it would be up LAST weekend... =/ ...) I'll let you know when it hits the web! Cheers On Thu, 2003-08-28 at 06:49, Martin Michlmayr wrote: * Jordi Mallach [EMAIL PROTECTED] [2003-08-28 11:11]: Hi Leo, My brother just got a webcam. Do you have packages ready? If so, can you upload them or provide an URL? [EMAIL PROTECTED] does not copy the submitter, hence I'm mailing -submitter now. -- Leo Costela [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] Key Fingerprint: 8AE6 CDFF 6535 192F B5B6 5921 2262 D36F 7ADF 9466 you must cut down the mightiest tree in the forest... with... a herring! signature.asc Description: This is a digitally signed message part
Bug#206421: ITP: gaim-encryption -- Gaim plugin that provides transparent RSA encryption
On Qui, 2003-08-21 at 10:00, Philippe April wrote: Hello, Hi I'd be interested to know how you will be packaging this, I was thinking about doing it as a first package to.. eventually become a DD (because I use gaim extensively every day) but thought it wasn't possible to package this one because it needs gaim's source code to compile... Please keep me posted with the details of how you're doing it, I'm very interested to know :) I might have more plugins for gaim in the future and would like to use the same architecture. For now, I'm still patching Gaim and making a private deb at my repository[1], but since Gaim's about to split libs and UI, I'm already looking into another packaging scheme. Gaim-encryption, since 2.06 doesn't need the patching anymore and it's only a matter of time before it doesn't need the whole source tree, when that happens I'll repackage it, or, if you're really interested, you could do it too! Just remember to talk to Robert McQueen [EMAIL PROTECTED] for guidelines you should follow when packaging Gaim plugins, once that becomes possible. Cheers [1] http://people.debian.org/~costela/debian -- Leo Costela [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] Key Fingerprint: 8AE6 CDFF 6535 192F B5B6 5921 2262 D36F 7ADF 9466 you must cut down the mightiest tree in the forest... with... a herring! signature.asc Description: This is a digitally signed message part
Bug#191420: ITP: gnome-velocity -- A light file manager for GNOME2
Package: wnpp Version: unavailable; reported 2003-04-30 Severity: wishlist * Package name: gnome-velocity Version : 0.1alpha Upstream Author : Kyle Davis [EMAIL PROTECTED] * URL : http://velocity.sf.net * License : GPL Description : A light file manager for GNOME2 Velocity is a file manager for the GNOME 2 Desktop environment. It is designed to be fast, efficient, and very powerful. As a file manager it offers many advanced and unique features such as: View profiles, Context menu image previewing, Plugins, and much more. . Velocity was known as GFileRunner, until it reached version 0.3.5 -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux wisdom 2.4.18 #4 Qua Jan 22 19:27:15 BRST 2003 i686 Locale: LANG=C, LC_CTYPE=pt_BR -- Leo Costela [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] Key Fingerprint: 8AE6CDFF6535192FB5B659212262D36F7ADF9466 you must cut down the mightiest tree in the forest... with... a herring! signature.asc Description: This is a digitally signed message part
Bug#191420: ITP: gnome-velocity -- A light file manager for GNOME2
severity #191420 wishlist thanks I don't know why it was filled as Normal... it didn't recognize wishlist as a valid value for the Severity pseudo-header... Any hints? Cheers PS.: CC me, I'm not on d-devel -- Leo Costela [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] Key Fingerprint: 8AE6CDFF6535192FB5B659212262D36F7ADF9466 you must cut down the mightiest tree in the forest... with... a herring! signature.asc Description: This is a digitally signed message part
Bug#184923: ITP: Gmodconfig
Hi I just wanted to know if you still intend to package this software, cause IMO it's really useful and you seem to have forgotten about it. Don't get me wrong, but you have filled ITP's on 4 pieces of software and really packaged none. I really encourage you to package things for Debian, but I think you might wanna take it slower, ITP one package at a time and really do it for a change (and do it right, of course, remember you'll have to look after all these packages after they enter the archive, that's a lot of responsability). If you're still working with the packages, nevermind this email and good luck. If you need a sponsor for Gmodconf (I assume you're not yet a DD) contact me and we can look at it. Cheers -- Leo Costela [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] Key Fingerprint: 8AE6CDFF6535192FB5B659212262D36F7ADF9466 you must cut down the mightiest tree in the forest... with... a herring! signature.asc Description: This is a digitally signed message part
Bug#189358: ITP: icukrell -- GKrellm plugin which shows the status of GnomeICU
Package: wnpp Version: unavailable; reported 2003-04-16 Severity: wishlist * Package name: icukrell Version : 2.0.0pre0.1 Upstream Author : drJeckyll [EMAIL PROTECTED] * URL : http://icukrell.sourceforge.net/ * License : still unknown (waiting author's answer) Description : GKrellm plugin which shows the status of GnomeICU This plugin gathers information from a running session of GnomeICU and shows it in a Krell. -- Leo Costela [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] Key Fingerprint: 8AE6CDFF6535192FB5B659212262D36F7ADF9466 you must cut down the mightiest tree in the forest... with... a herring! signature.asc Description: This is a digitally signed message part
Bug#142009: SashXB is dead upstream?
I think SashXB is dead upstream because IBM has stoped it's backing. If that's true it's not gonna get anywhere in the near future, unless someone (or some entity, like Gnome) takes on the development. I think this RFP will remain here for a lot of time... Cheers -- Leo Costela [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] Public Key: http://wallsplash.net/leo/pubkey.asc you must cut down the mightiest tree in the forest... with... a herring! signature.asc Description: This is a digitally signed message part
