--
> Hash: SHA512
>
> - -
> Debian Security Advisory DSA-5800-1 secur...@debian.org
> https://www.debian.org/security/ Salvatore Bonaccorso
> October 29, 2024
-
> > Debian Security Advisory DSA-5800-1 secur...@debian.org
> > https://www.debian.org/security/ Salvatore Bona
On Thu, Mar 18, 2021 at 05:06:45PM +0100, to...@tuxteam.de wrote:
> > *Grant Sanderson (3 Blue 1 Brown)* has released his amazing *mathematics
> > visualization* software Manim (on github). Can you please add it to the
> > *debian
> > repository,* so it can be installed
On Thu, Mar 18, 2021 at 10:54:32AM -0400, Khosro Pourkavoos wrote:
> Good morning,
>
> *Grant Sanderson (3 Blue 1 Brown)* has released his amazing *mathematics
> visualization* software Manim (on github). Can you please add it to the
> *debian
> repository,* so it can be i
Good morning,
*Grant Sanderson (3 Blue 1 Brown)* has released his amazing *mathematics
visualization* software Manim (on github). Can you please add it to the *debian
repository,* so it can be installed using apt?
===
*Manim*:
https://3b1b.github.io/manim/index.html
*3Blue1Brown*:
https
s in conflict with Debian's code of conduct, so be it.
>
> Seconded.
>
> There is not room in the Debian Project for both me and transphobes, and I
> would rather see the Debian Project end than be a safe haven for
> transphobia.
+1
--
cheers,
Holger
---
On Thu, Oct 03, 2019 at 11:18:41AM -0300, Antonio Terceiro wrote:
> I
> think having a single procedure for "meetings" would be a win.
+1
--
cheers,
Holger
---
holger@(debian|rep
e debian/upstream/metadata in the Perl team to easily
> obtain the CPAN distribution name and the bug tracker URL,
> so we can forward patches to CPAN RT or GitHub or mail them
> to the upstream authors:
>
> https://manpages.debian.org/unstable/pkg-perl-tools/dpt-forward.1.en.html
Th
Hello,
On Fri 04 Jan 2019 at 05:29pm GMT, Ulrike Uhlig wrote:
>> Exactly. I understand Ulrike's practical concerns but do not consider
>> them to outweigh the need to avoid permanency. Even writing "possible
>> CoC violation" could hurt someone twenty years down the line.
>
> Ack. I have no str
Hello,
On Fri 04 Jan 2019 at 03:03pm GMT, Ian Jackson wrote:
> Years later someone who did some bad things when they were much
> younger might reasonably come to us and say "can you please redact
> that unfortunate incident from your public web page - it's ancient
> history now". We should be ab
Ulrike Uhlig writes ("Re: Planet Debian revisions"):
> Please, no. A commit message ensures that everybody is aware of the
> removal reason, including planet admins. Resorting to email? I don't
> think emails are encoded in the feeds and we cannot reasonably expect
> people to search for them...
I
On Thu, Nov 16, 2017 at 07:23:23AM +0800, Paul Wise wrote:
> Is this because of it being hard to track the contributions of
> non-uploading DDs?
Not necessarily (but probably true for some case, for example, those we
got DD_nu because of relevant contributions to the debconf orga, that's
not reall
I think if we can find a way to manage it technically, allowing people
to forward email would be a reasonable thing to do.
On Thu, Nov 16, 2017 at 12:23 AM, Mattia Rizzolo wrote:
> non-uploading DD where the MIA team is not looking at.
Is this because of it being hard to track the contributions of
non-uploading DDs?
Is the MIA team looking at contributors.d.o data?
--
bye,
pabs
https://wiki.debian.org/PaulWise
Hello Mattia,
On Wed, Nov 15 2017, Mattia Rizzolo wrote:
> IMHO if somebody care to keep their forward email usable they can very
> well care enough to have a robust enough key and keep it in the
> keyring, and possibly be demoted to non-uploading DD where the MIA
> team is not looking at.
I'd l
On Wed, Nov 15, 2017 at 04:08:41PM +, Ian Jackson wrote:
> It would be possible to have an "emeritus" keyring, I guess. Since it
> would only be used for email forwarding and a few other things, it
> could have weaker security requirements.
Techinically such keyring exists, but they are not e
Peter Palfrader writes ("Re: Emeritus status, and email forwarding"):
> Without a key in a keyring that somebody maintains, authenticating such
> requests, even manually, is going to be a PITA.
Mattia Rizzolo writes ("Re: Emeritus status, and email forwarding"):
> In many cases (such this particul
shirish शिरीष writes ("Reasons for having DPL election terms 1 year"):
> My query how did the idea of having yearly elections for choosing DPL
> come in place.
This was my doing. And, TBH, I don't think I considered other options
very seriously, although I haven't searc
at bottom :-
On 30/08/2017, shirish शिरीष wrote:
> Dear all,
>
> Please CC me if somebody puts a reply .
>
> I had put up the query on debian-devel but was informed that probably
> debian-project would be much better place to have discussions like
> thees.
>
> I did try various terms like 'why is
Dear all,
Please CC me if somebody puts a reply .
I had put up the query on debian-devel but was informed that probably
debian-project would be much better place to have discussions like
thees.
I did try various terms like 'why is Debian Project leader choosen
yearly' and similar queries on sear
- Ian Jackson a écrit :
> Chris Lamb writes ("Re: Request for official help [and 1 more messages]"):
> > For some reason, I did not receive this. Thank you for following up.
> ...
> > I delegate to you :)
>
> Thanks. I will take care of it...
Glad t
Hi Ian,
> I did that on the 31st of July (quoted below). Admittedly leader@ was
> only in the CC, not the To. I have remedied that in this mail.
For some reason, I did not receive this. Thank you for following up.
> > Chris, could you please either nonexclusively delegate this issue to
> > me
On Mon, 06 Feb 2017, Ian Jackson wrote:
> This distributed approach has strengths (which Don points out) but it
> also has weaknesses. Principally, it means that though we advertise a
> single point of contact, that point of contact is mostly a go-between
> and support function for forum-specific t
consequences. [For example, the organizers of an event will know
> the appropriate means of excluding someone from an event, or even if
> that is possible.[1]]
These are all good points.
> Personally, I am very happy to work with the members of the
> antiharassment team to make sur
]] Ian Jackson
> Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers [and
> 1 more messages]"):
> Lars Wirzenius
> > > I suggest a lighter approach than a GR for eroding the strong package
> > > ownership further is to start
Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers [and 1
more messages]"):
Lars Wirzenius
> > I suggest a lighter approach than a GR for eroding the strong package
> > ownership further is to start another page, "LowThresholdHijack" or
&g
]] Lars Wirzenius
> I suggest a lighter approach than a GR for eroding the strong package
> ownership further is to start another page, "LowThresholdHijack" or
> something, listing maintainers who are OK if someone hijacks their
> package if the maintainer isn't taking good care of it. Would anyo
On Mon, Dec 05, 2016 at 08:02:27PM +0100, Laura Arjona Reina wrote:
> I have just created the page:
>
> https://wiki.debian.org/LowThresholdAdoption
>
> and added myself to the list.
I've added myself to the list.
--
I want to build worthwhile things that might last. --joeyh
signature.asc
De
Dear all
El 05/12/16 a las 19:13, Lars Wirzenius escribió:
> We've had the "strong package ownership" concept be a problem in
> various ways. Many years ago people were afraid of making NMUs to fix
> bugs, even RC bugs, and I started the
> https://wiki.debian.org/LowThresholdNmu page. It's got ove
We've had the "strong package ownership" concept be a problem in
various ways. Many years ago people were afraid of making NMUs to fix
bugs, even RC bugs, and I started the
https://wiki.debian.org/LowThresholdNmu page. It's got over 300
maintainers now, and NMUs are quite normal, though I suspect z
Russ Allbery writes ("Re: Replace the TC power to depose maintainers [and 1
more messages]"):
> Ian Jackson writes:
> > The TC has never desposed an existing maintainer, and very rarely even
> > overturned an individual decision.
>
> There is a widespread p
Ian Jackson writes:
> Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
>> We should go for "weak code ownership" instead, which *in theory* is
>> what we already have
> Well, no. What we have is a kind of sticky door when the current code
> owner is cooperative. An
Since I didn't want to sent too many more emails, I'll make three
short replies in one email...
Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
> We should go for "weak code ownership" instead, which *in theory* is
> what we already have
Well, no. What we have is a
Hi,
On Sonntag, 3. Januar 2016, Bernd Zeimetz wrote:
> > what were the criterias to choose to endorse/bless Microsofts
> > platform, or to ask differently: will there be official Debian
> > images (announced in DPN maybe too) for other commercial cloud
> > providers as well?
>
> for which cloud p
On Wed, Jan 6, 2016 at 9:05 PM, Mohsen wrote:
> I need know debian operation system who created or who made it !? 😊
> Thank u for answer I need to win iPod
If you are going to install Debian on the iPod after you get it, then
you can read this link ;)
https://www.debian.org/doc/manuals/project-
I need know debian operation system who created or who made it !? 😊
Thank u for answer I need to win iPod
Mohsen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
On 01/02/2016 03:27 PM, Holger Levsen wrote:
> what were the criterias to choose to endorse/bless Microsofts
> platform, or to ask differently: will there be official Debian
> images (announced in DPN maybe too) for other commercial cloud
> pro
Hi,
(btw, thanks for DPN!)
On Samstag, 2. Januar 2016, Laura Arjona Reina wrote:
> Official Debian Images for Microsoft Azure
>
> The Microsoft Azure platform officially endorses and supports Debian, by
> providing in their marketplace official Debian images, which are created
> in collaboration
ebian communication fora. In
some (many?) cases this could be a reference to the appropriate part
of http://www.debian.org/intro/organization.
I think this means that our IRC chanops need to create an email
address for such things (or publish the address if there is one
already).
Wouter, I looked at
Op 05-11-13 19:53, Ian Jackson schreef:
> Wouter Verhelst writes ("Re: Result of the Code of Conduct BOF at Debconf
> [and 1 more messages]"):
>> Op 15-08-13 11:48, Ian Jackson schreef:
>>> I think the existing draft is far too long. I'd like t
Wouter Verhelst writes ("Re: Result of the Code of Conduct BOF at Debconf [and
1 more messages]"):
> Op 15-08-13 11:48, Ian Jackson schreef:
> > I think the existing draft is far too long. I'd like to propose
> > something much shorter:
For clarity:
Op 15-08-13 11:48, Ian Jackson schreef:
> I think the existing draft is far too long. I'd like to propose
> something much shorter:
>
>
> Debian code of conduct
> --
>
> Debian expects everyone to help keep our community welcoming and fun:
>
> * Be respectful.
To me, the main purpose of a CoC is to clearly set out for the benefit
of forum administrators like listmaster what the project as a whole
expects of participants, and to clearly empower the forum admins to
warn and/or discipline transgressors.
Or to put it another way: for people in general, the
On Sun, Jun 17, 2012 at 7:26 AM, Tollef Fog Heen wrote:
> Yeah, the random forks is quite annoying.
AFAICT github seems to (mostly) exist to encourage this mode of
development; I've even seen projects with "fork me on github" banners
on their website. The projects I work on are fairly inactive in
]] Joey Hess
> Alessandro Ghedini wrote:
> > If anything it may be nice to mirror some "important" Debian software (say
> > dpkg, debhelper, lintian, ...) on GitHub like the Apache Foundation does [0]
> > (also see [1]).
> >
> > AFAIK those mirro
Joey Hess writes:
> In my experience this leads to a raft of badly formed pull requests that
> I cannot triage while offline (see Linus's rant about no diffs) and that
> I have to pull up a bloated web app over https over a modem to look at;
> as well as random forks, none of which are communicat
Alessandro Ghedini wrote:
> If anything it may be nice to mirror some "important" Debian software (say
> dpkg, debhelper, lintian, ...) on GitHub like the Apache Foundation does [0]
> (also see [1]).
>
> AFAIK those mirrors are completely automated and would allow Git
]] Yaroslav Halchenko
> * If we start using this organization as intended (i.e. placing our
> clones for maintained software), since the listing of the
> repositories get sorted by recency, README.Debian will sink to the
> bottom thus killing its visibility and thus its intended purpose
I'
debhelper, lintian, ...) on GitHub like the Apache Foundation does [0]
(also see [1]).
AFAIK those mirrors are completely automated and would allow GitHub users to
follow the development of a few interesting Debian projects. Also, I don't know
of the other git hosting platforms, but it may b
College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe&q
On Fri, Jun 15, 2012 at 05:35:50PM +0100, Ian Jackson wrote:
> So I think Charles came to entirely the right conclusion. I wish we
> could have had longer to talk about this but I guess it's done now.
Well, Charles' suggestion of pointing to the wikipedia page that list
alternatives instead of si
Stefano Zacchiroli writes ("Re: Claiming the "debian" account on GitHub ?"):
> (And please, do not fall into the trap "they offer the service for free,
> we should be nice"; we're experienced enough to know that those who
> offer service for free often gain something out of it. That is entirely
> n
On Thu, Jan 05, 2012 at 12:47:50PM -0500, Yaroslav Halchenko wrote:
> yeap -- totally reasonable -- whenever we find some time, we
> should finalize this... it is sad that
> http://www.debian.org/events/material#flyers
> is not a wiki so entry-barrier to add mentioning of our flier is a bit
> too
On 5 January 2012 18:47, Yaroslav Halchenko wrote:
> may be we should start a wiki page to "collaborate" on this aspect
> before we could push it to w.d.o... sounds reasonable?
Yes, sounds reasonable. But we usually just point from w.d.o to the
wiki instead of replicating (and later synchronising
th:
> http://debian-flyers.alioth.debian.org/
Whenever we were initiating this little "project" we researched
available ones, but they all were too "dusty" iirc. I see now some
recent (February 2011) activity in debian-fliers' CVS, so great to see
it going -- so we have +1 ;)
> &
On 5 January 2012 18:33, Yaroslav Halchenko wrote:
> one of the possible ways for the project to efficiently utilize its
> "booth space" at the conferences is to prepare informative (and
> hopefully catchy) fliers which would highlight different aspects of
> Debian project, showing its versatility
one of the possible ways for the project to efficiently utilize its
"booth space" at the conferences is to prepare informative (and
hopefully catchy) fliers which would highlight different aspects of
Debian project, showing its versatility and spread.
E.g. for our (Neuro)Debian booths at neuroscie
[dE .]
> Look what Microsoft and Apple's is doing with Android. And for any
> task with WP7, you have to have propitiatory applications which're
Microsoft, Apple, Android, and WP7 (whatever that is) are all
off-topic. The debian-project list is about the Debian Project.
You may hate technology
Hello everybody
dE . wrote:
GNU is a wildebeest which's vulnerable to Lions (MS), and sometimes
leopards (Apple), and Debian is one of the wildebeests.
It has to be defended by companies supporting it, and they have to
attempt destroy the Microsoft ecosystem the same way Microsoft does...
other
vailable for mac/Win to do even the simplest task with the phones. And
this's just 1 e.g.; look at their site, they're always doing .NET and
Sliverlight to break compatibility. Not the mention the 6 software
patents...
Do you call that the right track?
Your philosophy may be good f
On Tue, Jan 3, 2012 at 11:47 PM, Andreas Tille wrote:
> The Fedora Medical guy mentioned that there is a lack of management
> work. And I can confirm that this is perfectly what I'm observing in
> several Debian internal projects. To boil it down to some specific
> projects I have observed in th
>>>>> "JM" == Josselin Mouette writes:
JM> Also note that the most popular desktop operating system uses a
JM> release cycle of 3 years, not 1 year.
There is an important difference: Vendors of new devices often provide
working drivers for old versions
On Tue, 03 Jan 2012 03:35:51 +0530, "dE ." wrote:
...
> GNU is a wildebeest which's vulnerable to Lions (MS), and sometimes
> leopards (Apple), and Debian is one of the wildebeests.
Vulnerable, how?
Microsoft put quite some effort into trying to stamp out free software,
and that was Microsoft i
audience (field of endeavor, habbits etc)
> statistics might vary [e.g. 1] ;-)
>
> [1] http://neuro.debian.net/blog/2011/2011-06-27_software_survey.html
I can perfectly confirm this. From a Debian Med perspective I can say
that while there are some comparable initiatives in Fedora and S
I agree. Hate is counter-productive.
>
>> Rather, I personally have a more aggressive philosophy.
>
> Obviously. There's enough aggression on Debian's mailing lists
> already. We surely don't need more of it, more to the opposite.
+1
Jeremiah
--
To UNSUBSCRIBE, emai
dE . wrote:
> Thus, it's critical to hate and make people hate Microsoft and dive into
> politics in order to make opensource desktops successful.
No. Hate is definitively the wrong way to propagate FLOSS.
It should be a "together", not an "against each other". (Counts for
the the big companies
On 01/02/12 03:38, Michael Gilbert wrote:
On Sun, Jan 1, 2012 at 1:21 AM, dE . wrote:
Hi.
I was wondering about the 2 year release cycle of Debian and it's
adaptability on the Desktops.
If you want something with a faster release cycle, there is always
testing, which is updated four ti
On 01/01/12 23:58, Russ Allbery wrote:
"dE ." writes:
http://stats.wikimedia.org/archive/squid_reports/2011-10/SquidReportOperatingSystems.htm
You might have 60% usage of Debian but for the world it's 0.02%.
I've never been fond of putting too much weight on this sort of
statistic.
One of th
On Sun, Jan 1, 2012 at 1:21 AM, dE . wrote:
> Hi.
>
> I was wondering about the 2 year release cycle of Debian and it's
> adaptability on the Desktops.
If you want something with a faster release cycle, there is always
testing, which is updated four times a day.
If you want s
On 01/01/2012 07:28 PM, Russ Allbery wrote:
> "dE ." writes:
>
>> http://stats.wikimedia.org/archive/squid_reports/2011-10/SquidReportOperatingSystems.htm
>
>> You might have 60% usage of Debian but for the world it's 0.02%.
>
> I've never been fond of putting too much weight on this sort of
>
Well put Russ!!!
Relative percentage is not that important as long as absolute number is
positive, which means that fun goes on and our efforts are of
benefit ;)
And depending on the audience (field of endeavor, habbits etc)
statistics might vary [e.g. 1] ;-)
[1] http://neuro.debian.net/blog
"dE ." writes:
> http://stats.wikimedia.org/archive/squid_reports/2011-10/SquidReportOperatingSystems.htm
> You might have 60% usage of Debian but for the world it's 0.02%.
I've never been fond of putting too much weight on this sort of
statistic.
One of the delightful things about Debian is t
Hi,
On Sun, Jan 1, 2012 at 15:16, Josselin Mouette wrote:
> Le dimanche 01 janvier 2012 à 11:51 +0530, dE . a écrit :
>> Further, Desktop systems dont require that much of stability and
>> reliability and even security many times.
>
> This is the sentence with the highes
On 01/01/12 22:05, Josselin Mouette wrote:
Le dimanche 01 janvier 2012 à 16:19 +0530, dE . a écrit :
This is bullshit. Desktop systems don’t have specific release cycle
needs. Also note that the most popular desktop operating system uses a
release cycle of 3 years, not 1 year.
You might not
Le dimanche 01 janvier 2012 à 16:19 +0530, dE . a écrit :
> > This is bullshit. Desktop systems don’t have specific release cycle
> > needs. Also note that the most popular desktop operating system uses a
> > release cycle of 3 years, not 1 year.
>
> You might not have kn
On 01/01/12 21:33, Zlatan Todoric wrote:
dE, I suggest you to look into Debian CUT project. I believe thats
suits your needs if you don't like mixing branches. On the other side
- Debian is giant and complex distribution so there must be all
branches and a aprox.2 yr release cycle.
Zlatan
On 01/01/12 20:04, Adam D. Barratt wrote:
On Sun, 2012-01-01 at 11:51 +0530, dE . wrote:
I was wondering about the 2 year release cycle of Debian and it's
adaptability on the Desktops.
You have to admit that Debian is not used used much on the Desktops --
Really? Of the five systems in my hou
t the most popular desktop operating system uses a
release cycle of 3 years, not 1 year.
You might not have known, but the LTS release is not often used much
You have to admit that Debian is not used used much on the Desktops --
it appears to be more popular for servers; and the 2 year release
On 01/01/12 18:12, Henrique de Moraes Holschuh wrote:
On Sun, 01 Jan 2012, dE . wrote:
I was wondering about the 2 year release cycle of Debian and it's
adaptability on the Desktops.
We cannot do 1 year, it is not enough time to get hard things done
(remember: Debian is _very large_)
On Sun, 2012-01-01 at 11:51 +0530, dE . wrote:
> I was wondering about the 2 year release cycle of Debian and it's
> adaptability on the Desktops.
>
> You have to admit that Debian is not used used much on the Desktops --
Really? Of the five systems in my household which could count as
desktop
system uses a
release cycle of 3 years, not 1 year.
> You have to admit that Debian is not used used much on the Desktops --
> it appears to be more popular for servers; and the 2 year release cycle
> is good for servers; increasing the release cycles to a higher amount is
> also n
On Sun, 01 Jan 2012, dE . wrote:
> I was wondering about the 2 year release cycle of Debian and it's
> adaptability on the Desktops.
We cannot do 1 year, it is not enough time to get hard things done
(remember: Debian is _very large_), and still freeze for enough time to
get things
On the desktops however, in the above context, things differ completely.
There's new hardware available always; within a period of 2 years, the
generation of hardware changes requiring new drivers. Backports are
available, but usually after a timeframe of 1 year, it's unlikely that
the backpo
Hi,
This is Dana Carter with Technology Info Solutions and the reason I am
writing to you is that we help companies in the software industry sector
save a large amount of dollars on generating new and existing business.
We deliver a quality, enterprise -class business integration platfo
Reminder: There will be a meeting to discuss the DebConf12 bids at 20
UTC on 1 March, on #debconf-team on irc.debian.org.
Everyone interested in where DebConf will happen in 2012 is encouraged
to read through the competing bids' documents and attend the meeting.
Agenda:
- Questions fro
On Wed, Jan 19, 2011 at 10:27:39AM +1100, Ben Finney wrote:
> Steve Langasek writes:
> > I am vehemently opposed to Ben's patch, which is effectively an end
> > run around Debian Policy.
> That's a fair criticism. I should make a bug report against Policy.
That's the right place to put it too. It
On ke, 2011-01-19 at 10:27 +1100, Ben Finney wrote:
> Steve Langasek writes:
>
> > I am vehemently opposed to Ben's patch, which is effectively an end
> > run around Debian Policy.
>
> That's a fair criticism. I should make a bug report against Policy.
Good, then I'll apply Charles's patch. Tha
Steve Langasek writes:
> I am vehemently opposed to Ben's patch, which is effectively an end
> run around Debian Policy.
That's a fair criticism. I should make a bug report against Policy.
--
\ “He who wonders discovers that this in itself is wonder.” |
`\
On Tue, Jan 18, 2011 at 11:57:51PM +0200, Lars Wirzenius wrote:
> Charles and Ben have offered competing patches for Source, one making it
> optional (but relying on the policy to make it implicitly mandatory in
> most cases), the other making it required (but allowing just a mention
> of upstream
On Tue, Jan 18, 2011 at 11:57:51PM +0200, Lars Wirzenius wrote:
Charles and Ben have offered competing patches for Source, one making
it optional (but relying on the policy to make it implicitly mandatory
in most cases), the other making it required (but allowing just a
mention of upstream sour
Charles and Ben have offered competing patches for Source, one making it
optional (but relying on the policy to make it implicitly mandatory in
most cases), the other making it required (but allowing just a mention
of upstream sources not existing, when that is the case).
Is anyone in favor of one
Jonas Smedegaard writes:
> I notice that you also add explicit requirement of documenting removal
> of source in the Source: field.
No. Like Charles Plessy, I merely preserved the existing sentence, since
changing it was out of scope for the patch.
--
\ “I knew things were changing when
On Tue, Jan 18, 2011 at 11:15:12AM +1100, Ben Finney wrote:
Ben Finney writes:
I maintain the position I argued earlier in this same thread:
The provenance of the source of any Debian package should be recorded
explicitly, and the copyright file is the canonical location for that
informatio
Ben Finney writes:
> Keeping this field optional makes the provenance of the source more
s/optional/required/
> likely to be clear. It is minimal effort to support that aim (if the
> package is native to Debian, just say so explicitly in this field).
--
\ “Nothing is
Le Tue, Jan 18, 2011 at 12:56:17AM +0100, Jonas Smedegaard a écrit :
>
> I do not, however, agree with sneaking in additional requirements in
> that field:
>
> >+ which is mainly the case for native Debian packages. If the upstream
> >+ source has been modified to remove non-free parts, t
Ben Finney writes:
> I maintain the position I argued earlier in this same thread:
>
> The provenance of the source of any Debian package should be recorded
> explicitly, and the copyright file is the canonical location for that
> information. For packages where “it was only ever a Debian native
On Tue, Jan 18, 2011 at 07:44:03AM +0900, Charles Plessy wrote:
Le Mon, Jan 17, 2011 at 01:18:20PM -0800, Steve Langasek a écrit :
On Mon, Jan 17, 2011 at 10:14:03AM +0100, Dominique Dumont wrote:
> From a parser point of view, this requirement cannot be verified
> unless there's a way to know
Le Mon, Jan 17, 2011 at 01:18:20PM -0800, Steve Langasek a écrit :
> On Mon, Jan 17, 2011 at 10:14:03AM +0100, Dominique Dumont wrote:
>
> > From a parser point of view, this requirement cannot be verified unless
> > there's a way to know if a package is native or not.
>
> True, but unavoidable.
On Mon, Jan 17, 2011 at 10:14:03AM +0100, Dominique Dumont wrote:
> On Saturday 15 January 2011 14:03:39 Lars Wirzenius wrote:
> > I went with the patch below. Thanks Zack, Charles, Andrei.
> > Index: dep5.mdwn
> > ===
> > --- dep5.md
On Saturday 15 January 2011 14:03:39 Lars Wirzenius wrote:
> I went with the patch below. Thanks Zack, Charles, Andrei.
>
> Index: dep5.mdwn
> ===
> --- dep5.mdwn (revision 161)
> +++ dep5.mdwn (working copy)
> @@ -149,12 +149,17
1 - 100 of 267 matches
Mail list logo
