Package: wnpp
Severity: normal
I request assistance with maintaining the ejabberd package set.
It is team maintained via gitolite and a jabber MUC (Multi-User Chat) at
ejabb...@chat.deb.at and in constant need of working power.
You neither need to understand Erlang nor be a Debian Developer in or
* Ian Jackson [141030 13:42]:
> Thorsten Glaser writes ("Re: dgit and git-dpm"):
> > – I’d prefer users of even dgit, no matter how good it may be, to
> > not rely on that.
>
> Again, why ?
To do an NMU, one has to generate a debdiff anyway to post it to the
bug report (as the rules for NMUs mand
Josh Triplett writes:
> Russ Allbery wrote:
>> I think it's worth considering whether we should just dump the Lintian
>> checks for arch-independent files in /usr/lib, and make a corresponding
>> change to Policy that says that packages are free to put
>> arch-independent files there.
> See bug
Russ Allbery wrote:
> I think it's worth considering whether we should just dump the Lintian
> checks for arch-independent files in /usr/lib, and make a corresponding
> change to Policy that says that packages are free to put
> arch-independent files there.
See bug 741304; that change occurred in
* Russ Allbery [141102 22:12]:
> Sune Vuorela writes:
>
> > All the cmake files in the list, on the other hand, should be shippable
> > in /usr/lib/
>
> > I'm not sure about all the lintian overrides in there. Maybe a fix needs
> > to be applied in lintian for arch specific overrides ?
>
> I t
Good catch.
-Original Message-
From: "Jakub Wilk"
Sent: 11/2/2014 12:33 PM
To: "debian-devel@lists.debian.org"
Subject: Arch-dependent files in /usr/share
I found a number of arch!=all packages shipping /usr/share files that
vary with architecture in a way indicating an FHS violatio
* Sune Vuorela , 2014-11-02, 21:02:
I'm not sure about all the lintian overrides in there. Maybe a fix
needs to be applied in lintian for arch specific overrides ?
You can use wildcards in Lintian overrides. For example, instead of
emacs24-bin-common binary: setgid-binary
usr/lib/emacs/24.4/x
Hi,
On Sun, Nov 02, 2014 at 03:11:12PM -0800, Russ Allbery wrote:
> But the broader point is that if we stopped requiring this distinction,
> you could unwind those hacks as well. My guess is that would make
> maintaining the packages easier and would be preferrable from your
> perspective, altho
Rene Engelhard writes:
> On Sun, Nov 02, 2014 at 01:09:02PM -0800, Russ Allbery wrote:
>> files there. No one is ever going to bother to move the files in, say,
q>> LibreOffice into /usr/share, since the theoretical gain totally isn't
>> worth the effort in maintaining the package.
> Actually I
Hi,
On Sun, Nov 02, 2014 at 01:09:02PM -0800, Russ Allbery wrote:
> files there. No one is ever going to bother to move the files in, say,
> LibreOffice into /usr/share, since the theoretical gain totally isn't
> worth the effort in maintaining the package.
Actually I have various hacks in Libre
On 02/11/14 18:42, Andreas Barth wrote:
> (I however also don't think that this is pretty bad, but of course it
> is a FHS violation, and should be fixed.)
For Multi-Arch: foreign or non-Multi-Arch packages, I don't personally
think this should be considered priority > normal, or (unless it's
utte
Sune Vuorela writes:
> All the cmake files in the list, on the other hand, should be shippable
> in /usr/lib/
> I'm not sure about all the lintian overrides in there. Maybe a fix needs
> to be applied in lintian for arch specific overrides ?
I think it's worth considering whether we should just
On Nov 02, Russ Allbery wrote:
> So... we shouldn't gratuitously break the distinction, but it does make me
> question how much effort we should put into fixing issues like this. We
Agreed.
--
ciao,
Marco
signature.asc
Description: Digital signature
m...@linux.it (Marco d'Itri) writes:
> On Nov 02, Thorsten Glaser wrote:
>> Low-priority sounds about right, but there’s still the supposed
>> case of /usr/share sharing across architectures via NFS.
> So much hypothetical that I am quite sure that nobody does this.
Yeah, at the point where you
On 2014-11-02, Josselin Mouette wrote:
> Le dimanche 02 novembre 2014 à 10:33 -0800, Steve Langasek a écrit :
>> This is /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service,
>> which is the sole location for declaring services to dbus (i.e., there is no
>> corresponding path /usr/li
On Nov 02, Thorsten Glaser wrote:
> Low-priority sounds about right, but there’s still the supposed
> case of /usr/share sharing across architectures via NFS.
So much hypothetical that I am quite sure that nobody does this.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Sun, 2 Nov 2014, Steve Langasek wrote:
> it in /usr/lib instead of /usr/lib/$arch. But this also seems like a
> low-priority FHS issue to me. Is there a practical reason that we should
Low-priority sounds about right, but there’s still the supposed
case of /usr/share sharing across architect
Le dimanche 02 novembre 2014 à 10:33 -0800, Steve Langasek a écrit :
> This is /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service,
> which is the sole location for declaring services to dbus (i.e., there is no
> corresponding path /usr/lib/dbus-1/system-services). The file varies b
* Steve Langasek (vor...@debian.org) [141102 19:39]:
> On Sun, Nov 02, 2014 at 06:33:15PM +0100, Jakub Wilk wrote:
> > I found a number of arch!=all packages shipping /usr/share files that vary
> > with architecture in a way indicating an FHS violation.
>
> > Steve Langasek
> >systemd-shim
>
On Sun, Nov 02, 2014 at 06:33:15PM +0100, Jakub Wilk wrote:
> I found a number of arch!=all packages shipping /usr/share files that vary
> with architecture in a way indicating an FHS violation.
> Steve Langasek
>systemd-shim
This is /usr/share/dbus-1/system-services/org.freedesktop.systemd1
I found a number of arch!=all packages shipping /usr/share files that
vary with architecture in a way indicating an FHS violation.
DD-list of the affect binary packages is attached, and diff between i386
and s390x is here:
https://people.debian.org/~jwilk/qa/20141101-usr-share.diff
Please fix
❦ 2 novembre 2014 12:37 +0100, Ralf Jung :
>> However, it should be possible to create a tool which helps novice users
>> in managing their firewall, and such a tool could be installed by
>> default on at least a Desktop installation. If we go down that route,
>> and if said tool is easy enough
Hi,
>>> - Debian should ship a default set of firewall rules. Are we the only
>>> distro which doesn't do this? I mean a basic ruleset which drops
>>> incoming, accepts outgoing and accepts related,establised is so easy to
>>> do... and it would help for all those cases where services are started
On Sat, Nov 01, 2014 at 07:46:42PM +0100, Philipp Kern wrote:
> On Thu, Oct 30, 2014 at 05:52:07PM +0100, Christoph Anton Mitterer wrote:
> > - Debian should ship a default set of firewall rules. Are we the only
> > distro which doesn't do this? I mean a basic ruleset which drops
> > incoming, acce
24 matches
Mail list logo
