On Sun, Jan 21, 2024 at 10:52:02AM +0100, Jonas Smedegaard wrote:
> I can offer to maintain hosting and packaging of debtags code projects.
> Would that be helpful, or are/were you looking for new code maintainer?
Thank you for your interest! Personally I am not motivated to look after
Debtags an
Hi Enrico (cc d-devel list),
Quoting Enrico Zini (2022-10-19 15:20:43)
> I would like to let go of the responsibility of maintaining
> debtags.debian.org.
>
> Over the years I did my best to simplify the whole system, so picking up
> maintenance shouldn't be too hard, if there is interest.
>
> I
I demand that Arno Töll may or may not have written...
[snip]
> 2) ... Drive-by sponsoring does not work. It's annoying and back-breaking
> to the sponsored maintainer to have a package containing lots of fixes and
> maybe a new upstream version but nobody who uploads the you've been working
> on
Arno Töll writes:
> On 13.06.2012 17:35, Ian Jackson wrote:
> > 1. Change the definition of the Maintainer field to permit multiple
> >entries.
>
> There were probably technical reasons back then when introducing
> Uploaders. Maybe someone knows.
I don't know of technical concerns there.
Bu
Le Wed, Jun 13, 2012 at 06:47:32PM +0200, Gergely Nagy a écrit :
>
> I think that would fit into debian/README.source nicely.
Le Wed, Jun 13, 2012 at 06:54:35PM +0200, Arno Töll a écrit :
>
> README.source though, as people suggested in IRC.
Le Wed, Jun 13, 2012 at 11:25:43PM +0200, Ansgar Burc
Hi,
Ian Jackson writes:
> I think the first three can be fixed relatively simply. I propose the
> following changes:
>
> 1. Change the definition of the Maintainer field to permit multiple
>entries.
>
>There are currently four different entities (3 humans and a
>corporation) which us
Hi,
On 13.06.2012 19:46, Michael Gilbert wrote:
> I'm really not sure what your definition of drive-by is. Sometimes
> I'll make time to look at a package interesting me, I'll communicate
> with the sponsoree, upload it if they address my concerns, then follow
> it for a little while to make sure
On Wed, Jun 13, 2012 at 1:35 PM, Arno Töll wrote:
> Hi,
>
> as a clarification, because I was pointed to it:
>
> On 13.06.2012 18:54, Arno Töll wrote:
>> Drive-by sponsoring makes this even more complicated and is not helping
>> anybody. We should stop advocating drive-by sponsoring at all.
>
> ...
Hi,
as a clarification, because I was pointed to it:
On 13.06.2012 18:54, Arno Töll wrote:
> Drive-by sponsoring makes this even more complicated and is not helping
> anybody. We should stop advocating drive-by sponsoring at all.
... with the exception of evident cases like RC bug fixes, emergen
Ian Jackson writes:
> So for example, DDs have enormous theoretical power but there are
> strong and well documented social controls on how they should exercise
> that. I think as a matter of principle that the same principle should
> apply to DMs: it is easy to remove a misbehaving DM from Uplo
Hi,
first: thank you. Recent threads show, we clearly need a discussion like
this and hopefully people will take it as an opportunity to leave this
thread a bit more enlightened.
On 13.06.2012 17:35, Ian Jackson wrote:
>Instead, when a package team
> or lead maintainer accepts someone into Upload
* Ian Jackson [120613 17:35]:
> 5. Introduce a new conventional location for information useful to
>NMUers,
> debian/README.nmu
>
>Explicitly state that someone preparing or sponsoring an NMU should
>consult this file. Statements in this file may supplement, but do
>not over
* Kurt Roeckx (k...@roeckx.be) [110910 15:38]:
> We changed this some time ago and made $arch readable by anybody,
> the mbox's are at:
> buildd.debian.org:/org/buildd.debian.org/mbox/
>
> We've ask the security team to use wb-t...@buildd.debian.org
> instead, which is not public available.
Ok wi
On Sat, Sep 10, 2011 at 05:50:29PM +, brian m. carlson wrote:
> On Sat, Sep 10, 2011 at 01:27:01PM +, Felipe Sateler wrote:
> > On Thu, 08 Sep 2011 19:34:41 +0200, Andreas Barth wrote:
> > > I disagree with "let's first remove things". If a package like ruby
> > > doesn't build on sparc thi
On Sat, Sep 10, 2011 at 03:33:06PM +0200, Kurt Roeckx wrote:
> On Thu, Sep 08, 2011 at 07:34:41PM +0200, Andreas Barth wrote:
> >
> > > - Being able to judge whether the maintainers have done their part in
> > > reaching out to porters is a requisite for the above. And to do so, we
> > > reall
On Sat, Sep 10, 2011 at 01:27:01PM +, Felipe Sateler wrote:
> On Thu, 08 Sep 2011 19:34:41 +0200, Andreas Barth wrote:
> > I disagree with "let's first remove things". If a package like ruby
> > doesn't build on sparc this bug report is RC exactly as long as sparc is
> > a release arch. The rel
On Thu, Sep 08, 2011 at 07:34:41PM +0200, Andreas Barth wrote:
>
> > - Being able to judge whether the maintainers have done their part in
> > reaching out to porters is a requisite for the above. And to do so, we
> > really need more visibility of those exchanges. According to devref
> > [1
On Thu, 08 Sep 2011 19:34:41 +0200, Andreas Barth wrote:
> * Stefano Zacchiroli (z...@debian.org) [110908 19:22]:
>> Hopefully, not having $pkg on $arch would raise the visibility of the
>> issue and attract attention to fix the issue. In the meantime, the
>> fact that $pkg is not on $arch
* Stefano Zacchiroli (z...@debian.org) [110908 19:53]:
> On Thu, Sep 08, 2011 at 07:34:41PM +0200, Andreas Barth wrote:
> > Yes. Because one of the most frequent users is the security team
> > asking where this and that security build is. We don't want that
> > public for obvious reasons.
>
> > T
[ No Cc: please ]
On Thu, Sep 08, 2011 at 07:34:41PM +0200, Andreas Barth wrote:
> I disagree a bit here, tripple actually.
Actually, I think we are in agreement:
- I've said that contacting the porters is a prerequisite before
fiddling with the Arch list. RM is the last option.
- With "fiddl
* Stefano Zacchiroli (z...@debian.org) [110908 19:22]:
> I think maintainers should be empowered more to fiddle with the
> Architecture list of their packages, but also that they should give
> some sort of explanation (as simple as bug report pointers) for the
> architectures they do not su
On Mon, Aug 29, 2011 at 08:58:34AM +0200, Lucas Nussbaum wrote:
> TL;DR: I think that we should have a discussion about the respective
> roles & responsibilities of maintainers and porters with regard to
> porting.
I've re-read this discussion a couple of times, with the intention of
summarizing i
Le Wed, Aug 31, 2011 at 10:14:41PM +0200, Bernd Zeimetz a écrit :
>
> The mipsel port is used by the Lemote Notebooks/mini Desktops for example,
> which come pre-installed with Debian. Not sure if they have popcon enabled
> at all. And I guess mipsel is more a target for Embedian. No idea about u
On Wed, Aug 31, 2011 at 02:42:41PM +0200, Lucas Nussbaum wrote:
> On 31/08/11 at 12:58 +0100, Ben Hutchings wrote:
> > On Wed, 2011-08-31 at 11:57 +0200, Lucas Nussbaum wrote:
> > [...]
> > > But a different thread library that has clear POSIX compliance bugs[*]
> > > is the kind of things that mak
On 08/31/2011 01:45 PM, Charles Plessy wrote:
> Le Wed, Aug 31, 2011 at 11:35:59AM +0200, Andreas Barth a écrit :
>> * Lucas Nussbaum (lu...@lucas-nussbaum.net) [110831 10:56]:
>>> Also, in the case of architectures targetted at embedded systems (I'm
>>> thinking about mips and mipsel), what is imp
On Tue, Aug 30, 2011 at 11:05:03AM +0200, Bernhard R. Link wrote:
>
> (And try to imagine how hard it would have been to introduce amd64
> if alpha had not elliminated in many years work most of the subtle
> 64 bit bugs found in most software, I doubt porters alone could have
> completed this in t
On Wed, Aug 31, 2011 at 02:52:53PM +0100, Ian Jackson wrote:
> Let me make an alternative proposal:
>
> * The root cause bug in the BTS would be given a special tag
>("arch-blocker:" or something). I will call such a bug which
>is open and has existed in this state for 30 days a "ripe ar
On Wed, Aug 31, 2011 at 04:30:56AM +, Felipe Sateler wrote:
>
> I think some clarification needs to be done for these types of errors. I
> sometimes get a (serious) bug reported against one of my packages because:
>
> 1. python errored out with a glibc-detected error
> 2. gcc broke in some w
Lucas Nussbaum writes ("Maintainers, porters, and burden of porting"):
> However, issues such as miscompilation or broken syscall or libc
> semantics are largely undetected. To illustrate this, you can have a
> look at #635126 (miscompilation on armel and sparc) and #639658
> (forks+threads fun on
On 2011-08-31, Paul Wise wrote:
> On Tue, Aug 30, 2011 at 10:34 AM, Lars Wirzenius wrote:
>> But both are wrong, too: it's always the job of both. It's not supposed
>> to be a struggle between maintainers and porters, but everyone in
>> Debian against bugs and shortcomings of our system. Also, nei
On 31/08/11 at 12:58 +0100, Ben Hutchings wrote:
> On Wed, 2011-08-31 at 11:57 +0200, Lucas Nussbaum wrote:
> [...]
> > But a different thread library that has clear POSIX compliance bugs[*]
> > is the kind of things that make me fear that many more packages than we
> > see currently are broken on
On Wed, 2011-08-31 at 11:57 +0200, Lucas Nussbaum wrote:
[...]
> But a different thread library that has clear POSIX compliance bugs[*]
> is the kind of things that make me fear that many more packages than we
> see currently are broken on kfreebsd. And I'm not sure that it's where
> we want to spe
Le Wed, Aug 31, 2011 at 11:35:59AM +0200, Andreas Barth a écrit :
> * Lucas Nussbaum (lu...@lucas-nussbaum.net) [110831 10:56]:
> > Also, in the case of architectures targetted at embedded systems (I'm
> > thinking about mips and mipsel), what is important is that Debian
> > infrastructure supports
Lucas Nussbaum, le Wed 31 Aug 2011 12:25:24 +0200, a écrit :
> So, it's a really interesting project, but not really a proof of
> widespread kfreebsd usage in high-demand production environments like
> you seem to imply ;)
Well, I didn't want to imply anything at all, just that it was a
decision t
On 31/08/11 at 12:03 +0200, Samuel Thibault wrote:
> Andreas Barth, le Wed 31 Aug 2011 11:35:59 +0200, a écrit :
> > I know people who put kbsd on edge firewalls because it's way easier
> > for a standard linux / debian admin.
>
> We are considering this in our ISP, as well.
Come on, Samuel. You
* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110831 12:07]:
> On 31/08/11 at 11:40 +0200, Andreas Barth wrote:
> > * Lucas Nussbaum (lu...@lucas-nussbaum.net) [110831 07:34]:
> > > Being in the second set would be fine, and would not be a step towards
> > > being thrown out of Debian. Maintainers s
On Tue, Aug 30, 2011 at 10:34 AM, Lars Wirzenius wrote:
> But both are wrong, too: it's always the job of both. It's not supposed
> to be a struggle between maintainers and porters, but everyone in
> Debian against bugs and shortcomings of our system. Also, neither group
> is homogenous, and it's
On 31/08/11 at 11:40 +0200, Andreas Barth wrote:
> * Lucas Nussbaum (lu...@lucas-nussbaum.net) [110831 07:34]:
> > Being in the second set would be fine, and would not be a step towards
> > being thrown out of Debian. Maintainers should still help porters get
> > their packages ported, etc. But it
On 31/08/11 at 11:24 +0200, Cyril Brulebois wrote:
> Lucas Nussbaum (31/08/2011):
> > hurd-i386, kfreebsd-i386 and kfreebsd-amd64 are probably too
> > experimental to be used on production systems. For kfreebsd, my main
> > problem (with my Ruby hat) is the linuxthreads-based thread library, but
>
Andreas Barth, le Wed 31 Aug 2011 11:35:59 +0200, a écrit :
> I know people who put kbsd on edge firewalls because it's way easier
> for a standard linux / debian admin.
We are considering this in our ISP, as well.
Samuel
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
On 08/31/2011 11:35 AM, Andreas Barth wrote:
> * Lucas Nussbaum (lu...@lucas-nussbaum.net) [110831 10:56]:
>> Also, in the case of architectures targetted at embedded systems (I'm
>> thinking about mips and mipsel), what is important is that Debian
>> infrastructure supports the development of thos
* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110831 07:34]:
> Regarding architectures, we made releases with a semi-official status on
> two occasions at least (etch-m68k and kfreebsd in squeeze).
I hope you see the difference between etch-m68k and kbsd.
Kbsd is "too new", whereas etch-m68k was (
* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110831 10:56]:
> Also, in the case of architectures targetted at embedded systems (I'm
> thinking about mips and mipsel), what is important is that Debian
> infrastructure supports the development of those architectures, but I
> don't think that there's
Lucas Nussbaum (31/08/2011):
> hurd-i386, kfreebsd-i386 and kfreebsd-amd64 are probably too
> experimental to be used on production systems. For kfreebsd, my main
> problem (with my Ruby hat) is the linuxthreads-based thread library, but
> there might be other problems.
http://lists.debian.org/87
* Kurt Roeckx [110831 00:01]:
> On Mon, Aug 29, 2011 at 01:06:15PM +0200, Lucas Nussbaum wrote:
> I think to have a useful discussion we need to start with the
> different kind of failures we can actually see that are arch
> dependend. Some of those shows up on only 1 or 2 arches, some
> show up
* Lucas Nussbaum [110831 10:56]:
> Note that I'm not saying that we should get rid of them. Only that we
> should move them out of the "critical path". If there are active buildd
> admins, I don't see why they couldn't continue to use Debian
> infrastructure.
And let the software in Debian rot mo
On 31/08/11 at 10:37 +0200, Bernd Zeimetz wrote:
> On 08/31/2011 07:34 AM, Lucas Nussbaum wrote:
> > I've always wondered what was the point of having some architectures
> > part of stable releases as official architectures. Sure, they are very
> > useful as experimental architectures, and very fun
On 08/31/2011 07:34 AM, Lucas Nussbaum wrote:
> I've always wondered what was the point of having some architectures
> part of stable releases as official architectures. Sure, they are very
> useful as experimental architectures, and very fun to work on, but it's
> unlikely that people will use the
On 30/08/11 at 10:34 +0100, Lars Wirzenius wrote:
> But both are wrong, too: it's always the job of both. It's not supposed
> to be a struggle between maintainers and porters, but everyone in
> Debian against bugs and shortcomings of our system.
Sure. But what happens when bugs and shortcomings ar
On Wed, 31 Aug 2011 00:01:07 +0200, Kurt Roeckx wrote:
> On Mon, Aug 29, 2011 at 01:06:15PM +0200, Lucas Nussbaum wrote:
>> >
>> > Sorry, but I disagree here. I don't think it is reasonable to expect
>> > porters to check for build failures in general, especially as many of
>> > them just happen
On Mon, Aug 29, 2011 at 01:06:15PM +0200, Lucas Nussbaum wrote:
> >
> > Sorry, but I disagree here. I don't think it is reasonable to expect
> > porters to check for build failures in general, especially as many of
> > them just happen because of generic maintainer errors and
> > cross-architectur
In the blue corner, we have The Maintainer, who says: "I have a problem
with one architecture, and my package does not work there. It's The
Porter's job to debug and fix that. They know what's usually broken
on their architecture, so it's easier for them."
In the green corner, we have The Porter,
On 08/29/2011 07:15 PM, Lucas Nussbaum wrote:
> On 29/08/11 at 18:21 +0200, Bernd Zeimetz wrote:
>> On 08/29/2011 04:49 PM, Lucas Nussbaum wrote:
>>> I'm also completely tired of investigating issues which are already
>>> known to porters, which is unavoidable if each maintainer is asked
>>> to fir
* Lucas Nussbaum [110829 19:28]:
> I think that bugs caused by important differences compared to other
> Debian architectures are the porter's job to handle, not the
> maintainer's.
> That includes stuff like:
> - missing/different packages on $ARCH
> - missing/different libraries on $ARCH
> - dif
On 2011-08-29, Russ Allbery wrote:
> Samuel Thibault writes:
>> Lucas Nussbaum, le Mon 29 Aug 2011 16:49:17 +0200, a écrit :
>>> Those packages should be set Not-For-Us anyway, no? So they still need
>>> an action from porters or buildd maintainers.
>> We want to avoid Not-For-Us. Maintainers sho
* Russ Allbery (r...@debian.org) [110829 20:42]:
> Samuel Thibault writes:
> > Lucas Nussbaum, le Mon 29 Aug 2011 16:49:17 +0200, a écrit :
>
> >> Those packages should be set Not-For-Us anyway, no? So they still need
> >> an action from porters or buildd maintainers.
>
> > We want to avoid Not-
Russ Allbery (29/08/2011):
> Does this work now? Previously, setting the architecture list didn't
> do anything useful if the source package built at least one arch: all
> package.
Since arch: all as per-arch (…) now, I guess that limitation is gone.
And yes, arch restrictions have been working
Samuel Thibault writes:
> Lucas Nussbaum, le Mon 29 Aug 2011 16:49:17 +0200, a écrit :
>> Those packages should be set Not-For-Us anyway, no? So they still need
>> an action from porters or buildd maintainers.
> We want to avoid Not-For-Us. Maintainers should simply set the
> architecture list.
Lucas Nussbaum wrote:
> We might chose to make ruby1.9.1 the default ruby implementation for
> wheezy (instead of ruby1.8). I still hope that all porting issues
> affecting ruby1.9.1 will be resolved.
> But if it's down to those four choices, what should I do in a couple of
> weeks, when the new
Hi Lucas,
Lucas Nussbaum wrote:
> But if porting software to
> KFreeBSD's linuxthreads-based threading library with slightly broken
> semantics becomes my own task, I won't try to solve issues on KFreeBSD
> and instead stop supporting it, because I just don't have the time to do
> that.
That sou
On Mon, Aug 29, 2011 at 04:49:17PM +0200, Lucas Nussbaum wrote:
> On 29/08/11 at 16:16 +0200, Bernd Zeimetz wrote:
> > or test suites failing for various random reasons.
> Like what? In my experience rebuilding the archive on amd64, there are
> only a handful of packages where the test suite fails
On 29/08/11 at 18:21 +0200, Bernd Zeimetz wrote:
> On 08/29/2011 04:49 PM, Lucas Nussbaum wrote:
> [...]
> >> In my experience you would get a lot of issues which are nothing porters
> >> need to solve, like libraries not being available as the hardware just
> >> doesn't exist for that architecture
* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110829 13:10]:
> If you take a list of packages that failed on $PORTER_ARCH, but built
> fine on at least two or three other architectures, do you really expect
> to get many false positives (i.e, non-arch-specific problems)?
If we have methods which pr
On 08/29/2011 04:49 PM, Lucas Nussbaum wrote:
[...]
>> In my experience you would get a lot of issues which are nothing porters
>> need to solve, like libraries not being available as the hardware just
>> doesn't exist for that architecture
>
> Those packages should be set Not-For-Us anyway, no? S
On 29/08/11 at 13:06 +0200, Lucas Nussbaum wrote:
> If you take a list of packages that failed on $PORTER_ARCH, but built
> fine on at least two or three other architectures, do you really expect
> to get many false positives (i.e, non-arch-specific problems)?
Such a list would be easy to generate
Lucas Nussbaum, le Mon 29 Aug 2011 16:49:17 +0200, a écrit :
> On 29/08/11 at 16:16 +0200, Bernd Zeimetz wrote:
> > On 08/29/2011 01:06 PM, Lucas Nussbaum wrote:
> > > On 29/08/11 at 09:47 +0200, Andreas Barth wrote:
> > >> * Lucas Nussbaum (lu...@lucas-nussbaum.net) [110829 08:59]:
> > >>> I'd lik
On 29/08/11 at 16:16 +0200, Bernd Zeimetz wrote:
> On 08/29/2011 01:06 PM, Lucas Nussbaum wrote:
> > On 29/08/11 at 09:47 +0200, Andreas Barth wrote:
> >> * Lucas Nussbaum (lu...@lucas-nussbaum.net) [110829 08:59]:
> >>> I'd like to reinforce the fact that it's the porters' responsibility
> >>> to
On 08/29/2011 01:06 PM, Lucas Nussbaum wrote:
> On 29/08/11 at 09:47 +0200, Andreas Barth wrote:
>> * Lucas Nussbaum (lu...@lucas-nussbaum.net) [110829 08:59]:
>>> I'd like to reinforce the fact that it's the porters' responsibility
>>> to investigate porters issues, and propose the following
>>>
On 29/08/11 at 09:47 +0200, Andreas Barth wrote:
> * Lucas Nussbaum (lu...@lucas-nussbaum.net) [110829 08:59]:
> > I'd like to reinforce the fact that it's the porters' responsibility
> > to investigate porters issues, and propose the following
> > responsibilities:
> > (1) It is the responsibilit
* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110829 08:59]:
> I'd like to reinforce the fact that it's the porters' responsibility
> to investigate porters issues, and propose the following
> responsibilities:
> (1) It is the responsibility of porters to:
> - track architecture-specific bugs (
Thanks to the people in the library at the college I attended.
I believe this is the same as or very similar to the one I used:
Title: Information technology: GNVQ Advanced
Names: Knott, Geoffrey (Author); Waites, Nick (Author)
Publisher: Business Education Publications
Date: 1997
ISBN: 1901888
See the email I sent after wards. It has the same subject (and sorry, it
is quite long).
In short I suppose the material answer to your question would be:
A set of books and for quick sale of the proposal possibly having a few
people run localized linux terminal servers that allow colleges to h
On Mon, 2007-03-05 at 10:33 +, Howard Young wrote:
> I know of a way that maintainers could be increased substantially (I
> expect hundreds to many thousands a year).
> I am not sure of the specifics but I have little doubt that in the end
> it would work.
> It will likely take more than four
Tollef Fog Heen writes:
> Are you able to claim that source code written is not under copyright in
> any way? It's less than 70 years after the author's death (even for
> really old code from, say, 1950) and if it clearly is copyrightable, it
> will be under copyright.
If it was written by a US g
* Anthony DeRobertis
| Well, isn't prohibiting the "I didn't know it is copyrighted" defence
| the only legal effect of having the notice nowadays, anyway?
Are you able to claim that source code written is not under copyright
in any way? It's less than 70 years after the author's death (even
fo
Hello Anthony,
Anthony DeRobertis <[EMAIL PROTECTED]> wrote:
> Jeremy Stanley wrote:
>>This has to include a copyright year, also.
>>
>> ...and following additional discussion, the resolution is:
>>
>>After considering the suggestion, I have decided to close this
>>bug.
>>
> The yea
Scripsit Anthony DeRobertis <[EMAIL PROTECTED]>
> On Tue, Mar 28, 2006 at 03:51:30PM +0200, Henning Makholm wrote:
>> Only for some pretty strange values of "worthless". AFAIU the only
>> legal effect of the notice requirements you cite is as defined by
>> subsection (d): if a compliant notice is
On Tue, Mar 28, 2006 at 03:51:30PM +0200, Henning Makholm wrote:
> Only for some pretty strange values of "worthless". AFAIU the only
> legal effect of the notice requirements you cite is as defined by
> subsection (d): if a compliant notice is present, a defendant is
> excluded from the defense t
Scripsit Anthony DeRobertis <[EMAIL PROTECTED]>
> The year really should be included. At least in the US, not having a
> year in the notice appears to make the notice worthless. Quoting Title
> 17 USC Sec. 401(b):
Only for some pretty strange values of "worthless". AFAIU the only
legal effect of
Jeremy Stanley wrote:
This has to include a copyright year, also.
...and following additional discussion, the resolution is:
After considering the suggestion, I have decided to close this
bug.
The year really should be included. At least in the US, not having a
year in the notice a
Hi,
* Frank Küster <[EMAIL PROTECTED]> [2006-03-27 17:40]:
> Joerg Jaspert <[EMAIL PROTECTED]> wrote:
> > On 10605 March 1977, Nico Golde wrote:
> >> * Joerg Jaspert <[EMAIL PROTECTED]> [2006-03-26 20:31]:
> >>> A while ago Peter 'weasel' Palfrader wrote a nice little "How (not) to
> >>> write copy
Joerg Jaspert <[EMAIL PROTECTED]> wrote:
> On 10605 March 1977, Nico Golde wrote:
>
>> * Joerg Jaspert <[EMAIL PROTECTED]> [2006-03-26 20:31]:
>>> A while ago Peter 'weasel' Palfrader wrote a nice little "How (not) to
>>> write copyright files"[1]. Please read that *now*.
>>> [1] http://lists.debi
I just can't locate copyright statement anywhere within the package --
only license file (MPL 1.1/GPL 2.0/LGPL 2.1)
is copyright assumed to belong to upstream author? what years then
should be mentioned?
--
.-.
=-- /v\
On Sun, Mar 26, 2006 at 08:48:31PM +0200, Nico Golde wrote:
> * Joerg Jaspert <[EMAIL PROTECTED]> [2006-03-26 20:31]:
> > A while ago Peter 'weasel' Palfrader wrote a nice little "How (not) to
> > write copyright files"[1]. Please read that *now*.
> >
> > [1] http://lists.debian.org/debian-devel-a
On 10605 March 1977, Nico Golde wrote:
> * Joerg Jaspert <[EMAIL PROTECTED]> [2006-03-26 20:31]:
>> A while ago Peter 'weasel' Palfrader wrote a nice little "How (not) to
>> write copyright files"[1]. Please read that *now*.
>> [1] http://lists.debian.org/debian-devel-announce/2003/12/msg7.htm
Quoting Christian Perrier ([EMAIL PROTECTED]):
> The closer sarge release is, the higher the problem I'll write about
> below becomes annoying.
BTW, folks, sorry for having written so badly.I realize that my english
wasn't really good this morningI really shouldn't try to write
good englis
On Tue, Apr 15, 2003 at 08:31:16AM +0100, Mark Howard wrote:
> On Mon, 2003-04-14 at 08:44, Andrew Suffield wrote:
> > This is a sorted (worst offenders first) list of maintainers who have
> > excessive numbers of old RC bugs open against their packages.
> Great work... Just wish I wasn't on there.
On Tue, 15 Apr 2003, LapTop006 wrote:
> > Is there any better way of keeping snapshot packages out of testing than
> > RC bugs?
> > Picking a random architecture and making its builds fail is not a valid
> > answer :)
> I had been thinking that, something like a control feild "Dists:
> unstable" (
On Tue, Apr 15, 2003 at 08:31:16AM +0100, Mark Howard arranged a set of bits
into the following:
> On Mon, 2003-04-14 at 08:44, Andrew Suffield wrote:
> > This is a sorted (worst offenders first) list of maintainers who have
> > excessive numbers of old RC bugs open against their packages.
> Great
On Mon, 2003-04-14 at 08:44, Andrew Suffield wrote:
> This is a sorted (worst offenders first) list of maintainers who have
> excessive numbers of old RC bugs open against their packages.
Great work... Just wish I wasn't on there.
Is there any better way of keeping snapshot packages out of testin
> "Colin" == Colin Watson <[EMAIL PROTECTED]> writes:
Colin> Assuming you're <[EMAIL PROTECTED]>, you have
Colin> four open release-critical bugs, none of which have had any
Colin> response, and three of which have been open since October.
Nope, that's a screwup on my part. The bu
On Mon, Apr 14, 2003 at 09:22:45PM +0100, Andrew Suffield wrote:
> And introduces the people who adopted the offending packages:
> Martin Butterweck ([EMAIL PROTECTED])
Or not; I edited him out manually (pingus, which is orphaned and being
adopted very slowly) the first time around and forgot to
Figures, there was a bug inherited from the original script that could
(semi-randomly) assign packages to the old maintainer if they were
adopted since potato. I have also filtered out packages which have
been removed from unstable but are still present in older suites. That
knocks the following pe
On Mon, Apr 14, 2003 at 04:20:45PM +0200, Josef Spillner wrote:
> On Monday 14 April 2003 09:44, Andrew Suffield wrote:
> > This is a sorted (worst offenders first) list of maintainers who have
> > excessive numbers of old RC bugs open against their packages. Bugs
> ...
> > Josef Spillner
>
> Your
On Monday 14 April 2003 09:44, Andrew Suffield wrote:
> This is a sorted (worst offenders first) list of maintainers who have
> excessive numbers of old RC bugs open against their packages. Bugs
...
> Josef Spillner
Your script is buggy, fix it :-)
Are sponsored NMUs allowed in case of RC bugs ri
On Mon, Apr 14, 2003 at 11:21:48AM +0200, Andreas Tille wrote:
> On Mon, 14 Apr 2003, Andrew Suffield wrote:
>
> > If you don't understand why you are on this list, use the "maintainer
> > address" query on http://bugs.debian.org/ and look for old RC bugs. If
> > you still don't understand, mail m
On Mon, 14 Apr 2003, Andrew Suffield wrote:
> If you don't understand why you are on this list, use the "maintainer
> address" query on http://bugs.debian.org/ and look for old RC bugs. If
> you still don't understand, mail me and I'll tell you.
You just should add the "maintainer address" to this
On Sat, Sep 09, 2000 at 10:35:21AM +0100, Philip Blundell wrote:
> Are there any maintainers in Cambridge who would be willing to sign my GPG
> key?
You might be better off sending this to the debian-uk list,
[EMAIL PROTECTED] But I think most people there also read
-devel.
There are a number of
98 matches
Mail list logo
