Re: Josselin Mouette and Planet Debian
On Friday 19 December 2008 19:56, Johannes Wiedersich wrote: > What slightly upsets me about the issue is not what happened, but rather > that the French appear so arrogant as to think what happened on a world > wide announcement is fine, just because the French think it is fine. Do we have any French women on the list who think it's fine? Surely if we are talking about French culture in terms of women then we need some input from the 51% of French people who are female. Also while the claim has been made that French culture supports such things, the claim was not well defined. Is it the culture of French bars and locker rooms or the culture of French government offices and corporations? If it happens that women who work for the French government and French corporations accept such things then still wouldn't be an argument for accepting it in Debian. -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Josselin Mouette and Planet Debian
On Fri, Dec 19, 2008 at 08:31:15PM -0800, Steve Langasek wrote: > On Fri, Dec 19, 2008 at 10:11:25AM +0100, Thomas Weber wrote: > > > No, the problem is that certain of our French developers *think* that the > > > rest of the world just doesn't understand their French humor and that > > > something has been lost in translation. > > > > When the reality is that we understand it just fine, and think they're > > > assholes for it. > > > > It's only a cultural difference if you're counting Kindergarten as a > > > "culture". > > > I find this strange, given that not too long ago you categorized the > > participants of debian-legal as "wankers". > > > http://lists.debian.org/debian-devel/2008/12/msg00174.html > > > Joss' messages can be understood as pretty bad humor. Was your message > > above also meant as a joke? > > No. What part of that message would lead you to think I was joking? Nothing lead me to that, but then I'm not a native English speaker, so I may overlook subtleties. > > Or do you need to let of some steam here, because such behaviour is > > unacceptable on Ubuntu lists? > > There's no ubuntu-legal list infested with leeches who think it's their > business to tell Ubuntu how to interpret its own license requirements > without ever having contributed a line of code to Ubuntu, so I don't think > the analogy holds. Sorry, but I don't think the idea of 'politeness' differs so much over different mailing lists. Either you don't insult people or you do. And my point wasn't about debian-legal, obviously. But rather about people insulting people one day and then finger-pointing at other people insulting other people the next day. If you expect a certain behaviour, the best start is showing it yourself. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Josselin Mouette and Planet Debian
On Sat, Dec 20, 2008 at 07:07:35PM +1100, Russell Coker wrote: > On Friday 19 December 2008 19:56, Johannes Wiedersich > wrote: > > What slightly upsets me about the issue is not what happened, but rather > > that the French appear so arrogant as to think what happened on a world > > wide announcement is fine, just because the French think it is fine. > > Do we have any French women on the list who think it's fine? Surely if we > are > talking about French culture in terms of women then we need some input from > the 51% of French people who are female. > > Also while the claim has been made that French culture supports such things, > the claim was not well defined. Is it the culture of French bars and locker > rooms or the culture of French government offices and corporations? > > If it happens that women who work for the French government and French > corporations accept such things then still wouldn't be an argument for > accepting it in Debian. Could you just all leave the french alone and stop achieving nothing more than pissing us off ? Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Missing Build-Conflicts for non-clean build environments: RC? (was: Re: Bug#508947: Lowering severity)
On Sat, 20 Dec 2008 09:04:13 +0100, Sebastian Andrzej Siewior wrote:
> * David Paleino | 2008-12-19 22:58:07 [+0100]:
>
> >Hello,
> >trying to look at RC bugs, I just stumbled upon this one.
> >IMHO it's not severity serious, since binary packages are built in clean
> >chroots. Hence you don't have wx2.6 installed, but just the Build-Deps, i.e.
> >wx2.8.
> >It's still "important", because it fails on non-clean chroots, i.e. when
> >building on "normal" boxes.
>
> I don't agree with your arguing. Serious is defined as "severe violation
> of Debian policy (roughly, it violates a "must" or "required"
> directive)". Debian policy 7.7 says:
> |Build-Depends, Build-Conflicts
> |The Build-Depends and Build-Conflicts fields must be satisfied when
> |any of the following targets is invoked: build, clean, binary,
> |binary-arch, build-arch, build-indep and binary-indep.
> It does not mention a clean chroot. Afaik it also violates the policy if
> a packages build in fully installed chroot ist linked against
> more/different libraries than the same package build in a clean chroot.
What you're quoting is not relevant: that deals with *satisfying*
Build-{Depends,Conflicts}, not what to put in there.
The relevant section is IMHO:
/---
| Source packages that require certain binary packages to be installed or absent
| at the time of building the package can declare relationships to those binary
| packages.
| This is done using the Build-Depends, Build-Depends-Indep, Build-Conflicts
| and Build-Conflicts-Indep control file fields.
\---
See *at the time of building the package*. This is clearly on buildds (thus, on
clean chroots, even if not specified) for arch: any packages, and on
maintainer's box for arch: all packages (suppposing one would upload source +
binary packages) -- and, in fact, it's maintainer's duty to check FTBFS bugs on
clean sid pbuilder/cowbuilder environments.
Thus, my argument is still there.
Bringing this on -devel, so to have suggestions from other people as well :)
Kindly,
David
--
. ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 | http://snipr.com/qa_page
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
signature.asc
Description: PGP signature
Re: Missing Build-Conflicts for non-clean build environments: RC? (was: Re: Bug#508947: Lowering severity)
On 2008-12-20, David Paleino wrote: >> >Hello, >> >trying to look at RC bugs, I just stumbled upon this one. >> >IMHO it's not severity serious, since binary packages are built in clean >> >chroots. Hence you don't have wx2.6 installed, but just the Build-Deps, = > i.e. >> >wx2.8. >> >It's still "important", because it fails on non-clean chroots, i.e. when >> >building on "normal" boxes. >>=20 >> I don't agree with your arguing. Serious is defined as "severe violation >> of Debian policy (roughly, it violates a "must" or "required" >> directive)". Debian policy 7.7 says:=20 >> |Build-Depends, Build-Conflicts >> |The Build-Depends and Build-Conflicts fields must be satisfied when >> |any of the following targets is invoked: build, clean, binary, >> |binary-arch, build-arch, build-indep and binary-indep. >> It does not mention a clean chroot. Afaik it also violates the policy if >> a packages build in fully installed chroot ist linked against >> more/different libraries than the same package build in a clean chroot. Up to the etch release, I asked release people wether missing build-dependencies was release critical. They said no. I think I also have asked them in the last 6 months and got similar answer, but I'm not as sure about that as it wasn't involving one of my packages, but general rc bug work. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Missing Build-Conflicts for non-clean build environments: RC? (was: Re: Bug#508947: Lowering severity)
On Sat, 20 Dec 2008 10:12:48 + (UTC), Sune Vuorela wrote: > Up to the etch release, I asked release people wether missing > build-dependencies was release critical. They said no. Ok, fine. > I think I also have asked them in the last 6 months and got similar > answer, but I'm not as sure about that as it wasn't involving one of my > packages, but general rc bug work. This is not my package either, general RC bug hunting too ;) Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: First call for votes for the Lenny release GR
> > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > 41b0a520-c6c1-4e7b-8c49-74ee85faf242 > [ 3 ] Choice 1: Reaffirm the Social Contract > [ 1 ] Choice 2: Allow Lenny to release with proprietary firmware [3:1] > [ ] Choice 3: Allow Lenny to release with DFSG violations [3:1] > [ ] Choice 4: Empower the release team to decide about allowing DFSG > violations [3:1] > [ 2 ] Choice 5: Assume blobs comply with GPL unless proven otherwise > [ 4 ] Choice 6: Exclude source requirements for firmware (defined) [3:1] > [ ] Choice 7: Further Discussion > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > signature.asc Description: PGP signature
Re: Bug#509242: ITP: lensfun -- LensCorrection editor plugin
Hi Mark; Sounds very interesting. I'm not (yet) a member, but I guess the pkg-phototools team on alioth would welcome you http://pkg-phototools.alioth.debian.org/ Since tehy already maintain e.g. hugin and panorama tools) (I just wanted to beat KiBi to saying that :-) d (manual resend because of pebkac) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Help needed for #377468
Hi! I would like to ask for some help for the bug #377468, if possible, please. Particularly from a mozilla-plugin wizard. The problem is that djvulibre in upstream is not linked against a particular libXt in order to adapt against different libXt version depending of the browser used. The question raised by the upsteam is the case of the browser itself already uses libXt, and links to a different version of the library than the plugin. This bug is easily demonstrable using the command [1]: $ ldd -d -r /usr/lib/netscape/plugins-libc6/nsdejavu.so But this behavior is quite fragile and could break [2] and I personally think that on debian browser and plugin will use the same version of library. Does my assertion is always valid? Can I enforce linking against libXt at build time? BTW should we contact other plugin developper about bug like this and should we document this issue? Regards Bastien -- "ROUCARIÈS Bastien" roucaries.bastien+deb...@gmail.com --- DO NOT WRITE TO roucaries.bastien+blackh...@gmail.com OR BE BLACKLISTED signature.asc Description: This is a digitally signed message part.
Re: Help needed for #377468
Bastien ROUCARIES wrote: > I would like to ask for some help for the bug #377468, if possible, > please. Particularly from a mozilla-plugin wizard. > The problem is that djvulibre in upstream is not linked against a particular > libXt > in order to adapt against different libXt version depending of the browser > used. > The question raised by the upsteam is the case of the browser itself already > uses libXt, and links to > a different version of the library than the plugin. > This bug is easily demonstrable using the command [1]: > $ ldd -d -r /usr/lib/netscape/plugins-libc6/nsdejavu.so > But this behavior is quite fragile and could break [2] and I personally think > that on debian browser and plugin > will use the same version of library. > Does my assertion is always valid? Can I enforce linking against libXt at > build time? > BTW should we contact other plugin developper about bug like this and should > we document this issue? Just having made this choice w.r.t. to nsdejavu and pthread for properly fixing #504740, I'd recommend adding the libs to NSDEJAVU_LIBS for the reasons Steve explained (the pro becomes even more obvious when you factor in symbol versioning that some libraries may have). Personally, I'd also recommend to go with Steve's opinion on these matters when you don't have one of your own, but that's mostly based on the profound expertise in this area that he demonstrated in Debian over and over again and not an argument in itself. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Help needed for #377468
[dropped even more CCs] roucaries bastien wrote: > It seems other plugins have the same problem. Should I open bug report? Well, that depends a bit: a) some of the symbols in your list (NS_*) might be from stuff that can reasonably be expected to always linked into things loading the plugins. (I don't know, but it should be checked before filing bugs, also see c) ), b) otherwise it seems to be a bug, c) for things that don't break within the set of packages Debian ships, I think fixing them for Lenny is not that important. For stuff that breaks, well, it might be worth fixing if it's easily fixable, but I'd ask for input of the release team before filing. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Help needed for #377468
On Sat, Dec 20, 2008 at 4:22 PM, Thomas Viehmann wrote: > Bastien ROUCARIES wrote: >> I would like to ask for some help for the bug #377468, if possible, >> please. Particularly from a mozilla-plugin wizard. > > Just having made this choice w.r.t. to nsdejavu and pthread for properly > fixing #504740, I'd recommend adding the libs to NSDEJAVU_LIBS for the > reasons Steve explained (the pro becomes even more obvious when you > factor in symbol versioning that some libraries may have). > > Personally, I'd also recommend to go with Steve's opinion on these > matters when you don't have one of your own, but that's mostly based on > the profound expertise in this area that he demonstrated in Debian over > and over again and not an argument in itself. Ok but I will do for my package. It seems other plugins have the same problem. Should I open bug report? $ldd -d -r /usr/lib/mozilla/plugins/* 2>&1 | grep undefined undefined symbol: __gxx_personality_v0 (/usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so) undefined symbol: gdk_window_invalidate_rect (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: cairo_set_operator (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: gdk_cairo_create(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: NS_CStringSetData (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: cairo_destroy (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: gtk_widget_get_type (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: NS_StringContainerFinish (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: NS_Alloc (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: NS_CStringCopy (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: NS_CStringContainerInit (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: cairo_paint (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: cairo_restore (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: NS_GetMemoryManager (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: NS_StringContainerInit (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: gdk_draw_rectangle (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: NS_GetComponentManager (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: gtk_widget_get_screen (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: NS_CStringContainerFinish (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: NS_StringGetData(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: cairo_translate (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: gdk_draw_drawable (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: NS_CStringGetData (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: gtk_object_get_type (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: gtk_button_get_type (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: gdk_window_begin_paint_rect (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: gtk_widget_send_expose (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: gdk_cairo_rectangle (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: gtk_button_get_image(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: gdk_cairo_set_source_pixmap (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: gdk_pixmap_new (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: NS_CStringGetMutableData (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: gtk_settings_get_for_screen (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: cairo_clip (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: NS_GetServiceManager(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: NS_UTF16ToCString (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: NS_CStringContainerInit2 (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: NS_Free (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: cairo_save (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: gdk_window_end_paint(/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: cairo_paint_with_alpha (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: gdk_window_process_updates (/usr/lib/mozilla/plugins/libtotem-basic-plugin.so) undefined symbol: gdk_window_invalidate_rect (/usr/lib/mozilla/plugins/libtotem-complex-plugin.so) undefined
Re: Missing Build-Conflicts for non-clean build environments: RC? (was: Re: Bug#508947: Lowering severity)
On Sat, Dec 20, 2008 at 10:12:48AM +, Sune Vuorela wrote: > >> I don't agree with your arguing. Serious is defined as "severe violation > >> of Debian policy (roughly, it violates a "must" or "required" > >> directive)". Debian policy 7.7 says:=20 > >> |Build-Depends, Build-Conflicts > >> |The Build-Depends and Build-Conflicts fields must be satisfied when > >> |any of the following targets is invoked: build, clean, binary, > >> |binary-arch, build-arch, build-indep and binary-indep. > >> It does not mention a clean chroot. Afaik it also violates the policy if > >> a packages build in fully installed chroot ist linked against > >> more/different libraries than the same package build in a clean chroot. > Up to the etch release, I asked release people wether missing > build-dependencies was release critical. They said no. Er, what? 4. Autobuilding Packages must list any packages they require to build beyond those that are "build-essential" in the appropriate Build-Depends: fields. http://release.debian.org/etch/rc_policy.txt -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Missing Build-Conflicts for non-clean build environments: RC? (was: Re: Bug#508947: Lowering severity)
On 2008-12-20, Steve Langasek wrote: > On Sat, Dec 20, 2008 at 10:12:48AM +, Sune Vuorela wrote: >> >> I don't agree with your arguing. Serious is defined as "severe violation >> >> of Debian policy (roughly, it violates a "must" or "required" >> >> directive)". Debian policy 7.7 says:=20 >> >> |Build-Depends, Build-Conflicts >> >> |The Build-Depends and Build-Conflicts fields must be satisfied when >> >> |any of the following targets is invoked: build, clean, binary, >> >> |binary-arch, build-arch, build-indep and binary-indep. >> >> It does not mention a clean chroot. Afaik it also violates the policy if >> >> a packages build in fully installed chroot ist linked against >> >> more/different libraries than the same package build in a clean chroot. > >> Up to the etch release, I asked release people wether missing >> build-dependencies was release critical. They said no. > > Er, what? Sorry. I was clearly trying to write build-conflicts, but failed. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Help needed for #377468
On Sat, Dec 20, 2008 at 03:50:21PM +0100, Bastien ROUCARIES wrote: > Hi! > > I would like to ask for some help for the bug #377468, if possible, > please. Particularly from a mozilla-plugin wizard. > > The problem is that djvulibre in upstream is not linked against a particular > libXt > in order to adapt against different libXt version depending of the browser > used. > The question raised by the upsteam is the case of the browser itself already > uses libXt, and links to > a different version of the library than the plugin. > I think it should link against libXt in any case. AFAIK libXt properly tracks library version, so linking against it should actually do the right thing. Of course your plugin might only use a super stable subset of the symbols in libXt, but even then i think not linking against the system lib causes troubles. - Alexander -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Josselin Mouette and Planet Debian
On Sat, Dec 20, 2008 at 09:12:46AM +0100, Thomas Weber wrote: > > > Or do you need to let of some steam here, because such behaviour is > > > unacceptable on Ubuntu lists? > > There's no ubuntu-legal list infested with leeches who think it's their > > business to tell Ubuntu how to interpret its own license requirements > > without ever having contributed a line of code to Ubuntu, so I don't think > > the analogy holds. > Sorry, but I don't think the idea of 'politeness' differs so much over > different mailing lists. Either you don't insult people or you do. And > my point wasn't about debian-legal, obviously. But rather about people > insulting people one day and then finger-pointing at other people > insulting other people the next day. There are a couple of differences here that I think are material (or else I wouldn't be behaving in a way that you think is hypocritical). First, I haven't objected that Joss is "insulting" anyone. I object that he publically mocks many of his peers in the Debian project (sometimes singly, sometimes as a class), and he and his apologists insist that this is justified because it's "fun" or "funny", and that people who are offended should all just lighten up instead of taking offense at this lowering of the level of discourse. These people have so little respect for their peers in Debian that they won't even bother with an attempt at civil discussion. They seem to think that putting the "fun" back in Debian means making crass, schoolyard jokes about other people in the project, not about having fun *working on Debian*. While I admit I suffer from the same self-righteousness by deciding who it's ok to insult on the lists, I'm certainly not doing this to amuse myself or others. I do it because I think hangers-on who contribute nothing to Debian but their opinions are a real and serious problem on a number of our lists, and debian-legal in particular where they account for a majority of replies over the past couple of years; and our mailing list policies, conditioned as they are by the knee-jerk "censorship is bad" crowd, don't offer any other way to deal with such problems *except* vigilantism. I don't /enjoy/ sending mails like that. I just believe that they're the lesser evil. I hope a system such as the one being proposed on -project might eventually provide us with a working feedback mechanism to check people's urges to contribute nothing but cheap talk, one that doesn't involve self-appointed enforcers. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: I hereby resign as secretary
On Fri, Dec 19, 2008 at 04:13:37PM +, Michael Banck wrote: > On Thu, Dec 18, 2008 at 11:00:26PM +0100, Pierre Habouzit wrote: > > > On Thu, Dec 18, 2008 at 08:44:11AM -0600, Manoj Srivastava wrote: > > > > As to the people who emailed me that they are putting together a > > > > petition for the DAM to have me removed from the project, I hear you > > > > too. I am going to spend the next few days evaluating how important the > > > > project is to me, and whether I should save you the bother or an > > > > expulsion process. > > > Huh, who talked about expelling Manoj !? > > Doesn't the above paragraph imply that? Right, I skipped it at first read. I was quite shocked, even if I'm among Manoj detractors wrt his work as secretary for the last vote, I see absolutely no reason for an expulsion. That's just silly. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org pgpI8XMOBMZcr.pgp Description: PGP signature
Can I become a Debian package maintainer, how?
Hi, I work with Debian now for a few years. And I like to help the project and also learn more about it... Can I become a Debian package maintainer, how? I'm especially interested in software for making music... Regards, \s -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Can I become a Debian package maintainer, how?
On 2008-12-20T21:17:27, schoappied wrote: > I work with Debian now for a few years. And I like to help the project > and also learn more about it... > Can I become a Debian package maintainer, how? I'm especially interested > in software for making music... http://www.debian.org/devel/join/ /Allan -- Allan Wind Life Integrity, LLC http://lifeintegrity.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Can I become a Debian package maintainer, how?
schoappied writes: > I work with Debian now for a few years. And I like to help the project > and also learn more about it... Thanks for your interest! > Can I become a Debian package maintainer, how? I'm especially > interested in software for making music... One of the smoothest paths to improving Debian and becoming a contributing maintainer is to choose a Debian package that you use yourself, and begin fixing some of its bugs in the bug tracking system http://bugs.debian.org/>. This will be of direct benefit and, since you will be working with the existing maintainers, will also start to teach you about how Debian packages are maintained collaboratively. -- \ “Are you pondering what I'm pondering?” “Well, I think so | `\ Brain, but what if we stick to the seat covers?” —_Pinky and | _o__) The Brain_ | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: problems with the concept of unstable -> testing
Hi, sorry for posting to this thread once more, permit me to get this off my chest. I apologize for the disgraceful lack of civility my posts to this thread and I regret that it reduced your fun in Debian. If you are inclined to do me a favor after all of this, please don't reply to this message. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Can I become a Debian package maintainer, how?
Ben Finney wrote: schoappied writes: I work with Debian now for a few years. And I like to help the project and also learn more about it... Thanks for your interest! Can I become a Debian package maintainer, how? I'm especially interested in software for making music... One of the smoothest paths to improving Debian and becoming a contributing maintainer is to choose a Debian package that you use yourself, and begin fixing some of its bugs in the bug tracking system http://bugs.debian.org/>. This will be of direct benefit and, since you will be working with the existing maintainers, will also start to teach you about how Debian packages are maintained collaboratively. Ok... What to do mean by 'fix bugs'? I think I'm able to build packages, but I'm not a software developer... Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Can I become a Debian package maintainer, how?
schoappied, le Sat 20 Dec 2008 23:48:32 +0100, a écrit : > Ok... What to do mean by 'fix bugs'? I think I'm able to build packages, > but I'm not a software developer... A lot of bugs are packaging issues. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Can I become a Debian package maintainer, how?
On 2008-12-20, schoappied wrote: > Hi, > > I work with Debian now for a few years. And I like to help the project > and also learn more about it... > Can I become a Debian package maintainer, how? I'm especially interested > in software for making music... Try contact the multimedia packaging team. Maintainer: Debian Multimedia Team /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
