Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

[Wouter Verhelst]

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, accepts outgoing and accepts related,establised is so easy to
> > do... and it would help for all those cases where services are started
> > but not yet finally configured/secured by the admin.
> 
> Are all of our users admins that grasp firewalls?

Most likely not, and therefore I agree that with the current state of
affairs, enabling a firewall on Debian by default is probably a bad idea.

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 to use and understand for the most
novice of users, I would absolutely agree that enabling a firewall with
this tool on default installations is desirable.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141102112921.ge16...@grep.be

Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

[Ralf Jung]

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
>>> but not yet finally configured/secured by the admin.
>>
>> Are all of our users admins that grasp firewalls?
> 
> Most likely not, and therefore I agree that with the current state of
> affairs, enabling a firewall on Debian by default is probably a bad idea.

One could also interpret this the other way - since many people don't
know how to manually configure a firewall, there should be something
there per default that protects them.

> 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 to use and understand for the most
> novice of users, I would absolutely agree that enabling a firewall with
> this tool on default installations is desirable.

There's firewalld that integrates into NetworkManager - at last for
Desktops using the latter (KDE, Gnome, Xfce, probably more) that may be
a sensible choice. I didn't have a closer look at it yet, though.

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54561762.1060...@ralfj.de

Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

[Vincent Bernat]

 ❦  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 to use and understand for the most
>> novice of users, I would absolutely agree that enabling a firewall with
>> this tool on default installations is desirable.
>
> There's firewalld that integrates into NetworkManager - at last for
> Desktops using the latter (KDE, Gnome, Xfce, probably more) that may be
> a sensible choice. I didn't have a closer look at it yet, though.

I am using it. It is nice since you can associate profiles with
network. When you are at home, the firewall profile is more permissive,
allowing stuff like mDNS.
-- 
 /*
  * Hash table gook..
  */
2.4.0-test2 /usr/src/linux/fs/buffer.c


signature.asc
Description: PGP signature

Arch-dependent files in /usr/share

[Jakub Wilk]

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 your packages. :-)

--
Jakub Wilk
Adrian-Ken Rueegsegger 
   libapq-postgresql4-dev

Albin Tonnerre 
   e17 (U)

Andreas Henriksson 
   gconf-defaults-service (U)
   gconf-service (U)

Andreas Metzler 
   autogen

Andreas Tille 
   anfo (U)
   libvxl1-dev (U)

Andrew Ross 
   plplot-tcl

Anibal Monsalve Salazar 
   heartbeat (U)

Anton Gladky 
   gerris-mpi (U)
   libcoin80-dev (U)
   libsimage-dev (U)
   libsoqt4-dev (U)

Antonin Kral 
   aranym

Arno Töll 
   apache2-dev (U)

Arthur Loiret 
   gawk

Axel Beckert 
   wml (U)

Bastien Roucariès 
   imagemagick-6.q16 (U)

Changwoo Ryu 
   ibus-hangul (U)

Chow Loong Jin 
   banshee-meego (U)

Christophe Prud'homme 
   libdolfin-dev (U)
   ufc (U)

Cyril Brulebois 
   xserver-xorg-dev (U)

Cédric Boutillier 
   libqtruby4shared-dev (U)

Daniel Baumann 
   lxc

Daniel Kobras 
   imagemagick-6.q16 (U)

David Palacio 
   libqtruby4shared-dev (U)
   libsmokeqt4-dev (U)

Debian Accessibility Team 
   brltty

Debian Apache Maintainers 
   apache2-dev
   libapr1-dev

Debian Cinnamon Team 
   cinnamon
   cinnamon-settings-daemon

Debian CLI Applications Team 
   banshee-meego

Debian FreeIPA Team 
   certmonger

Debian Games Team 
   freeorion
   funguloids

Debian Gauche Maintainers 
   gauche
   gauche-gl

Debian GCC Maintainers 
   libgnatprj4.9-dev

Debian GNOME Maintainers 
   gconf-defaults-service (U)
   gconf-service (U)
   gedit-plugins

Debian GNUstep maintainers 
   gnustep-common
   libgnustep-base-dev

Debian HA Maintainers 
   heartbeat

Debian Krap Maintainers 
   libqzeitgeist-dev
   virtuoso-opensource-6.1

Debian Med Packaging Team 
   anfo
   libvxl1-dev

Debian OCaml Maintainers 
   frama-c-base

Debian Perl Group 
   libxml-parser-perl

Debian Pkg-e Team 
   e17

Debian Printing Group 
   foomatic-db-engine

Debian Qt/KDE Maintainers 
   kdelibs5-dev
   libqca2-dev
   libqtruby4shared-dev
   libsmokeqt4-dev
   qt4-qmake
   qtmobility-dev

Debian Science Maintainers 
   gerris-mpi
   libdiet-dagda2.8-dev
   libsoqt4-dev

