On Thu, Jun 28, 2018 at 8:56 AM, Sean Whitton wrote:
>> Packages must not contain files in /home, and packages' maintainer
>> scripts must not write to users' home directories. The programs in
>> those packages may create directory hierarchies as described in
>> §3.8.3 "Home Directo
On Thu, Jul 30, 2015 at 5:46 PM, James Montgomery wrote:
> wine-mono, I've logged all the dependencies required, meticulously,
> and would now like ask you how Debian deals with such build systems
> where the build comes from the wine-mono script.
>
> As you're aware, wine-mono has the custom build
On Sat, Jul 25, 2015 at 6:10 PM, James Montgomery wrote:
> As a wine-development user myself who has never done an official
> backport I wouldn't mind trying my hand at backporting. Is the wiki
> for BuildingFormalBackports[0] the best place to start? Also, if this
> is too big a beast to cut my te
x-debbugs-cc: debian-w...@lists.debian.org,
debian-backpo...@lists.debian.org, 793...@bugs.debian.org
Hi,
Resent to correctly include the CC's above.
I received a bug against wine today, which boils down to a request for
regular backporting of the package to stable:
http://bugs.debian.org/793551
package: developers-reference
severity: wishlist
x-debbugs-cc: debian-backpo...@lists.debian.org
x-debbugs-cc: debian-w...@lists.debian.org
x-debbugs-cc: 793...@bugs.debian.org
x-debbugs-cc: 793551-submit...@bugs.debian.org
Hi,
I received a bug against wine today, which boils down to a request fo
On Mon, Nov 12, 2012 at 3:50 AM, Jonathan Nieder wrote:
> Michael Gilbert wrote:
>> I wonder if the part about +nmuN as an
>> optional versioning for non-native packages could be re-added?
>
> It's still not needed or a noticeable existing
On Sun, Jan 8, 2012 at 12:17 PM, Russ Allbery wrote:
> In the long run, what we want is something that satisfies:
>
> package < binNMU < stable/security update < NMU < maintainer upload
>
> with all stable/security updates sorting in Debian release order.
>
> The current convention of .1 satisf
On Mon, Jul 16, 2012 at 9:37 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> Interesting condition. According to Developers Reference 5.9.4,
>> orphaning is a process that is only supposed to be initiated by the
>> existing maintainer.
>
> Orphaning is also
As a reminder to myself if these changes were to gain traction,
section 5.9.5 (adopting a package) will also need some rewriting since
certain instructions overlap salvaging.
Best wishes,
Mike
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Tr
On Mon, Jul 16, 2012 at 6:55 PM, Jakub Wilk wrote:
> * Michael Gilbert, 2012-07-16, 18:35:
>
>> +
>> +If a package has been already been orphaned, you may salvage it without
>> any
>> +kind of approval.
>> +
>> +
>> +
>> +Filing a removal
package: developers-reference
severity: normal
version: 3.4.8
tag: patch
Hi,
I've prepared an initial draft of a developers reference patch that
would document a package salvaging process. Please see below.
Best wishes,
Mike
--- pkgs.dbk.orig 2012-07-16 18:19:56.065047490 -0400
+++ pkgs.
On Tue, Apr 24, 2012 at 2:22 PM, Chris Knadle wrote:
> I already proposed to write a bug report against the developers-refernece
> package in the email prior to the one you're replying to. [1]
>
> [1] http://lists.debian.org/debian-policy/2012/04/msg00046.html
Then do it!
Best wishes,
Mike
--
On Tue, Apr 24, 2012 at 12:45 PM, Chris Knadle wrote:
>> > Try to read between the lines -- it implies "be reluctant to do an NMU
>> > unless you're absolutely sure of what you're doing". That's a much
>> > higher bar than the spirit that I think is embodied in Zack's email
>> > describing NMUs.
>
On Wed, Mar 14, 2012 at 5:18 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>> On Wed, Mar 14, 2012 at 1:43 AM, Russ Allbery wrote:
>
>>> I think you're in the "rough" of "rough consensus."
>
>> It takes some moxie to put a dent into the st
On Wed, Mar 14, 2012 at 1:43 AM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> Opinions are malleable (wrong and right are all a matter of
>> perspective). This is something sufficiently nuanced that I think its
>> worth sufficient pondering to really get it righ
On Tue, Mar 13, 2012 at 11:27 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> I understand this section very well, and even with that lead-in wording,
>> I contend that sufficient ambiguity remains that additional clarity is
>> needed. Otherwise, it wouldn't h
On Tue, Mar 13, 2012 at 10:53 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> This is a bit off-topic for the bug report, but while you're thinking
>> about rewording this section, it may be prescient to consider
>> non-explicit dependencies.
>
>> For
On Thu, Jan 5, 2012 at 12:25 PM, Russ Allbery wrote:
> This is the bug concerning the wording in current Policy 2.2.1:
>
> In addition, the packages in main
>
> * must not require a package outside of main for compilation or
> execution (thus, the package must not declare a "Depends",
On Mon, Feb 20, 2012 at 2:22 AM, Wouter Verhelst wrote:
> Hi,
>
> During a recent discussion on debian-devel about multiarch, it was shown
> that gzip does not always produce the exact same output from a given
> input file.
>
> While it was shown that removing the requirement to compress
> document
On Tue, Oct 25, 2011 at 8:20 PM, Charles Plessy wrote:
>> I believe it should also document the N.N standard for
>> NMUs of non-native packages, since people don't seem inclined to change to
>> +nmu and there's probably no reason to do so.
I suppose this isn't a compelling argument, but it's just
> Ian Jackson wrote:
>> I don't know what azareus's UI for this is like but depending on the
>> situation it might be best to make a configuration option, set by
>> default, which suppresses it. For example, if the current
>> code presents dialogues nagging to be allowed to update from upstream,
On Jan 14, 1:10 pm, "Shaun Jackman" wrote:
> On a stable Debian system, system-wide upgrades can be far between. I
> prefer to give the user a choice of whether to use the update system
> provided by the upstream author to update the software before the next
> stable release of Debian.
like i said
hello,
is there a policy on whether an executable is permitted to update itself? i
personally believe that in order to maintain the security of the system, apt
and apt alone should be used to install software updates. recently i
submitted a bug on azureus about how it should not urge users to i
I took a stab at implementing the dbrief concept that I described
previously. This tool is useful for me, and I am providing it in the
hope that other users find it useful as well. please check out my
work at http://dbrief.sourceforge.net and provide feedback.
mike
> thank you for all of the in
thank you for all of the interesting comments.
what I am getting at is that there should be a simple way for the user
to discover what he or she just installed. "dpkg -L ",
which is a good start, gives you information about installed files,
but the command itself is not easily discoverable (i did
es as well. Some packages do not provide
binaries at all (gnome-core, documentation, etc.). And some have
different names than the primary binary because it is a particular
distribution of popular software (package tetex binary latex, etc.).
Thank you for your thoughts and consideration.
Regards,
Michael Gilbert
26 matches
Mail list logo
