Re: ..d-u support sponsorships, was: Problem with ppp keeping link up
--- Arnt Karlsen <[EMAIL PROTECTED]> wrote: > On Tue, 12 Oct 2004 11:41:25 -0700 (PDT), Mike wrote in message > <[EMAIL PROTECTED]>: > > > > --- [EMAIL PROTECTED] wrote: > > > > > I note that back in Jan 2003, someone had the same problem but got > > > no response on the debian-user mailing list. > > > > > It's good too see that this list is functioning and there are ppl > > around to answer questions. As for the debian-user list I don't have > > enuff time to listen in for network related questions and direct them > > to here. I hope that some/any one would be kind enuff todo so and > > encourage other to take the time todo so, when time is avalible. > > > > Dito for debian-devel and any other list. > > ..how about sponsorships? You can easily spend a 16 hour working day > at d-u to keep up with it, and face it, _somebody_ has to pay for all > that time. As I write this, I have 30470 unread of 67172 since joining > d-u in August last year until wisening up the same way Lawrence Lessig > did in January this year, bills to pay and Groklaw.net, FlightGear.org > and IPCop.org. > How about breaking up the list in to several smaller lists, like debian-fierwall. For today the names like debian-user1 and debian-user2 could be used to provide at least some level of maintanable/readable material. I don't know how many mails a day the d-u lists gets, but I'm guessing more then 16 a day is too many. > -- > ..med vennlig hilsen = with Kind Regards from Arnt... ;-) > ...with a number of polar bear hunters in his ancestry... > Scenarios always come in sets of three: > best case, worst case, and just in case. > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > __ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com
debian/rules VS debian/copyright.
I'm really a horrible person and I'm excellent at writing files like debian/rules. From my perspective it's perfectly clear that a simple tool designed to write perfect debian/rules files would have no chance at writing a debian/copyright file. I understand that for decades there has been a large group of hard working individuals that excel at writing both. I'd like to point out a need, and a desire on my part, for this to change. I've been told that in order to write a good debian/copyright one must have interment knowledge of a package and therefore be part of the packaging team. I fail to see how the two relate, there is a lot more that goes into a package then just the debian/copyright and unlike the debian/rules it stands alone as it doesn’t interface with any other part of the Debian Package, excepting that the original source is not part of the Debian Package(at least in this instance). Both files interface with the original source, but that's where the similarities end. I've also been told that having a single maintainer responsible for the package as a whole is a good idea. I say one can easily split technical and legal responsibility without the need for any gray lines. Doing so reduces the knowledge base, an important part of finding the right ppl. Allowing for more knowledgeable technical writers, like myself, to write excellent packages and debian/rules files further improving the quality of Debian. 1. I see a clear benefit. 2. I see a long road ahead. 3. I see an eventual finish where Package Maintainers and Helpers can either focus on debian/rules or debian/copyright without the need to be familiar at all with the other. I offer up this edit for your review. I understand many might hate and oppose the idea of splitting the two. Thank you. Index: english/intro/help.wml === RCS file: /cvs/webwml/webwml/english/intro/help.wml,v retrieving revision 1.11 diff -u -r1.11 help.wml --- english/intro/help.wml 11 Apr 2010 13:38:53 - 1.11 +++ english/intro/help.wml 22 Mar 2012 00:54:17 - @@ -1,7 +1,9 @@ #use wml::debian::template title="How can you help Debian?" -If you are considering helping in the development of Debian GNU/Linux -there are many areas in which both experienced and inexperienced users can assist: +As a "Net-New" User + +New users can start right away, even with out installing or intending +to use Debian. Though it's a good idea to at least try it once. # TBD - Describe requirements per task? # such as: knowledge of english, experience in area X, etc.. @@ -14,13 +16,34 @@ the bugs associated with packages you use and provide further information, if you can reproduce the issues described in them. -# TBD - link to users mailing lists -# Translators, link directly to the translated mailing lists and provide -# a link to the IRC channel in the user's language -If you are an experienced user you can help other users through -the http://lists.debian.org/";>user mailing lists or -by using the IRC channel #debian. For more information on support options -and available sources read the support pages. +Help Debian keep track of your favorite applications in the +Work-Needing and Prospective Packages lists. + +# TBD - favorite features +# Currently I'm unaware of a place to suggest "Better support for socks5" +# + +You can help with the development of the public face of Debian and +contribute to the website or by +helping with the organisation of events +worldwide. + +You can donate equipment and services to the Debian project so that +either its users or developers can benefit from them. We are in constant search +for mirrors worldwide our users can rely on and +auto-builder systems for our porters. + +Help Debian promoting itself by talking about it and demonstrating it to others. + + + +Debian Labor + +Debian is always looking for help and there are some areas where just being +a worm body ready to learn new things is the perfect starting place. + + # TBD - link to translators mailing lists # Translators, link directly to your group's pages @@ -33,6 +56,25 @@ language. For more information read the Internationalisation pages. +You can help writing copyright definitions for package maintainers in need. +Best place to find one is +http://mentors.debian.net/";>mentors.debian.net. + + + +Debian Development + +If you are considering helping in the development of Debian GNU/Linux +there are many areas in which both experienced and inexperienced users can assist: + +# TBD - link to users mailing lists +# Translators, link directly to the translated mailing lists and provide +# a link to the IRC channel in the user's language +If you are an experienced user you can help other users through +the http://lists.debian.org/";>user mailing lists or +by using the IRC channel #debian. For more information on support options +and available sources read the support pages. + You can h
Re: debian/rules VS debian/copyright.
On 03/21/12 20:36, Jonathan Yu wrote: > Hi Mike, > > On Wed, Mar 21, 2012 at 9:00 PM, Mike Mestnik <mailto:che...@mikemestnik.net>> wrote: > > I say one can easily split technical > and legal responsibility without the need for any gray lines. > > > While I am certainly not opposed to your idea in principle - that > everyone has something to contribute (including non-programmers) to > Debian's continued success - I think that for most packages, the > problem would be logistical. > > From my experience working with the Debian Perl Group as a contributor > but not a Debian Developer, our workflow works something like this: > > 1. An interested party commits desired changes with corresponding > debian/changelog updates to the team repository > > 2. The Package Entropy Tracker notices the change, and flags it as > Pending Upload > > 3. A Debian Developer reviews the package and provides sponsorship > (uploading the work on behalf of the original contributor) if > applicable, or requests further changes > > When it comes to copyright and licensing information, which is > typically a matter of looking through the accompanying documentation > and leaving appropriate notes in debian/copyright, it is typically a > small job that is done along with the rest of the packaging process. > One nice way of doing a quick spot check is using "grep -ir copyright > ." to find all instances of the word "copyright" in the source files. > Logistically, requiring developers to wait for an external party to > work on copyright information (which typically doesn't take too long > in my experience) would significantly slow down at least the Debian > Perl Group's ability to process and upload packages. > > When it comes to translations, which I think is an area that recieves > much more non-developer attention than debian/copyright files, the > logistical issue still arises - but since we don't all write all of > the languages in existence, we often have no choice but to seek the > assistance of interested parties. > > However, all that being said, I think that Debian can benefit from > interested parties assisting with copyright audits. We certainly have > a lot of metadata and a lot of code in the various Debian repositories > - but how accurately does that metadata (e.g. license and copyright > information) reflect the reality? > > Moreover, there are a lot of open bug reports where we are blocked on > an ITP due to incomplete or missing copyright/licensing information - > it would be nice to have more eyes to look over these bugs, forward > the information upstream where appropriate, and follow up on open bug > reports (unfortunately, of which, there are many). > > To sum up, the two places I see non-developer assistance being > beneficial to the Debian project (in the context of copyright and > licensing information) are: > > 1. Auditing of copyright/licensing information: ensure that the > metadata stored in debian/copyright is correct. This can be very > difficult to do as sometimes code is taken from other sources by > upstream developers without attribution. > This is where I'm stuck on my package not so much the specific issue of a lack of attribution, but the process of auditing the copyright/licensing information. Thanks to your input I now can see my path vary clearly. I'll take a bit to reflect this re-wording and apply both of these suggestions to my recommended patch. Thank you! > 2. Following up on bugs related to copyright/licensing information: > for cases where an ITP/RFP has been filed, but where copyright > information is not clear from the source data, file a bug report with > the upstream developers, or alternatively, ping the upstream > developers in case the bug has been overlooked. Possibly spend some > time investigating alternative bug trackers that the upstream > developers may use instead, or their personal e-mail addresses. > > Cheers, > > Jonathan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f6a8dc7.7020...@mikemestnik.net
Multirelease, something like Multiarch.
Hello, Multiarch gives the ability to store libraries in the main root lib directories from different architectures and this allows applications to co-exist on the same system. Some applications are compiled for amd64 while others are for i386 and perhaps x32. This could have been done using chroots and for a long time prior to Multiarch it was. The problems of, what happens when a i386 app loads a library for amd64 were handled. Now we've a similar situation for releases and even distributions. We can run multiple releases using a chroot for each, but perhaps this system can be improved on. Along comes the idea of supporting Multirelease. Certainly there is a lot to work out and I'm sure there will be plenty of ideas and good solutions. Cheers.
Proxy compliance and assistance.
Hello, ASYMK there are a number of different proxies technologies and it's not impossible to be in a position where there use is mandatory. I've recently looked into a number of bugs against Canonical's Ubuntu: [1]479630 [2]370924 1. https://bugs.launchpad.net/bugs/479630 2. https://bugs.launchpad.net/bugs/370924 I'd like to start a movement to verify and assist projects/packages with the proper deployment of software that supports proxies. If this doesn't happen in Debian then there is no hope for Ubuntu. I'm able to assist application developers in the network level coding needed to make use of a proxy as well as provide some vary flexible example tools that can be employed to this end. What I need most of all is community support, it's no good to confront developers or package maintainers that are insistent on rebelling against the use of proxies. Obviously this is a debate that could only hurt the users. I'd like to see proxy support being added a release critical issue, likely not for the current release but set as a goal no more then two releases from now. I'd like to have a single large debate and then, assuming the concept flies, setup a task force and mailing list for users and developers to get assistance. Members of the task force should be considerate of all different types of proxies. http(caching and non-caching); http-connect(both port filtered and not port filtered); socks(in all it's glorious iterations); plus anything else that falls even remotely into this category. However it's only natural that the group would consist of experts in particular areas. Even though the advent of IPv6 diminishes the need or deployment of proxies and that they may decrease and even disappear in the not so distant future. I see proxy support instead as a worth while goal that's long overdue. Thank you. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e7a375b.9090...@mikemestnik.net
Re: Re: Proxy compliance and assistance.
On Wed, 21 Sep 2011 at 14:13:31 -0500, Mike Mestnik wrote: I'd like to start a movement to verify and assist projects/packages with the proper deployment of software that supports proxies. In GLib-based applications, connecting using GSocketClient while having glib-networking installed will automatically use a configured proxy; this is much less ongoing maintenance burden than adding specific proxy support to every networked application, so please use this route where feasible in GLib/GNOME applications, rather than repeatedly writing app-specific proxy code. Recent versions of telepathy-gabble (as used by Empathy for XMPP) will automatically pick up GNOME/KDE proxy settings in this way, for instance. (There's probably an equivalent thing I could say about Qt/KDE applications, if I knew Qt better.) This is the kind of information I'd intend to propagate and turn into release goals. Understanding that there's more then one way... Debian may need a centralised configuration where all of the deployed back-ends(GSocketClient/Qt/other:apt:wget:axel) would be configured. Let me make myself clear, "I fully support and advocate using centralised librarys, especially when they implement tasks common to many applications." However the real work is a little different then that Utopia. I belive that leeway should be given in the short term for things that are deemed important. I belever that proxy support is so important. What I need most of all is community support, it's no good to confront developers or package maintainers that are insistent on rebelling against the use of proxies. There's an important difference between "I think proxies don't matter" and "I think this particular patch to support use of proxies is more maintenance burden than it's worth"; be careful not to mistake the second for the first. Part of a maintainer's job is to say "no" to things they're not going to be able to maintain in future. Well, I'll say one thing. I'm a little bit retarded so forgive me as there should be some one other then me doing PR(I rather like Paul Wise's comments, nice work... Don't take that the wrong way I understand you don't have the time.) anything I'm involved in. I understand that the following point of view is likely to be overkill, however if no-one is willing to stake a flag down in there utopia then any line drawn could be misplaced. If an application, any application, lacks proxy support and a patch exists that's five lines enabling environment variables then in the absence of any other patch it should be... A. Disabled by default, but compiled in at least one package. There is no point in fighting about the better way if the person advocating the better way is not willing or able to do anything more then put pen to paper. Either write a better patch or get out of the way of progress. I can't understand why this "I don't like it." attitude would ever fly. There are plenty of ways to guard against new code from causing problems... For example "Disabled by default" could mean that the code is only executed when a new command line flag is present. The dev. can put a patch on top of the submitted patch to ensure any level of disabling they are comfortable with. There is even a possibility to split the proxy support out into another binary package if it's the only way to work around technical issues. This "It might not work attitude" is worthless if it is working and I assure you that proxy support is nothing to cry weapons of mass destruction over. It's completely harmless, even if done improperly. *Beyond the average rate of failure for any additional patch. I for one would tend to reject a patch to add a "full" proxy implementation to any network application that I maintained, but I'd be more likely to accept a patch that used GProxyResolver or g_socket_client_add_application_proxy (for GLib code) or something like libproxy or pacrunner (for non-GLib code). Again, if you want it done right then you'll just have to do it yourself. When it's a this is un-usable in a given environment there just needs to be a solution, instead of excuses. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e7b6f16.9020...@mikemestnik.net
Bug#867869: ITP: beautify-bash -- Beautifier for Bash shell scripts written in Python
Package: wnpp Severity: wishlist Owner: Mike Mestnik -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: beautify-bash Version : 1.0 Upstream Author : Paul Lutus , Shriram V * URL : https://arachnoid.com/python/beautify_bash_program.html https://github.com/shri314/beautify_bash * License : GPL Programming Lang: Python Description : Beautifier for Bash shell scripts written in Python Second Bash script beautifier by Paul Lutus — the first is pretty well-known. This rewrite cleans up some annoying inconsistencies. Currently Debian does not have a commandline tool that tidies/beautifies shell scripts. This is useful in git hooks to ensure that only properly formatted/spaced code makes it into the repository. For example the d-i has several instances where shell scripts have trailing whitespace, indicating disarray. It's an old program that's seen recent development by Shriram, while Paul Lutus is the original author he does not seem to have an email address. Paul can be reached via this URL, I assume, https://arachnoid.com/messages/index.php This is a Python script about 200 lines long, it can also serve as a Python module. I'm looking to hammer out the details concerning what version/release and to find a sponsor. Thanks for your consideration. -BEGIN PGP SIGNATURE- iQJLBAEBCAA1FiEE50YYYn+e/FujuFBs49GprY7cq4oFAlljL8sXHGNoZWFrb0Bt aWtlbWVzdG5pay5uZXQACgkQ49GprY7cq4qrkQ//fnWwjj7g1mjac7cUT4T9D1o9 qKJZdXL2gvQWU0PtjavKWaqeVPdFebsiyDRjdnCOxjnap5P5HDogJzh1dA8Xwilt 9OWFD3ZImA6VBOvIwN7LjcguWe0Z7NSy8XjU42bvAzrDZWXf1DHj+G/TMB+ES8SC dNLl/UJ64yTidsYlCdsZ1wRuDaaZlZ5eo/YoN+7SsYbcVRLF6U/HP9dPFChTBxpS aVPKIysQZdrlOBAb3RfLXxhQNxpASLh+TYtHh0hi2vY9A3C9d1W9WFjprJs8/RI0 nxPGdw0abBFmuQR1KmLUDLrqTr0kPEP18cVVQ+3rYvVP6xN73mfqn4Uv6TTFx3DE kVytozrVnCtFt3tS2VymETPES6ZZSSBHChgaTPlZBhO319iZUpCZt2PAQ7/13FLM zUTfEcTQrpxNlRQnPVhf3KaJT1zNhI0XQJmFmpg04/BNGti0+4clO6d5fL7q/WT0 AAmDRlF+nV+RYU7bANBYKWMmvGeSFP0ahITXgcOAlira7qj5UB9JxZqOn2cfFEsc xnD6hTOWHaH3w1jmeWR7+YI0HRsXWsGVwIYfmQW1cCAA4ojBIw36ZSQpjjNRqqVi njixeBBPp6wJmzSaY0ABebctKy1rM3C0dFiuE8UopgAjfTU/TOy1vXmgPiOIc/CH StQcY1Enco1GZkXCflU= =UN9F -END PGP SIGNATURE-
