Re: cdrtools
On Sun, Jul 30, 2006 at 08:28:04PM -0500, Matthew R. Dempsky wrote: > On Sun, Jul 30, 2006 at 10:03:14PM +0200, Wouter Verhelst wrote: > > On Sun, Jul 30, 2006 at 11:25:00AM +0200, Joerg Schilling wrote: > > > Note it is unclear whether the makefiles could be called "scripts" > > > > Unproven assertion. > > How is something proven unclear? 'unexplained', then. Whatever. -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Translated packages descriptions progress
On Sun, Jul 30, 2006 at 06:55:19PM -0300, Felipe Augusto van de Wiel (faw) wrote: > On 07/30/2006 03:26 AM, Michael Vogt wrote: > > Dear Friends, > > Hi Michael, Hi > > the current version of apt in debian/experimental has support for > > translated package descriptions and we have a the current translations > > available for sid on the mirrors (currently not on ftp.debian.org > > itself because of the mirror split I suspect). > > In a couple of mirrors that I checked, the translations look > a little bit out-of-date (from May.2006), is this expected and for > now the idea is just have it for tests, or we will have it being > update automagically (which would be wonderful). :-) Yes, yesterday I see the out-of-date files too. The problem ist a broken cronjob on ddtp.debian.net. sorry I will check and fix this. > > Please help testing the new code and report problems and/or > > success. It should be enough to install apt, python-apt, synaptic from > > experimental and if your LANG is set to something other than C it > > should download the appropriate translation indexes and displays them > > with apt-cache or synaptic (warning: not everything is translated > > yet). > > It is already based on the recent work of Michael Bramer (grisu)? I don't work on apt and co. This work is based on otavio's work. But the running ddtp-server is my work. But only for the next months. We like to switch the ddtp as part of the new i18n-framework. > I have a few doubts, because I would like to ask the Brazilian > Portuguese Team to start working on it again, so here they go: > > The review process is the same? no. the currend ddtp-server don't support the review process, sorry. > There are also "coordinators" with special commands to the > pdesc server? (At least for Brazilian team, we will need to > update that address). > > Is there anything else that we could do to help DDTP? dito. The server don't know all the special commands from the old ddtp-server yet. sorry. No 'help', no 'admin', no 'review' etc. But I like to add some of them. But we should concentrate on the work of the i18n framework. > We exchange a lot of ideas about the DDTP during DebConf6, > we also tried to add this as a "pet release goal" for etch, but for > quite a while now, there were no news, thanks for this report. :-) yes. But all the ideas about the DDTP during DebConf6, are ideas about the new i18n framework. I hope we can test the new apt version and can get this version to sid and after some days to testing. Gruss Grisu -- Michael Bramer -- http://www.feuerwehr.kreuzau.de/wiki/ PGP: finger [EMAIL PROTECTED] -- Linux Sysadmin -- Use Debian Linux Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge. Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
TRAMP MAGAZINE
Our new online members service. Become a member to use the new online home for all \"TRAMPS\" worldwide. www.trampmagazine.com. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More dh_python questions
Hi, (Could you please stop cross-posting to debian-devel? The discussion belongs to debian-python@ and the list is low traffic.) On Sun, Jul 30, 2006, Manoj Srivastava wrote: > I have only one version in XS-Python-Version (say, 2.4) I think the patch in #378604 enhance this situation with "XS-Python-Version: 2.4", but I had trouble too with "XS-Python-Version: 2.3", see thread on debian-python@, "Generation of "python" dependencies for public extensions versus python2.3". Also, the behavior seems completely clean for "XS-Python-Version: current", have a look at "flumotion" which has private modules which are compiled in place (in /usr/lib/flumotion) for the current version of python on install, and are recompiled on upgrades. Bye, -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
At 1154196833 past the epoch, Michael Banck wrote: > It makes no sense to complain about this until we have a > good default artwork. So let's fix that first, then > convince the gdm maintainer that we should use this. Well put. On that note, where is consistent art work being coordinated? I'm interested in helping out here, if possible. -- Jon Dowland http://alcopop.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Etch artwork (was: Re: Why does Ubuntu have all the ideas?)
On Mon, Jul 31, 2006 at 10:37:54AM +0100, Jon Dowland wrote: > At 1154196833 past the epoch, Michael Banck wrote: > > It makes no sense to complain about this until we have a > > good default artwork. So let's fix that first, then > > convince the gdm maintainer that we should use this. > > Well put. On that note, where is consistent art work being > coordinated? I'm interested in helping out here, if > possible. We have started trying to coordinate this at http://wiki.debian.org/DebianDesktopArtwork What we need first is somebody to make good screenshots of the default GNOME, KDE (and maybe XFCE) desktops and their default toolkit/window manager themes (and check back with the packaging teams whether any changes until etch release are planned to this end), so we can figure out whether one set of artwork is possible, or (due to big color/whatever differences) we need several sets. Then, decide on some basic things like color (Debian purple? (ugh!) Blueish? (yay!) Greenish?) and then announce a Call for Artwork through appropriate channels (to be determined, d-d-a might not cut it) The package integration stuff seems to have happened at least for GNOME thanks to Gustavo, the KDE team should check what needs to be done on their side. cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Translated packages descriptions progress
On 7/30/06, Michael Vogt <[EMAIL PROTECTED]> wrote: Dear Friends, As someone who has been loosely following this for a while and translated a few descriptions, I have a few little questions/comments: 1. The website you provide (http://ddtp.debian.net/) is extremely light on detail. It contains just the translations, nothing else. Something I've wished for is a link to a site provide translations of common technical terms, given they're not in the usual dictionaries. If that link got included in the email it'd be great. At the moment I'm using http://www.kde.nl/helpen/woordenlijst.html but even that's missing some common words. 2. What's with the graph? It looks odd. 3. There's some comments further in the thread about the review process not working, or something like that. What's up with that? Other than that, I'm glad there's progress. Getting translated descriptions is a really cool goal. -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
At 1154090521 past the epoch, Katrina Jackson wrote: > PS. Hardware, Hardware, Hardware, I have to confess, if > there was better hardware support I think most people > would be happy. Hardware supported by Ubuntu 6 months > ago, should be supported by Debian by now. Without further specifics, this is not a useful argument to have. Assuming by "Ubuntu" you mean Ubuntu Breezy (i.e. stable as of 6 months ago), but what do you mean by "Debian"? Sarge? Sid today? Sid yesterday? Etch last week? If you've only looked at Sarge, say, then perhaps Debian *does* support the hardware you are talking about. -- Jon Dowland http://alcopop.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Successful and unsuccessful Debian development tools
Michael Banck <[EMAIL PROTECTED]> writes: > On Sun, Jul 30, 2006 at 09:39:26PM +0100, martin f krafft wrote: >> Do you know of a good example of a tool that has successfully shaped >> Debian development for a large number of people? > > CDBS and alioth/svn.debian.org. > > > HTH, > > Michael With cdbs as negative and alitoh/svn as positive? How about debhelper, debconf, dpatch? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Successful and unsuccessful Debian development tools
also sprach martin f krafft <[EMAIL PROTECTED]> [2006.07.30.2139 +0100]: > I have Reply-To set for fear of horrible flame wars when one DD > bashes another one's favourite tool, but I will make the results > public, obviously. Thus, I appreciate if you could take the time to > drop me a short note if you have an opinion on the matter. First of all, thanks to all who have replied so far! I have much to learn still; at Stefano Zacchiroli's suggestion, I've started a page on the wiki, which should probably provide for better exchange. http://wiki.debian.org/madduck/adoptions Feel free to add whatever you may have to say. I'd appreciate if you could identify all additions/comments with your name. Thanks, -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system your eyes are weary from staring at the CRT. you feel sleepy. notice how restful it is to watch the cursor blink. close your eyes. the opinions stated above are yours. you cannot imagine why you ever felt otherwise. signature.asc Description: Digital signature (GPG/PGP)
Re: Etch artwork (was: Re: Why does Ubuntu have all the ideas?)
On 7/31/06, Michael Banck <[EMAIL PROTECTED]> wrote: On Mon, Jul 31, 2006 at 10:37:54AM +0100, Jon Dowland wrote: > At 1154196833 past the epoch, Michael Banck wrote: > > It makes no sense to complain about this until we have a > > good default artwork. So let's fix that first, then > > convince the gdm maintainer that we should use this. > > Well put. On that note, where is consistent art work being > coordinated? I'm interested in helping out here, if > possible. We have started trying to coordinate this at http://wiki.debian.org/DebianDesktopArtwork What we need first is somebody to make good screenshots of the default GNOME, KDE (and maybe XFCE) desktops and their default toolkit/window manager themes (and check back with the packaging teams whether any changes until etch release are planned to this end), so we can figure out whether one set of artwork is possible, or (due to big color/whatever differences) we need several sets. We already have some good artwork. The problem is where it is and visual consistency between the different desktop environments. Btw, some wallpapers will work better in a desktop environment and won't in others (eg: text or image in the bottom is evil, we usually have panels there). I want to make a call for a online meeting to discuss some points with gdm, kdm, pkg-gnome, pkg-kde and xfce maintainers. I just need to talk (again) with Joss about desktop-base plans and see what he think about my ideas (see below). Then, decide on some basic things like color (Debian purple? (ugh!) Blueish? (yay!) Greenish?) and then announce a Call for Artwork through appropriate channels (to be determined, d-d-a might not cut it) I agree. The package integration stuff seems to have happened at least for GNOME thanks to Gustavo, the KDE team should check what needs to be done on their side. We've desktop-base package, that i would like to: - Move desktop-base from pkg-gnome to a "neutral" alioth project where at least two members of each group has commit access. I've asked for the second time debian-desktop group members (2, non-DDs) input about this yesterday; - Use to build gdm and kdm themes; - GNOME, KDE and XFCE splash screens; - sid wallpaper (common for all environments); - etch wallpaper (to be easily changed during freeze). That is what i want to discuss in a online meeting with the parties involved, this is just what i've in mind, nothing was decided yet. Feedback about it, specially from the maintainers involved in the changes is welcome. The sid->etch wallpaper is a release issue and should be discussed with the release team too, but it won't hurt change to Etch wallpaper right before the freeze if required by them. The kdm is maintained by the pkg-kde group, but the gdm isn't. Actually gdm is configured to pick a random theme in each login. I think Joey Hess talked with Ryan Murray about change this in the near future. FYI, i'm including GNOME and KDE because there are tasks gnome-desktop and kde-desktop respectively. I've prepared a xfce-desktop task, but it won't be in d-i beta3 due to tasksel freeze. Hopefully it will be a possibility preseeding the Etch installer. regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Jon Dowland <[EMAIL PROTECTED]> writes: > Without further specifics, this is not a useful argument to > have. Assuming by "Ubuntu" you mean Ubuntu Breezy (i.e. > stable as of 6 months ago), but what do you mean by > "Debian"? Sarge? Sid today? Sid yesterday? Etch last week? > If you've only looked at Sarge, say, then perhaps Debian > *does* support the hardware you are talking about. I am running a testing/unstable system myself, but I would not recommend a beginner user to use anything but stable. Things do go wrong in testing and I would not expect a beginner to deal with things like the x.org transition. So when comparing distributions I would always compare stable releases. I don't think it makes sense to compare development versions since they are not intended for end users. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian
On 7/31/06, Hubert Chan <[EMAIL PROTECTED]> wrote: On Sat, 29 Jul 2006 20:00:21 +, "Gustavo Franco" <[EMAIL PROTECTED]> said: [...] > The packages that aren't under group maintenance and will never be, > needs more not so strict NMU rules. Why? Due to the "my stuff, don't touch that!" current approach, but (again) this is just IMHO. regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Successful and unsuccessful Debian development tools
Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Michael Banck <[EMAIL PROTECTED]> writes: > >> On Sun, Jul 30, 2006 at 09:39:26PM +0100, martin f krafft wrote: >>> Do you know of a good example of a tool that has successfully shaped >>> Debian development for a large number of people? [...] > How about debhelper, debconf, dpatch? dpatch as an example for both success and non-success: It's great for many applications, but for large source trees other tools, like quilt, are superior. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Debian should have a weekly debate
I really believe Debian would benefit if they had a weekly debate. Iunderstand you debate on things you are voting on, but I think it could bebetter if you debated on general concerns. I was reading the "Why Ubuntu has all the ideas" thread and think two things were apparent.First- Many wrote quick feelings out of impulse. Often, they had good ideasthey wanted to express, but because of impulse, said them in ways that were not the most productive. Many were accused of being trolls or making personalattacks because of this.Second- Many people had a few issues that they so deeply wanted to expressthat they couldn't hold back, even though it may cause an argument. I don't think this is a bad thing, but it does to me show many have issues they wouldlike to be discussed. This leads me to believe one of the best things the Debian project couldadopt is a weekly debate. This is really healthy for a society, I hope you take the idea seriously. Every day when I watch CNN they have a panel of peopledebating key issues which need to be addressed. Whenever I come away from oneof those debates, I know I am better informed, and better able to contribute to society in a productive way. I think this will also hold true for all theDebian Developers.This is what needs to happen, two weeks before a debate there needs to be atopic announced and a call for volunteers. There should be 3-4 people who feel passionately about the issue who should volunteer. Then they should have twoweeks to draft a statement, about 1-3 pages long about how they feel about thesubject. During the two weeks they could privately collaborate with others for advice. After two weeks the volunteers would release their statements on adebian-debate mailing list or something. They should then have 48 hours toofficially respond to the other statements. Then it should be open floor where all the devs comment and each of the statements and rebuttals. That could lasta few days. Then the next week it starts again. (Obviously if you have twoweeks to prepare but the debate happen each week they would have to slightly stager over each other.) *These debates should not happen on IRC. If feelings are too deep out of impulse things will be said that shouldn't be said* I really believe this will allow those who feel passionately about a subject to have a voice, and allow time and contemplation so that there aren't abruptstatements that are too impulsive and not that informative. It takes time to often draft a statement that articulates your thoughts in a way that is best said. Again there could be some private collaboration. Obviously the topics should not be things like: Should Debian squash bugs?Should Devs continue to use the command line? Those are pointless. How about things like some of the main topics in the "Ubuntu" thread. How do you feel about the innovation level and direction in Debian? Whatshould stay the same, and how should things be changed? Should there be only individual maintainers of important packages or shouldthey be done in teams? Or should there be a central source that all Developerscan touch, or should maintainers have a more "you worry about your package, and me mine" attitude? Or is there a better middle ground? How well is Debian catering to the Desktop user? Should more be done, less,or are things just fine? Or maybe in some way should things be done different? I am not saying these are the best topics, but I think you get the idea. I just really feel some healthy debate would be beneficial for Debian. It wouldkeep everyone more informed on key issues, and would allow people who feelpassionately about the subject to get it out in an intellectual manner. It will also get discussion about things that really need to be discussed, but peopleare afraid to bring up because feelings run high. alfo
Debian should have a weekly debate
I really believe Debian would benefit if they had a weekly debate. Iunderstand you debate on things you are voting on, but I think it could bebetter if you debated on general concerns. I was reading the "Why Ubuntu has all the ideas" thread and think two things were apparent.First- Many wrote quick feelings out of impulse. Often, they had good ideasthey wanted to express, but because of impulse, said them in ways that were not the most productive. Many were accused of being trolls or making personalattacks because of this.Second- Many people had a few issues that they so deeply wanted to expressthat they couldn't hold back, even though it may cause an argument. I don't think this is a bad thing, but it does to me show many have issues they wouldlike to be discussed. This leads me to believe one of the best things the Debian project couldadopt is a weekly debate. This is really healthy for a society, I hope you take the idea seriously. Every day when I watch CNN they have a panel of peopledebating key issues which need to be addressed. Whenever I come away from oneof those debates, I know I am better informed, and better able to contribute to society in a productive way. I think this will also hold true for all theDebian Developers.This is what needs to happen, two weeks before a debate there needs to be atopic announced and a call for volunteers. There should be 3-4 people who feel passionately about the issue who should volunteer. Then they should have twoweeks to draft a statement, about 1-3 pages long about how they feel about thesubject. During the two weeks they could privately collaborate with others for advice. After two weeks the volunteers would release their statements on adebian-debate mailing list or something. They should then have 48 hours toofficially respond to the other statements. Then it should be open floor where all the devs comment and each of the statements and rebuttals. That could lasta few days. Then the next week it starts again. (Obviously if you have twoweeks to prepare but the debate happen each week they would have to slightly stager over each other.) *These debates should not happen on IRC. If feelings are too deep out of impulse things will be said that shouldn't be said* I really believe this will allow those who feel passionately about a subject to have a voice, and allow time and contemplation so that there aren't abruptstatements that are too impulsive and not that informative. It takes time to often draft a statement that articulates your thoughts in a way that is best said. Again there could be some private collaboration. Obviously the topics should not be things like: Should Debian squash bugs?Should Devs continue to use the command line? Those are pointless. How about things like some of the main topics in the "Ubuntu" thread. How do you feel about the innovation level and direction in Debian? Whatshould stay the same, and how should things be changed? Should there be only individual maintainers of important packages or shouldthey be done in teams? Or should there be a central source that all Developerscan touch, or should maintainers have a more "you worry about your package, and me mine" attitude? Or is there a better middle ground? How well is Debian catering to the Desktop user? Should more be done, less,or are things just fine? Or maybe in some way should things be done different? I am not saying these are the best topics, but I think you get the idea. I just really feel some healthy debate would be beneficial for Debian. It wouldkeep everyone more informed on key issues, and would allow people who feelpassionately about the subject to get it out in an intellectual manner. It will also get discussion about things that really need to be discussed, but peopleare afraid to bring up because feelings run high. alfo
Re: Etch artwork (was: Re: Why does Ubuntu have all the ideas?)
Message sent to the related projects mailing lists and maintainers. Time to deal with the goodies, pressure, critics and work... regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian should have a weekly debate
also sprach alfredo diega <[EMAIL PROTECTED]> [2006.07.31.1616 +0100]: > I really believe Debian would benefit if they had a weekly debate. > I understand you debate on things you are voting on, but I think > it could be better if you debated on general concerns. I was > reading the "Why Ubuntu has all the ideas" thread and think two > things were apparent. I don't think a debate is in any way a useful format for F/OSS, but there's nothing preventing you from inviting to one and moderating it. > Every day when I watch CNN they have a panel of people debating > key issues which need to be addressed. I generally end up wanting to throw up seeing those people discuss. Words and no action. And I more than often wonder why some people are even given the chance chance to speak about a topic. Like the other day I read a statement by Britney "hussy" Spears about the Lebanon situation. WTF? I'd prefer if Debian got work done rather than talk (too) much about issues. We know we're going to disagree on many things, and mailing list discussions at least give us links with some of the useful comments to link to from DWN or other discussions. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system don't hate yourself in the morning -- sleep till noon. signature.asc Description: Digital signature (GPG/PGP)
Re: Debian should have a weekly debate
On 7/31/06, martin f krafft <[EMAIL PROTECTED]> wrote: also sprach alfredo diega <[EMAIL PROTECTED]> [2006.07.31.1616 +0100]: > I really believe Debian would benefit if they had a weekly debate. > I understand you debate on things you are voting on, but I think > it could be better if you debated on general concerns. I was > reading the "Why Ubuntu has all the ideas" thread and think two > things were apparent. I don't think a debate is in any way a useful format for F/OSS, but there's nothing preventing you from inviting to one and moderating it. I thought #debian-tech @ irc.oftc.net was started with the "technical debates" goal in mind, no? > Every day when I watch CNN they have a panel of people debating > key issues which need to be addressed. I generally end up wanting to throw up seeing those people discuss. Words and no action. And I more than often wonder why some people are even given the chance chance to speak about a topic. Like the other day I read a statement by Britney "hussy" Spears about the Lebanon situation. WTF? I'd prefer if Debian got work done rather than talk (too) much about issues. We know we're going to disagree on many things, and mailing list discussions at least give us links with some of the useful comments to link to from DWN or other discussions. I agree, but i think that the online meetings about specific projects work. (eg: d-i, ltsp, ...) regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Successful and unsuccessful Debian development tools
Am Montag 31 Juli 2006 17:08 schrieb Frank Küster: > Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > > Michael Banck <[EMAIL PROTECTED]> writes: > >> On Sun, Jul 30, 2006 at 09:39:26PM +0100, martin f krafft wrote: > >>> Do you know of a good example of a tool that has successfully shaped > >>> Debian development for a large number of people? > > [...] > > > How about debhelper, debconf, dpatch? > > dpatch as an example for both success and non-success: It's great for > many applications, but for large source trees other tools, like quilt, > are superior. And quilt is much more intuitive to use. Using dpatch is a science for itself. HS
Re: Debian should have a weekly debate
On Monday 31 July 2006 18:16, alfredo diega wrote: > I really believe Debian would benefit if they had a weekly debate. I > understand you debate on things you are voting on, but I think it could be > better if you debated on general concerns. I was reading the "Why Ubuntu > has > all the ideas" thread and think two things were apparent. AFAICS debates are ongoing all the time via various comm channels - MLs, various wiki pages, IRC channels, even VCS if you want ;-) What channel do you miss to debate thru ? > First- Many wrote quick feelings out of impulse. Often, they had good > ideas > they wanted to express, but because of impulse, said them in ways that were > not > the most productive. Many were accused of being trolls or making personal > attacks because of this. > > Second- Many people had a few issues that they so deeply wanted to express > that they couldn't hold back, even though it may cause an argument. I > don't > > think this is a bad thing, but it does to me show many have issues they > would > like to be discussed. > >This leads me to believe one of the best things the Debian project could > adopt is a weekly debate. This is really healthy for a society, I hope you > take > the idea seriously. Every day when I watch CNN they have a panel of > people debating key issues which need to be addressed. Whenever I come > away from one > of those debates, I know I am better informed, and better able to > contribute to > society in a productive way. I think this will also hold true for all the > Debian Developers. That will consume tons of time which is better to be spent in fixing RC-bugs, helping WNPP, improving d-i, processing and mentoring NMs, improving artworks and such. -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian
On Mon, 31 Jul 2006 11:40:54 -0300, "Gustavo Franco" <[EMAIL PROTECTED]> said: > On 7/31/06, Hubert Chan <[EMAIL PROTECTED]> wrote: >> On Sat, 29 Jul 2006 20:00:21 +, "Gustavo Franco" >> <[EMAIL PROTECTED]> said: >> >> [...] >> >> > The packages that aren't under group maintenance and will never be, >> > needs more not so strict NMU rules. >> >> Why? >> > Due to the "my stuff, don't touch that!" current approach, but (again) > this is just IMHO. I disagree with that. (IMHO) I think that the "my stuff" approach has more to do with maintainer attitude than with NMU rules. I don't think that loosening the NMU rules will decrease the maintainers' possessiveness. The current rules already authorized all DDs to make NMUs, if you follow the procedures. And if you follow the current NMU rules, then the entire process will take, what, a couple of weeks? My own opinion is that if you loosen the NMU rules, we'll get more bad NMUs, which will result in more annoyed maintainers, which will increase possessiveness. (NMUs will be seen as sources of breakages, rather than as sources of fixes.) I also don't see why we would need to relax the NMU rules for all packages that are not under group maintenance. One of the packages that I maintain is extremely tiny (relatively speaking), and at the moment has a very slow upstream release cycle. If a normal-severity bug doesn't get fixed for two weeks, it's not the end of the world. And there is absolutely no reason why that package should be group-maintained -- adding a group would add more overhead, and produce no benefit. So I don't see why that package should have looser NMU rules than other packages, such as the GNUstep core library packages, which are maintained by a group (even though I'm basically the only one who maintains them), but has the potential of breaking other packages if it is broken. If we are going to loosen the NMU rules (or decrease the time for an NMU), I think it should be applied to all packages, and not just packages that are not group-maintained. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: package ownership in Debian
On Monday 31 July 2006 18:43, Hubert Chan wrote: > On Mon, 31 Jul 2006 11:40:54 -0300, "Gustavo Franco" <[EMAIL PROTECTED]> said: > > On 7/31/06, Hubert Chan <[EMAIL PROTECTED]> wrote: > >> On Sat, 29 Jul 2006 20:00:21 +, "Gustavo Franco" > >> <[EMAIL PROTECTED]> said: > >> > >> [...] > >> > >> > The packages that aren't under group maintenance and will never be, > >> > needs more not so strict NMU rules. > >> > >> Why? > > > > Due to the "my stuff, don't touch that!" current approach, but (again) > > this is just IMHO. > > I disagree with that. (IMHO) I think that the "my stuff" approach has > more to do with maintainer attitude than with NMU rules. I don't think > that loosening the NMU rules will decrease the maintainers' > possessiveness. The current rules already authorized all DDs to make > NMUs, if you follow the procedures. And if you follow the current NMU > rules, then the entire process will take, what, a couple of weeks? IMHO the maintainer(s) could mention their wishes wrt to NMU and any particular package in debian/copyright, right after This package was debianized by ... When needed NMU is appreciated/forbidden/whatever That will help to avoid some confusion, when people are in doubt wrt "to NMU or not to NMU". -- pub 4096R/0E4BD0AB 2003-03-18 fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#380654: ITP: ndisc6 -- IPv6 diagnostic tools
Package: wnpp Severity: wishlist Owner: "Rémi Denis-Courmont" <[EMAIL PROTECTED]> * Package name: ndisc6 Version : 0.6.6 Upstream Author : Rémi Denis-Courmont <[EMAIL PROTECTED]> * URL : http://www.simphalempin.com/dev/ndisc6. * License : GPL Programming Lang: C99 Description : IPv6 diagnostic tools ndisc6 gathers a few diagnostic tools for IPv6 networks: - ndisc6, which performs ICMPv6 Neighbor Discovery in userland, - rdisc6, which performs ICMPv6 Router Discovery in userland, - rltraceroute6, yet another IPv6 implementation of traceroute (it has many more option than the one in iputils though), - tcptraceroute6, a TCP/IPv6-based traceroute implementation, - tracert6, a ICMPv6 Echo Request based traceroute, - tcpspray6, a TCP/IP Discard/Echo bandwidth metter. I already have a lintian+linda+pbuilder-clean package ready here: http://www.remlab.net/files/ndisc6/debian/ I'd need a sponsor though. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17.7 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
expanded wants.
see how PC works from inside out The computer you using Crynwr v.x drivers docs PKTDA.ZIP PKTDB.ZIP drives PKTDC.ZIP update SKLIB.ZIP UNZIP.EXE VAL.ZIP Code Broker Science Policy Haninah Levine Shopping Contacts SuSe Old breaking trends. links on: Subscribe releases Media theURL winName features HomeAbout UsNews contact Daily Service Releases Tracks Speeches You risen steadily microns smallest For human hair thick. As feature size heart any normal whether desktop machine server laptop. might be Pentium larger foreign markets. Direction Energy Last Enter Image Source File. directory file d: images breaking trends. links on: Subscribe programs ALPS.ZIP Resident //Z BASIC.ZIP boots CAM.ZIP HomeAbout chip. first was Boot external another Version. Now available download. prefer show ADACDBOX organize beat match bpmFree MBChorus Producer chorus sound MBAudio .NET computer you using read this page uses do its work. heart energy costs become mainstay lives. built computers either chips discrete wired powered Italy Uk Gulf Countries Japan Zealand Tourism provides reliable credible range issues overseas social impact tourism visitor arrivals dangerous pretense something people copy. goal However reason Take Action GPLv: drafting GPLv. costs become mainstay Utilities Backup Drivers Printers Several useful TSR NOTE: REQUIRED contained remaining area. DESI.ZIP designs showing menory schemes ICE.ZIP HomeTable Contents: Inside Trends Lots reports creates FLOAT.ZIP callable floating markets. Direction Energy question trust executive branch respect freedoms expanded wants. Most Poll
Re: package ownership in Debian
On Mon, 31 Jul 2006 19:30:34 +0300, George Danchev <[EMAIL PROTECTED]> said: > IMHO the maintainer(s) could mention their wishes wrt to NMU and any > particular package in debian/copyright, right after This package was > debianized by ... When needed NMU is appreciated/forbidden/whatever I agree that it could be helpful to document a maintainer's preference somewhere, but I'm not sure that debian/copyright is the right place. Maybe in the PTS, or getting it to show up in some extended view of the BTS, or in db.debian.org (although that won't help non-DDs). I like the LowThresholdNMU idea, but I won't be signing on for that because my own preferences are a bit stricter than what's on that page. It would be nice to document somewhere that I don't mind (well-made) NMUs, but please contact me first -- give me about a week to respond, and if I don't respond by then (and I haven't announced that I'm on vacation), then you can assume that I'm MIA, and NMU to your heart's content. Another question is: right now, LowThresholdNMU is opt-in: add your name to the list if you don't mind NMUs. I wonder how people would feel about changing it so that the default is low-threshold -- for those who don't say anything, we assume by default that NMUs are OK, and if you don't want people to touch your packages, or have other preferences, then you publish that in some generally-known area, wherever we choose to publish that information. (Of course, I think that you should always be allowed to NMU by following the procedures that we already have.) > That will help to avoid some confusion, when people are in doubt wrt > "to NMU or not to NMU". -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Quote: Debian and Democracy at Advocato.org
nice work!
Re: package ownership in Debian
"Gustavo Franco" <[EMAIL PROTECTED]> writes: > Due to the "my stuff, don't touch that!" current approach, but (again) > this is just IMHO. I have had people insist that I needed to maintain a package differently, but they have all been strangely unwilling to post clear applyable patches or make NMUs. They usually say to me something like, "It's your job, not mine!" (And no, I'm not talking about lilypond.) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dh_python and python policy analysis
Hi, I have finished my initial analysis of Python policy and dh_python, and created a rough specification of what the python policy is supposed to be (based on current dh_python behaviour). The current analysis, and future updates, are to be found at http://www.golden-gryphon.com/software/manoj-policy/ The document is a draft, since I have not been involved in Python development, it may have flaws, and I am hoping that people more conversant with Python development would point them out to me. The document could also stand some polishing; and since it was written piecemeal, continuity leaves much to be desired as yet. I am including a text version below. manoj Packaging with the new Python policy A package developers view Manoj Srivastava Copyright (c) 2006 Manoj Srivastava Revision History Revision 1.0 25 Jul 2006 Obstacles to conformance with the new python policy. While the new Python policy, specifically the [1]"Packaged Modules" chapter, contains the elements that must be present in the debian/control filename, it is not very explicit about how the values are to be substituted. The Debian Wiki falls back on calling dh_python, which is not helpful in understanding the actual logic to be followed. This article is an attempt to correct this gap in documentation. -- Table of Contents 1. [2]Introduction 1.1. [3]Categorization of Python software 2. [4]Requirements for packages (new policy) 2.1. [5]XS-Python-Version: 2.2. [6]XB-Python-Version: 2.3. [7]Depends: 2.4. [8]Provides 3. [9]Recipe for developers 3.1. [10]Based on type of python modules being packaged 3.1.1. [11]Script 3.1.2. [12]Private Pure Python Modules 3.1.3. [13]Private Extension 3.1.4. [14]Public pure Python Module 3.1.5. [15]Public Extension 1. Introduction While trying to update SELinux packages, I ran across problems in trying to determine if my packages were complying with the new python policy: any practical tips for packaging generally devolved to the statement "Oh, just run dh_python". This is my attempt to offer more concrete tips for packaging, by reverse engineering dh_python for the specifications and tips. -- 1.1. Categorization of Python software Program/script This consists of software directly called by an end user of external program, and is independently interpreted by the Python interpreter. Usually starts with the magic bytes #!, with the interpreter being /usr/bin/python* or /usr/bin/env python*. Modules This is code included in python "programs/scripts", and not invoked directly (serving as library modules in compiled languages). Modules can be categorized under two orthogonal criteria: firstly, based on the whether or not they are implemented purely in python, like so: Pure Python Module These are python source code, to be interpreted by the Python interpreter just like program/script code is, and may work across many versions of Python. Extension Module Extensions are C code compiled and linked against a specific version of the libpython library, and so can only be used by one version of Python. Another way of categorizing modules is based on whether or not they are available for use by third party scripts/modules. Public Public modules are available for use in other Python scripts or modules using the import directive. They are installed in one of the directories /usr/lib/pythonX.Y/site-packages /usr/lib/pythonX.Y /var/lib/python-support/pythonX.Y /usr/share/pycentral /usr/share/python-support Private Private modules are generally only accessible to a specific program or suite of programs included in the same package. They are installed in special directories, for example: /usr/lib/ /usr/share/ /usr/lib/games/ /usr/share/games/ -- 2. Requirements for packages (new policy) The new python policy places certain requirements for packages that contain Python bits. -- 2.1. XS-Python-Version: The XS-Python-Version field in debian
Re: dh_python and python policy analysis
Manoj Srivastava wrote: > Hi, > > I have finished my initial analysis of Python policy and > dh_python, and created a rough specification of what the python > policy is supposed to be (based on current dh_python behaviour). The > current analysis, and future updates, are to be found at > http://www.golden-gryphon.com/software/manoj-policy/ > > The document is a draft, since I have not been involved in > Python development, it may have flaws, and I am hoping that people > more conversant with Python development would point them out to me. > > The document could also stand some polishing; and since it was > written piecemeal, continuity leaves much to be desired as yet. > > I am including a text version below. > > manoj > > > > > > Packaging with the new Python policy > > A package developers view > > Manoj Srivastava > >Copyright (c) 2006 Manoj Srivastava > >Revision History >Revision 1.0 25 Jul 2006 > Not sure if I missed it, but you seem to claim a copyright but not give an explicit license. I imagine you meant to put it under GPL or a free version of the GFDL. Could you please clarify and also add it to the document? Regards, -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Re: Successful and unsuccessful Debian development tools
On Sun, Jul 30, 2006 at 09:39:26PM +0100, martin f krafft wrote: > Dear fellow developers, > > As many of you know, I am conducting research on Debian, > specifically on how Debian developers adopt or reject new methods of > package maintenance. I would like to get a broad collection of data > for the first part of my research, which is the study of tools that > have been successfully adopted or which have been rejected (so to > speak) by the developer crowd. > > While I already have a good selection, I am on the look for more. > Do you know of a good example of a tool that has successfully shaped > Debian development for a large number of people? Or do you remember > a tool that tried but horribly failed? Those are much harder to > find. :) > > I have Reply-To set for fear of horrible flame wars when one DD > bashes another one's favourite tool, but I will make the results > public, obviously. Thus, I appreciate if you could take the time to > drop me a short note if you have an opinion on the matter. > > I will be blogging about recent developments some time soon, > specifically about the change in direction of my research, so watch > [0] or just read the planet [1] if you are interested. Subversion, in conjunction with alioth, has risen dramatically in Debian to accomodate team-based maintainance. There are of course plenty of challengers, but subversion seems to beat them all. Also, pbuilder and debootstrap are considered absolutely critical for serious work. In terms of failed tools, yada seems to generate a lot of dislike. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ir-kbd-gpio.ko missing from kernel images
Hi All I'm trying to get the infra-red remote control working on my MythTV box and can't find the correct module (ir-kbd-gpio) So, can anyone tell me where I can find, or how I can compile the ir-kbd-gpio.ko module. The module is part of the bttv video4linux driver but the ir-kbd-gpio.c source file seems to be missing from the kernel source tree and the module is not part of the debian kernel images. The bttv 0.9.15 source tar (linux.bytesex.org) contains the file so I guess I could just to compile the module from that but I'd prefer to do it in a more Debian way if possible. Newbie disclaimer: I've built my own nvidia module and compiled the kernel once so I can follow instructions but I'm no guru. Thanks in advance Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