Debian Science Team 
   libcoin80-dev
   libdolfin-dev
   libsimage-dev
   ufc

Debian SSSD Team 
   sssd-dbus

Debian systemd Maintainers 
   systemd

Debian VoIP Team 
   libpt-dev

Debian WML Packaging Team 
   wml

Debian X Strike Force 
   xserver-xorg-dev

Debian Xfce Maintainers 
   libexo-helpers
   orage
   thunar
   tumbler
   xfce4-cellmodem-plugin
   xfce4-linelight-plugin
   xfce4-messenger-plugin
   xfce4-netload-plugin
   xfce4-notifyd
   xfce4-quicklauncher-plugin
   xfce4-radio-plugin
   xfce4-sensors-plugin
   xfce4-timer-plugin
   xfce4-verve-plugin
   xfce4-wmdock-plugin
   xfce4-xkb-plugin
   xfconf
   xfswitch-plugin

Debichem Team 
   gromacs-dev

Didier Raboud 
   foomatic-db-engine (U)

Dirk Eddelbuettel 
   r-base-core

Drew Parsons 
   gerris-mpi (U)
   xserver-xorg-dev (U)

Eugen Dedu 
   libpt-dev (U)

Evgeni Golov 
   xfce4-cellmodem-plugin (U)
   xfce4-notifyd (U)

Fabio Fantoni 
   cinnamon (U)
   cinnamon-settings-daemon (U)

Fathi Boudra 
   kdelibs5-dev (U)
   qt4-qmake (U)
   qtmobility-dev (U)

Felix Geyer 
   libqca2-dev (U)

Filippo Giunchedi 
   sensors-applet (U)

Francesco Paolo Lovergine 
   aolserver4-dev

Frederik Schüler 
   heartbeat (U)

George Kiagiadakis 
   kdelibs5-dev (U)

gregor herrmann 
   libxml-parser-perl (U)

Guido Günther 
   cups-pk-helper

Gürkan Sengün 
   gnustep-common (U)
   libgnustep-base-dev (U)

Hatta Shuzo 
   gauche (U)
   gauche-gl (U)

Haïkel Guémar 
   libdiet-dagda2.8-dev (U)

Henning Glawe 
   pdl

HIGUCHI Daisuke (VDR dai) 
   uim-applet-gnome

ImageMagick Packaging Team 
   imagemagick-6.q16

IME Packaging Team 
   ibus-hangul

Jan Lübbe 
   e17 (U)

Jan Niehusmann 
   libqca2-dev (U)

Jens Thiele 
   gauche (U)
   gauche-gl (U)

Jeroen Schot 
   gawk (U)

Johannes Ring 
   libdolfin-dev (U)
   ufc (U)

John Paul Adrian Glaubitz 
   mate-gnome-main-menu-applet (U)
   mate-netbook (U)
   mate-notification-daemon (U)
   mate-panel (U)
   mate-power-manager (U)

Jordi Mallach 
   gconf-defaults-service (U)
   gconf-service (U)
   mailutils-guile

Josselin Mouette 
   gconf-defaults-service
   gconf-service
   gedit-plugins (U)

Keng-Yu Lin 
   urfkill

Kilian Krause 
   libpt-dev (U)

Kiwamu Okabe 
   uim-applet-gnome (U)

Laszlo Boszormenyi (GCS) 
   cinnamon (U)

Laurent Bigonville 
   gedit-plugins (U)
   plymouth

LI Daobing 
   ibus-hangul (U)

Lionel Le Folgoc 
   libexo-helpers (U)
   orage (U)
   thunar (U)
   tumbler (U)
   xfce4-cellmodem-plugin (U)
   xfce4-linelight-plugin (U)
   xfce4-messenger-plugin (U)
   xfce4-netload-plugin (U)
   xfce4-notifyd (U)
   xfce4-quicklauncher-plugin (U)
   xfce4-radio-plugin (U)
   xfce4-sensors-plugin (U)
   xfce

Re: Arch-dependent files in /usr/share

[Steve Langasek]

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.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 by
architecture because it encodes a reference to the binary daemon, which is
shipped in a multiarch path.

Since the package is not Multi-Arch: same anyway[1], and there will therefore
only ever be one of these daemons on the system at a time, so we could ship
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
treat these with a high priority?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

[1] and obviously couldn't be with differing /usr/share contents


signature.asc
Description: Digital signature

Re: Arch-dependent files in /usr/share

[Andreas Barth]

* 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
> 
> 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 by
> architecture because it encodes a reference to the binary daemon, which is
> shipped in a multiarch path.

In this case I tend to say that the bug is in dbus because we should
be able to have the possibility to have per-arch services files. And
after that is fixed, systemd-shim should be adapted of course.

