This topic came up on #debian-devel today. It was mentioned by Paul
Wise, that listing a copyright holder for files which are in the public
domain is wrong. But apparently we don't have a defined way to express
that in debian/copyright. Looking at codesearch [1], I find variations like
Copyright:
On Fri, 26 Aug 2016 12:10:08 +0200 Ansgar Burchardt
wrote:
> Package: debian-policy
> Severity: normal
>
> Upstart is no longer part of Debian[1] nor actively maintained
> upstream. Policy should drop references to it as an alternative init
> system.
>
> I've attached a patch to remove section
On Fri, 31 Jul 2015 13:16:24 +0200 Guillem Jover wrote:
> Hi!
>
> On Fri, 2015-07-31 at 11:34:20 +0200, Bastien ROUCARIES wrote:
> > On Fri, Jul 31, 2015 at 11:04 AM, Bastien ROUCARIES wrote:
> > > Lintian now detect script creating user pointing to /home.
>
> > After a chat under #debian-qa it
Am 18.09.2017 um 02:18 schrieb Michael Biebl:
> It's not as simple as that. You might still have running processes with
> that uid in which case usermod complains and exists.
> So to successfully run usermod you'd have to kill a processes running
> under that uid.
Fwiw, I ra
Am 15.09.18 um 20:31 schrieb Russ Allbery:
> Adding Colin as base-passwd maintainer.
>
> Sean Whitton writes:
>> On Fri 10 Aug 2018 at 08:23AM +0200, Michael Biebl wrote:
>
>>> Currently, DynamicUser gets a uid from within the following range:
>>> 61184 - 6
Lennart, Zbyszek,
what's your take on this?
For some more background, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905817
and the recent discussion at
https://lists.debian.org/debian-policy/2020/01/msg00013.html
Thanks,
Michael
Am 14.01.20 um 11:13 schrieb Philipp Kern:
> On 2020-01-0
[..]
Thanks for bringing that up, Simon.
I share your concern and agree with your conclusion.
As an example, I explicitly decided to keep the name
NetworkManager.service in the network-manager package.
I did create an alias/symlink network-manager.service and ship that in
the package, to shadow/m
Am 21.03.2011 10:56, schrieb Michael Biebl:
> Am 21.03.2011 08:07, schrieb Ralf Treinen:
>
>> Here is a list of files that are known to be shared by both packages
>> (according to the Contents file for sid/amd64, which may be
>> slightly out of sync):
>>
>> /
Hi Steve!
Am 21.03.2011 18:58, schrieb Steve Langasek:
> On Mon, Mar 21, 2011 at 11:30:06AM +0100, Michael Biebl wrote:
>
> Right, in the policy proposal I am describing that each init script is
> responsible for checking this. But the actual *implementation* of this
> check can
Hi!
> + replacement for /var/run, and its
> + subdirectory /run/lock is a replacement for
> + /var/lock. These changes have been
> + adopted by most distributions and have been proposed
> + for inclusion in a fut
Am 05.04.2011 20:13, schrieb Bill Allombert:
> I suggest to wait until /run exists in unstable systems, but not until
> packages are
> using it. This allows developers to notice the change and maybe comment on
> the patch.
http://packages.qa.debian.org/b/base-files/news/20110405T161708Z.html
--
Am 08.06.2011 23:22, schrieb Bill Allombert:
> On Sun, May 29, 2011 at 12:25:18AM +0100, Roger Leigh wrote:
>> Hi,
>>
>> I have attached the full patch against current policy.git. This is
>> identical to the previous patches, with the addition of a single
>> sentence to the footnote:
>>
>> "Additi
On 16.03.2012 20:09, Adam D. Barratt wrote:
> On Sun, 2012-02-26 at 17:01 -0800, Steve Langasek wrote:
>> On Sun, Feb 26, 2012 at 04:00:11PM -0800, Russ Allbery wrote:
>>> Oh, yes, I misunderstood that too. How about:
>>
>>> These maintainer scripts must not call the upstart
>>> st
On 16.03.2012 21:18, Steve Langasek wrote:
> On Fri, Mar 16, 2012 at 08:53:15PM +0100, Michael Biebl wrote:
>
>> As I've already mentioned before, I don't like the approach, that any
>> init script should use something like:
>
>>> if [ "$1" = sta
On 16.03.2012 21:25, Michael Biebl wrote:
> Personally, I would just prefer, if the shell library would forward the
> action requests to the native init system.
I still like this part of the original upstart-job idea (Steve knows the
details), simply because admins are used to the
/etc/
On 16.03.2012 21:18, Steve Langasek wrote:
>> What happens in maintainers scripts that call invoke-rc.d service start?
>> Will they now suddenly all fail? How will invoke-rc.d behave when the
>> package both installs a upstart job and sysv init script?
>
> Doesn't this language already cover that
On 16.03.2012 22:08, Steve Langasek wrote:
> On Fri, Mar 16, 2012 at 01:07:08PM -0700, Russ Allbery wrote:
>> If upstart and systemd can agree on the same invocation semantics for the
>> shell library, we could even provide a shell library that handled both and
>> make this more generic.
>
> I th
On 16.03.2012 22:08, Steve Langasek wrote:
> It also rubs me the wrong way to have the shell library exiting directly
> from the init script. I'd really prefer an interface such as
> init_is_upstart() which leaves it open for the init script to handle some of
> the mentioned corner cases - in par
On 16.03.2012 22:05, Michael Biebl wrote:
> If invoke-rc.d intercepts and redirects the request to upstart (or
> systemd), should update-rc.d do the same?
>
> Say you run "update-rc.d disable", should this disable only
> the sysv init script, both, or only the upst
On 16.03.2012 22:28, Steve Langasek wrote:
> On Fri, Mar 16, 2012 at 09:25:17PM +0100, Michael Biebl wrote:
>>> Well, it would be inappropriate to refuse to stop the service because
>>> upstart was running. The more likely outcome is that the init script
>>> will n
On 16.03.2012 23:12, Steve Langasek wrote:
> On Fri, Mar 16, 2012 at 10:57:20PM +0100, Michael Biebl wrote:
>>>> Personally, I would just prefer, if the shell library would forward the
>>>> action requests to the native init system.
>
>>> But this falls dow
On 10.04.2012 01:07, Steve Langasek wrote:
I'm wondering if this couldn't be handled in invoke-rc.d though.
If upstart is running, and there is a native upstart job, which is not
running though, invoke-rc.d could just call /etc/init.d/foo stop
>
In postinst, when you run invoke
Hi Russ, hi Sune,
I'd like to second this request to reword the current section in the
policy regarding menu files, suggesting fdo .desktop files as the
recommended mechanism and make it clear that .menu files are only really
relevant for legacy or more exotic window managers.
Sune's patch looks f
On Mon, Mar 10, 2014 at 06:39:20PM -0400, Joey Hess wrote:
>The FHS requirement that architecture-independent application-specific
>static files be located in /usr/share is relaxed to a suggestion.
>
>In particular, a subdirectory of /usr/lib may be used by a package
>(or a collect
On Mon, Mar 10, 2014 at 06:39:20PM -0400, Joey Hess wrote:
> So, I propse adding to the list of exceptions in policy section 9.1.1:
>
>The FHS requirement that architecture-independent application-specific
>static files be located in /usr/share is relaxed to a suggestion.
>
>In partic
Am 20.03.2014 23:58, schrieb Bill Allombert:
> On Mon, Mar 17, 2014 at 12:39:17AM +0100, Michael Biebl wrote:
>> On Mon, Mar 10, 2014 at 06:39:20PM -0400, Joey Hess wrote:
>>> So, I propse adding to the list of exceptions in policy section 9.1.1:
>>>
>>>T
Am 25.03.2014 18:56, schrieb Michael Biebl:
> Am 20.03.2014 23:58, schrieb Bill Allombert:
>> On Mon, Mar 17, 2014 at 12:39:17AM +0100, Michael Biebl wrote:
>>> On Mon, Mar 10, 2014 at 06:39:20PM -0400, Joey Hess wrote:
>>>> So, I propse adding to the list of exce
Am 15.08.2014 17:47, schrieb Gerrit Pape:
> Package: rsyslog
> Version: 8.2.2-3
> Severity: serious
> Justification: Policy 2.5
>
> Hi, the current rsyslog package version in testing is priority important
> and depends on packages with priority extra. Policy 2.5 states:
>
> "Packages must not de
Am 15.08.2014 18:10, schrieb Michael Biebl:
> Am 15.08.2014 17:47, schrieb Gerrit Pape:
>> Severity: serious
>> Justification: Policy 2.5
[..]
> That this rule is violated in hundreds of cases [1] clearly shows that
> there is something wrong which needs to be addressed in a
Am 12.11.2014 um 15:04 schrieb Andreas Henriksson:
> Hello Tim Wootton, release-team, et.al.!
>
> Thanks for your bug report.
>
> On Wed, Nov 12, 2014 at 11:00:16AM +, Tim Wootton wrote:
>> Package: bsdutils
>> Version: 1:2.25.2-2
>> Severity: serious
>> Justification: Policy 2.5
>>
>> Dear M
Am 12.11.2014 um 15:35 schrieb Bill Allombert:
> It is well settled that priority changes are done throught the distribution
> override file and not in the package control file and thus, an error of
> priority is not a RC bug in the package.
And that. Adjusting library package priorities is useles
On Fri, 21 Jun 2024 20:27:56 +0200 Helmut Grohne wrote:
Package: debian-policy
Version: 4.7.0.0
X-Debbugs-Cc: bl...@debian.org,m...@debian.org,mbi...@debian.org,z...@debian.org
Hi,
given the progress we have made with /usr-move and DEP17, I think it is
time to consider encoding the changes int
Hi Sean, hi everyone!
Am 25.02.25 um 13:43 schrieb Chris Hofstaedtler:
Nevertheless I think the generic text is a good idea. After all,
what good is having programs with the same name in /usr/bin and
/usr/games.
For completeness sake I want to mention that we discussed this issue on
#debian-
33 matches
Mail list logo
