[gentoo-dev] last rites: net-im/ohphone
Hi, net-im/ohphone has just entered package.mask and will be removed after 30 days because I've lost interest in the package a year or so ago and no one has stepped up to take it. A possible alternative is net-im/ekiga. Related bug: http://bugs.gentoo.org/show_bug.cgi?id=105670 Thanks, Alastair -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paid support
On Sat, 2006-09-02 at 23:00 +0100, Stuart Herbert wrote: On 9/2/06, Donnie Berkholz [EMAIL PROTECTED] wrote: It might be worth putting together a list of folks interested in doing this on the Gentoo website, under a Third-party Paid Support section. We already have a Support link on the top of www.g.o, it could be on that page. We'll also need to sort out a process for handling complaints against developers from the folks they help. Doesn't matter how well we make it clear that these folks are independent; their actions will reflect on Gentoo as a whole, and unhappy customers _will_ complain to us sooner or later. Rather than pretent it won't happen, better we're pro-active and have something prepared. I think this is a great idea. If not for paid support, but just a list of names of developers who are willing to do some freelance consulting on setting up machines with Gentoo or to debug a problem, etc. I'm sure there are people who have ended up with a Gentoo machine, but can't hire a full time dev and would just like to pay someone to handle certain issues. I landed some freelancing where one of the reasons I was found was because I did work for Gentoo, and they have some gentoo servers that needed to be setup properly and securely. I'm putting my hand up to help set this up if it is more effort than putting up a single page on the web site :) Cheers, Alastair -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last Rites app-pda/rapip
Hi all, app-pda/rapip has been masked and is pending removal from the portage tree. Upstream has stopped maintaining this and I believe that kpilot and others are a good replacement for it. Due to the lack of man power and my general lack of interest with anything that requires KDE, I am removing this from the tree. Hopefully this doesn't affect many, but if it does, please scream out and we can sort something out. Cheers, Alastair -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]
On Wed, 2006-08-16 at 13:18 +0200, Simon Stelling wrote: Enrico Weigelt wrote: I already suggested an bug-reporting tool, which automatically collects all the necessary data, several weeks ago. This tool is simply called by commandline and asks the users several questions. Then it files an bug with some certain syntax and uploads necessary information (emerge --info, pkg-db extracts, ...). That somehow looks like the guided file-a-new-bug form we had some time ago. Personally, I'd rather have it in bugzilla, because a shell tool takes the user away from bugzilla, and after all you have to search for existing bugs anyway, so you already are on bugzilla. Somehow I believe that most people will encounter bugs when on the command line, so being able to search/post in bugzilla from the command line is a pretty natural extension. Using PyBugz as an example, typing this after an emerge plptools fails is much easier than opening firefox, typing bugs.gentoo.org, finding the search page and typing the package name in the search box in: bugz search plptools PyBugz actually has a 'bugz post' option that I've only used a couple of times, but it actually prompts the user to submit their emerge --info. Cheers, Alastair -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)
On Fri, 2006-07-28 at 11:51 -0700, Donnie Berkholz wrote: Robert Cernansky wrote: If I have some application that is not included in portage why I decide to make an ebuild? Because I hope that then it will be accepted and included to portage, so maintained by developers (big thanks for this). If I have to take care of package + ebuild + dependencies, I'll rather choose not to make an ebulid but compile package right from .tar.gz archive. Many people disagree with you here, that's why overlays exist. Somebody wants to use Portage to manage ebuilds that aren't yet in the actual tree. I have to say I agree with Donnie here on this. I've been using private ebuilds for certain things that are installed on my work systems that will never be applicable to anyone except for 4 people on this planet. Yet I use these because then I'm able to take this simple single file, plonk it into another Gentoo machine and recreate the same installation. Maybe it is just because making ebuilds is now just second nature to me. Look at my overlay at the moment, half the stuff there have a less than 30% chance of ever making it into the main portage tree. But I still make those ebuilds in the off chance that either (a) I do decide to put them in, or (b) someone else might stumble across them and find it, and (c) there are just things that I cannot test because I don't have the hardware. Proxy-dev and sunrise are completely different things. But both are trying to decrease the steps needed to contribute to open source, so in my book, that is a good thing. Cheers, Alastair -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] sys-libs/slang - call for maintainer
On Wed, 2006-07-19 at 15:52 +0200, Jakub Moc wrote: Hello everyone, I've filed a bug about slang-2 version bump [1] more than one year ago. As it hasn't moved anywhere, I'm sending a call for maintainer here. It's a pretty important bump for UTF-8 compatibility and is really needed to get rid of those hackish slang UTF-8 patches in stuff like app-misc/mc that just tend to break stuff. Just a bit of background since I'm listed as the maintainer. I took an interest in this package because it was a direct dependency on a package I maintained, app-editors/jed. Then CJK came along and applied a bunch of patches and somewhere along the line, CJK became the primary maintainer because no one else would. As for slang-2, there was no immediate package that required version 2, and I could never get the submitted ebuilds to compile for me, so I left the bug alone. I would be grateful for someone to take over this who might have more of an interest in this library as CJK isn't exactly the most manned herd around. Just a note for any future maintainers, app-editors/jed-0.99.16 will not work with slang-2. I believe the newer version that was released in April will (although I only just found out about this release today.) Cheers, Alastair -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pybugz - python command line interface to bugzilla
On Mon, 2006-07-17 at 11:28 +0100, Chris Bainbridge wrote: On 16/07/06, Alastair Tse [EMAIL PROTECTED] wrote: Hi All, As a little weekend project, I wrote a command line interface to bugzilla in Python that is targetted to Gentoo's bugzilla (but also generalisable to other bugzillas with a little code modification). It can do the following: You might like to have a look at Redhat's bugzilla. There's a xml-rpc interface (not sure if the patches are redhat specific or upstream) that allows you to do these kind of things. There are also some command line and gui tools that utilise the xml-rpc api. That must be their own extension to bugzilla because a quick grep of the sources on bugzilla.org doesn't reveal anything about XML-RPC. They're even using 2.18, which is a little older than what we're using on bugs.g.o. Cheers, Alastair -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] pybugz - python command line interface to bugzilla
Hi All, As a little weekend project, I wrote a command line interface to bugzilla in Python that is targetted to Gentoo's bugzilla (but also generalisable to other bugzillas with a little code modification). It can do the following: * search bugzilla and output a table of bugs: bugz search keyword * list bug details (incl comments and attachment): bugz get bugid * get attachments: bugz attachment attachid * post attachments: bugz attach bugid filename * modify bug: bugz modify bugid -c here is a new comment --fixed I know there's gentoo-bugger, which is great, but it's in perl and I couldn't figure out how to modify the output to suit my needs. Here's the README attached if you're interested in how it might work for you to become more efficient when dealing with Gentoo's Bugzilla. You can get it either via my portage overlay in: http://overlays.gentoo.org/svn/dev/liquidx/app-admin/pybugz or as a python distutils compat tarball in http://media.liquidx.net/static/pybugz/pybugz-0.5.tar.gz Hope maybe some people might find it useful. Cheers, Alastair PyBugz - Python Bugzilla Interface -- Bugzilla has a very inefficient user interface, so I've written a command line utility to interact with it. This is mainly done to help me with closing bugs on Gentoo Bugzilla by grabbing patches, ebuilds and so on. Author -- Alastair Tse [EMAIL PROTECTED]. Copyright (c) 2006 under GPL-2. Features * Searching bugzilla * Listing details of a bug including comments and attachments * Downloading/viewing attachments from bugzilla * Posting comments, and making changes to an existing bug. * Adding attachments to a bug. Usage/Workflow -- PyBugz comes with a command line interface called bugz. It's operation is similar in style to cvs/svn where a subcommand is required for operation. To explain how it works, I will use a typical workflow for Gentoo development. 1) Searching bugzilla for bugs I can fix, I'll run the command: --- $ bugz search version bump --assigned [EMAIL PROTECTED] * Using http://bugs.gentoo.org/ .. * Searching for version bump ordered by number 101968 liquidx net-im/msnlib version bump 125468 liquidx version bump for dev-libs/g-wrap-1.9.6 130608 liquidx app-dicts/stardict version bump: 2.4.7 2) Narrow down on bug #101968, I can execute: - $ bugz get 101968 * Using http://bugs.gentoo.org/ .. * Getting bug 130608 .. Title : app-dicts/stardict version bump: 2.4.7 Assignee: [EMAIL PROTECTED] Reported: 2006-04-20 07:36 PST Updated : 2006-05-29 23:18:12 PST Status : NEW URL : http://stardict.sf.net Severity: enhancement Reporter: [EMAIL PROTECTED] Priority: P2 Comments: 3 Attachments : 1 [ATTACH] [87844] [stardict 2.4.7 ebuild] [Comment #1] [EMAIL PROTECTED] : 2006-04-20 07:36 PST ... 3) Now this bug has an attachment submitted by the user, so I can easily pull that attachment in: - $ bugz attachment 87844 * Using http://bugs.gentoo.org/ .. * Getting attachment 87844 * Saving attachment: stardict-2.4.7.ebuild 4) If the ebuild is suitable, we can commit it using our normal repoman tools, and close the bug. --- $ bugz modify 130608 --fixed -c Thanks for the ebuild. Committed to portage or if we find that the bug is invalid, we can close it by using: $ bugz modify 130608 --invalid -c Not reproducable Other options - There is extensive help in `bugz --help` and `bugz subcommand --help` for additional options. bugz.py can be easily adapted for other bugzillas by changing BugzConfig to match the configuration of your target bugzilla. However, I haven't spent much time on using it with other bugzillas out there. If you do have changes that will make it easier, please let me know.
Re: [gentoo-dev] pybugz - python command line interface to bugzilla
On Sun, 2006-07-16 at 20:33 +0200, Jakub Moc wrote: Alastair Tse wrote: You can get it either via my portage overlay in: http://overlays.gentoo.org/svn/dev/liquidx/app-admin/pybugz or as a python distutils compat tarball in http://media.liquidx.net/static/pybugz/pybugz-0.5.tar.gz Cool! Any reason why not commit it - at least package.masked? ;) None really, except I don't like committing my own code to the tree. But I do plan to commit it to the tree once I iron out any bugs there are out of it. Cheers, Alastair -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [gentoo dev]suggestion to distutils eclass
On Mon, 2006-07-17 at 00:49 +0800, Zhang Le wrote: Some packages don't provide standard setup.py. Take a look at the attachment. This is a new ebuld. I agree with Stefan, just put a symlink in from whatever their distutils install script is to setup.py in src_unpack(). This seems to be such a rare corner case that it isn't worth adding extra complexity in. Cheers, Alastair -- gentoo-dev@gentoo.org mailing list