(I however also don't think that this is pretty bad, but of course it
is a FHS violation, and should be fixed.)



Andi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141102184210.gy20...@mails.so.argh.org

Re: Arch-dependent files in /usr/share

[Josselin Mouette]

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 by
> architecture because it encodes a reference to the binary daemon, which is
> shipped in a multiarch path.

The same holds for gconf-service and gconf-defaults-service. The path to
the binary is a MultiArch one, but the package is MA: foreign precisely
for this reason. 

We could move the binary to /usr/lib/gconf instead
of /usr/lib/$triplet/gconf, but is there really a point?

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1414956762.28884.2.ca...@kagura.malsain.org

Re: Arch-dependent files in /usr/share

[Thorsten Glaser]

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 architectures via NFS.

bye,
//mirabilos
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1411022059450.27...@tglase.lan.tarent.de

Re: Arch-dependent files in /usr/share

[Marco d'Itri]

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

Re: Arch-dependent files in /usr/share

[Sune Vuorela]

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/lib/dbus-1/system-services).  The file varies by
>> architecture because it encodes a reference to the binary daemon, which is
>> shipped in a multiarch path.
>
> The same holds for gconf-service and gconf-defaults-service. The path to
> the binary is a MultiArch one, but the package is MA: foreign precisely
> for this reason. 

And for various .desktop files


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 ?

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m36663$5uc$1...@ger.gmane.org

Re: Arch-dependent files in /usr/share

[Russ Allbery]

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're so space-constrained on a device that
you're doing this, you probably just mount all of /usr from the network,
and as soon as you have real storage, it's easy enough to just have one
full copy of /usr per architecture (and probably a lot safer and more
reliable).

Honestly, I think the /usr/share vs. /usr/lib distinction in the FHS may
have outlived its usefulness.  The only other thing that I know people do
with it is check /usr/lib in Tripwire but not check /usr/share, and I'm
not sure that makes any sense either.  It's tempting to just use /usr/lib
for everything and let /usr/share die, but the transition is hideous and a
ton of tedious work.  Meh.

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
could add a search path to D-Bus to check both /usr/share and /usr/lib,
and in a lot of ways that's the simplest fix, but if we could eventually
eliminate this distinction, it would remove a bunch of Lintian checking
and package machinery and moving stuff about that's of rather questionable
usefulness and mostly just wastes maintainer time.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/878ujt71mv@hope.eyrie.org

Re: Arch-dependent files in /usr/share

[Marco d'Itri]

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

Re: Arch-dependent files in /usr/share

[Russ Allbery]

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 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.  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.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/874muh71jl@hope.eyrie.org

Re: Arch-dependent files in /usr/share

[Simon McVittie]

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
utterly trivial) fixed in jessie.

> * Steve Langasek (vor...@debian.org) [141102 19:39]:
>> This is /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service
> 
> In this case I tend to say that the bug is in dbus because we should
> be able to have the possibility to have per-arch services files. And
> after that is fixed, systemd-shim should be adapted of course.

The obvious question with per-architecture is, whose architecture? On a
general multi-arch system, the architecture of /usr/bin/dbus-daemon
(from dbus_*.deb, Multi-Arch: Foreign) is essentially arbitrary.

I would not be keen on searching
[/usr]/lib/MULTIARCH-TUPLE/dbus-1/..., because it doesn't seem to be a
great idea to treat one architecture specially (namely the one for which
dbus-daemon happens to be installed). D-Bus system services are
basically analogous to executables in $PATH: they're looked up by an
author-chosen name (a D-Bus service name rather than the executable's
filename, but the principle is the same) in a search path with a
well-defined order.

D-Bus *session* services additionally have the historical mis-design
that two implementations of the same session service name don't
necessarily have either file conflicts or predictable ordering, because
the .service file's name is not required to match the service name. I've
contributed
https://lintian.debian.org/tags/dbus-session-service-wrong-name.html in
an attempt to reduce/avoid that post-jessie.

My recommendation would be for packages to install their D-Bus services'
executables in ${libexecdir} (or ${sbindir} or ${bindir}) rather than
${libdir}, as the GNU coding standards would already suggest. That's
what Telepathy has always done, for instance. Happily, for
D-Bus-activated services that are not already in $PATH, the precise
location of the executable is an implementation detail, so moving the
executable shouldn't break anything.

Alternatively, here's a structure that would already work:

/usr/share/dbus-1/system-services/com.example.Foo.service:
symlink to /usr/lib/dbus-1/system-services/com.example.Foo.service

/usr/lib/dbus-1/system-services/com.example.Foo.service:
real file, contains multi-arch path in Exec line

Alternatively^2, I'd consider a patch (preferably upstream) to insert
/usr/lib/dbus-1/system-services into dbus' search path for system
services, as long as it doesn't interfere with
/lib/dbus-1/system-services, which is already searched (/lib in its role
as the rootfs' equivalent of /usr/share). Anything using that path would
need a versioned dependency on a suitable dbus to order upgrades
correctly, making this undesirable for jessie at this point, IMO.

Josselin Mouette wrote:
> The same holds for gconf-service and gconf-defaults-service. The path
> to the binary is a MultiArch one, but the package is MA: foreign
> precisely for this reason.

I'd say the real reason for it to be MA: foreign is "you cannot usefully
have more than one copy of gconf-service installed, and regardless of
which one you have, all architectures can use it". Only one executable
at a time, and preferably a predictably-chosen one, can provide the
org.gnome.GConf service (any other executable trying to provide the same
service name is just a waste of disk space); it doesn't really matter
which architecture it is, because D-Bus is an architecture-independent
protocol when used correctly.

Thorsten Glaser wrote:
> Low-priority sounds about right, but there’s still the supposed
> case of /usr/share sharing across architectures via NFS.

I agree ... but does anyone actually do that in any case? The conditions
for it to be valid to share /usr/share are really quite narrow (you have
to have the same packages on every architecture, at the same versions,
and upgrade all architectures in lockstep) and I'm having a hard time
seeing how this situation could be set up without either having a
complete chroot per architecture on the NFS server (in which case you
might as well just serve up those chroots separately), or throwing a lot
of dpkg --force at the installation/upgrade steps.

(Also, the days of packaged software (/usr and friends) being larger
than user data (/home, /srv) seem to have passed, and it's entirely
possible to deduplicate multiple architectures' /usr/share directories
with hard links or even btrfs reflinks.)

Regards,
S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5456a02f.4040...@debian.org

Re: Arch-dependent files in /usr/share

[Rene Engelhard]

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 LibreOffice packaging doing exactly this.

(Admittedly not all, and that "rest" is would be the most painful one.)

Regards,

Rene


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141102230734.gc18...@rene-engelhard.de

Re: Arch-dependent files in /usr/share

[Russ Allbery]

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 have various hacks in LibreOffice packaging doing exactly this.

> (Admittedly not all, and that "rest" is would be the most painful one.)

Ah, I'd only noticed the remaining ones and hadn't realized all the work
you were already doing.  Sorry about that!

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, although please do correct me if I'm wrong about that.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87mw895hbj@hope.eyrie.org

Re: Arch-dependent files in /usr/share

[Rene Engelhard]

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, although please do correct me if I'm wrong about that.

Indeed, you are right.

Even the existing ones gave headaches at times (especially the icons/images_*
which broke not that long ago when being in /usr/share (well, actually being
symlinks...).

Regards,

Rene


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141102231815.gd18...@rene-engelhard.de

Re: Arch-dependent files in /usr/share

[Jakub Wilk]

* 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/x86_64-linux-gnu/movemail 2755 root/mail

you can write

emacs24-bin-common binary: setgid-binary usr/lib/emacs/24.4/*/movemail 2755 
root/mail

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141102233610.ga9...@jwilk.net

RE: Arch-dependent files in /usr/share

[Saqman2060]

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 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 your packages. :-)

-- 
Jakub Wilk

Re: Arch-dependent files in /usr/share

[Christian Hofstaedtler]

* 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 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.

I agree. The various interpreters already ship most of their
standard library files in /usr/lib. I'd also want to point out that
additional search paths in /usr/share would add significant
runtime overhead.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141103013236.ga19...@nq.home.zeha.at

Re: Arch-dependent files in /usr/share

[Josh Triplett]

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 Policy 3.9.6.0, and lintian
should change to match.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141103023738.GA20359@thin

Re: Arch-dependent files in /usr/share

[Russ Allbery]

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 741304; that change occurred in Policy 3.9.6.0, and lintian
> should change to match.

Not quite.  That still requires moving whole directories to /usr/lib (at
normal severity level).  I'm saying that we should consider waiving this
section of the FHS completely and letting packagers use /usr/lib for
arch-independent files.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87lhnt3sel@hope.eyrie.org

Re: dgit and git-dpm

[Bernhard R. Link]

* 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 mandate).

And the debdiff is the real difference so the real changes done, so
worth looking at.

How is being quite sure what would be in there with dgit that much
different as with other NMUs? Where is the difference to
"I just applied those two patches from the BTS and changed
debian/rules the way described in debian/changelog.
Why should I look at the debdiff? I know I changed nothing else."?

Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141103061735.ga1...@client.brlink.eu

Bug#767874: RFH: ejabberd -- distributed, fault-tolerant Jabber/XMPP server written in Erlang

[Philipp Huebner]

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 order to 
help out.

If you're interested simply join the MUC and talk to us.

Regards,
Philipp


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141103065302.30287.21860.report...@emmagan.debalance.de