Re: tarball in tarball: opinions
(some of the answers/facts have already been given, but I reply anyway to also give my personal opinion) On Sat, 05 Jul 2008, Jay Berkenbilt wrote: > * I like to have an exact copy of the downloaded source tarball with >the same md5 checksum, gpg detached signature, etc. Using the That should be the orig.tar.gz/bz2 file indeed. > * I manage my debian directories in subversion, and I use >svn-buildpackage to build. I always use "mergeWithUpstream". >Sometimes I want to do something more involved, so I just manually >extract my .orig.tar.gz files. >I can't do this without tarball in tarball if my packages either >contain their own debian directories that I don't use This is not a problem with the new source format. >or if they extract to a directory other than pkg-version. This has never been a problem, dpkg-source always handled this. If the orig tarball contains a single directory, it's renamed as pkg-version, if it contains multiple directories they are moved as-is inside a new pkg-version directory. > So, is using tarball in tarball considered "bad" these days? Is it > viewed as an approach that once had its time but is now discouraged, > or is it just a matter of personal preference and creating a > README.source that tells the user what to do file makes it all okay? I have always found tarball in tarball a big nuisance. They are rightfully justified _only_ when the source package is composed of multiple source packages (such as the glibc for example). But the new source format also support multiple upstream tarballs. For the other cases, they are often used to work around a messy upstream build system that is not able to clean the build directory properly. It would be far more productive to write a patch to fix the upstream build system and submit it rather than work around the deficiencies. > will be easier to handle after we can switch to 3.0 (quilt), but as > far as I know, there is no way to replace your .orig.tar.gz without > changing the package version, and I don't want to introduce epochs for > this. Creating a fake version "version.ds" or "version+ds" is often used for those cases (I believe "ds" stands for "debian specific" or something like that). Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#426877: dpkg: Option "--oknodo" should be the default behaviour for "start-stop-daemon" (LSB specs)
On Sat, 5 Jul 2008 12:13:27 +0200, Raphael Hertzog <[EMAIL PROTECTED]> wrote: >On Sat, 05 Jul 2008, Marc Haber wrote: >> On Sat, Jul 05, 2008 at 10:58:35AM +0200, Raphael Hertzog wrote: >> > THanks, I could come up with a transition plan myself if needed. But >> > compare your suggestions with: "someone goes over all init scripts, file >> > bugs and in lenny+1 we're done". >> >> That'll cause tremendous pain for backporters. I'm opposed. > >You're opposed to what? Reversing s-s-d's behavior from lenny to lenny+1. >I think you misunderstood. I don't want to change the default behaviour >of start-stop-daemon and as such, there's no need for any transition. I see... Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Strange file problem
Hello folks, i have some trouble about a strange file problem experienced after a filesystem [ReiserFS] crash. In the /var/run directory I have 3 files (sshd.pid, sudo, motd) that cannot be accessed in any way. I try to remove it but rm -f returns a "permission denied" message sshd doesn't work but sudo does. The Inode has value 0 in all cases. Have you got any ideas? -- .''`. Andrea Ferraresi <[EMAIL PROTECTED]> : :' : irc.FreeNode.net #lslug | JID [EMAIL PROTECTED] . `` Registered Linux user #388877 and Machine #289399 `- WebMaster http://www.lslug.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange file problem
* Andrea Ferraresi <[EMAIL PROTECTED]>: > Hello folks, > i have some trouble about a strange file problem experienced after > a filesystem [ReiserFS] crash. > In the /var/run directory I have 3 files (sshd.pid, sudo, motd) that cannot > be accessed in any way. I try to remove it but rm -f returns a > "permission denied" message > sshd doesn't work but sudo does. The Inode has value 0 in all cases. > Have you got any ideas? Have you tried a full filesystem check? Backup your data, such repair actions sometimes eat your data. -- Ralf Hildebrandt (i.A. des IT-Zentrums) [EMAIL PROTECTED] Charite - Universitätsmedizin BerlinTel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-BerlinFax. +49 (0)30-450 570-962 IT-Zentrum Standort CBF send no mail to [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#426877: Clarify what "sensible behaviour" is for init scripts
> Note that /etc/init.d/skeleton, on which many init scripts in Debian are
> based, handles this case correctly without using --oknodo.
Are you sure? These are the "start" and "stop" sections of skeleton
file in a Debian Etch:
-
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec
$DAEMON --test > /dev/null \
|| return 1
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
$DAEMON_ARGS \
|| return 2
# Add code here, if necessary, that waits for the process to be ready
# to handle requests from services started subsequently which depend
# on this one. As a last resort, sleep for some time.
}
#
# Function that stops the daemon/service
#
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5
--pidfile $PIDFILE --name $NAME
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
# Wait for children to finish too if this is a daemon that forks
# and if the daemon is only ever run from this initscript.
# If the above conditions are not satisfied then add some other code
# that waits for the process to drop all resources that could be
# needed by services started subsequently. A last resort is to
# sleep for some time.
start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5
--exec $DAEMON
[ "$?" = 2 ] && return 2
# Many daemons don't delete their pidfiles when they exit.
rm -f $PIDFILE
return "$RETVAL"
}
-
This is not the LSB behaviour. Athe --oknodo is just present in the
second call to "start-stop-daemon" of the "stop" action (and no more),
and the text is very clear:
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
2008/7/6, Russ Allbery <[EMAIL PROTECTED]>:
> "\"Iñaki" Baz Castillo" <[EMAIL PROTECTED]> writes:
>
>> Op, sorry, I meant that "lighttpd DOESN'T use LSB specs but Debian
>> specs".
>>
>> You say that "it's not a sensible behaviour to fail when asked to start
>> a service that is already running" but this is the default behaviour of
>> Debian init scripts (dince --oknodo is optional and of course not always
>> used).
>
> Note that /etc/init.d/skeleton, on which many init scripts in Debian are
> based, handles this case correctly without using --oknodo.
>
> --
> Russ Allbery ([EMAIL PROTECTED])
Re: Bug#426877: Clarify what "sensible behaviour" is for init scripts
On Sun, 06 Jul 2008, Iñaki Baz Castillo wrote: > > Note that /etc/init.d/skeleton, on which many init scripts in Debian are > > based, handles this case correctly without using --oknodo. > > Are you sure? These are the "start" and "stop" sections of skeleton > file in a Debian Etch: No those are functions... the main code runs without "set -e" and thus doesn't fail on the error and the return value of the function is checked: do_start case "$?" in 0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;; 2) [ "$VERBOSE" != no ] && log_end_msg 1 ;; esac If do_start returns 0 or 1, the whole script returns "0" (hence success). Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489507: ITP: icu4j -- unicode and globalization library
Package: wnpp Severity: wishlist Owner: Michael Koch <[EMAIL PROTECTED]> * Package name: icu4j Version : 3.8.1 Upstream Author : IBM Corp. and ICU Team * URL : http://icu-project.org/ * License : ICU License Programming Lang: Java Description : unicode and globalization library ICU is a mature, widely used set of C/C++ and Java libraries providing Unicode and Globalization support for software applications. ICU is widely portable and gives applications the same results on all platforms and between C/C++ and Java software. . ICU4J is Java version of ICU library. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnome, kde, xfce use non-policy main menu
Le samedi 05 juillet 2008 à 02:42 -0400, Daniel Dickinson a écrit : > Gnome, KDE, and XFCE are the the top three desktops used in debian and > cover most users of desktops in debian. > > They all use xdg .desktop-based menus as their main menu. The last time this discussion was raised up, the clear consensus was that, at least for the GNOME menu, the primary goals of the xdg-based menu system and those of the Debian menu are fundamentally different. The GNOME menu is aimed towards usability, and the Debian menu is aimed towards completeness. Given the capabilities of the GNOME panel (for which adding submenus is neither easy nor efficient in terms of usability), the limitations of the XDG system (for which it is not possible to define “views” including or excluding some categories) and the restrictions of the Debian menu system (no i18n support, 32x32 XPM icons, strict hierarchy), these goals are simply not compatible. Therefore, I still feel that, despite it being a big mess, the current situation is the best: * the default menu contains only what is needed, and we are still hunting down entries that are useless to make them not show up by default; * users wanting the Debian menu and its gazillions of entries including window managers, terminal emulators and shell interpreters can enable it easily in the menu editor; * those really wanting only the Debian menu can replace gnome-applications.menu by debian-menu.menu. If you want this to change, you need to seriously think about evolutions to both XDG and Debian menu systems, to convince fd.o and the Debian menu maintainer to implement them, and to find a good way to present them in a nice way in the main menu and in a menu editor. None of these tasks are simple. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bug#426877: Clarify what "sensible behaviour" is for init scripts
2008/7/6 Raphael Hertzog <[EMAIL PROTECTED]>: > No those are functions... the main code runs without "set -e" and thus doesn't > fail on the error and the return value of the function is checked: > >do_start >case "$?" in >0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;; >2) [ "$VERBOSE" != no ] && log_end_msg 1 ;; >esac > > > If do_start returns 0 or 1, the whole script returns "0" (hence success). Thanks for pointing that, you are right. Anyway I consider it a bit complex and the fact is that various Debian init scripts return 1 in the above case. Thanks for all. -- Iñaki Baz Castillo <[EMAIL PROTECTED]>
Re: gnome, kde, xfce use non-policy main menu
On Sun, 06 Jul 2008 14:28:15 +0200, Josselin Mouette <[EMAIL PROTECTED]> wrote: Therefore, I still feel that, despite it being a big mess, the current situation is the best: * the default menu contains only what is needed, and we are still hunting down entries that are useless to make them not show up by default; * users wanting the Debian menu and its gazillions of entries including window managers, terminal emulators and shell interpreters can enable it easily in the menu editor; As being a simple user I like having both. Regards, Tilo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tarball in tarball: opinions
Thanks for all the input on tarball within tarball. I will stop using that format for all my packages with the possible exception of ICU which contains its own debian directory. I was aware of the fact that dpkg-source handles the tarball nnot extracting to package-version and have, in fact, advised others that repackaging the orig.tar.gz to get around this is not necessary. One of my own packages (psutils) is this way. My point wasn't that dpkg-source doesn't handle it, but that it makes it somewhat less convenient to manually extract the source over top of my svn-controlled debian directories. I was not aware of svn-buildpackage --svn-export, pointed out by Magnus Holmgren <[EMAIL PROTECTED]>, and I think that will solve my problem quite nicely and prevent me from writing my own script that duplicates the logic in dpkg-source. With regard to the ICU packages, which include their own debian directory, I tried unsuccessfully two years ago to convince upstream to drop this. There has been a recent change of leadership in the project, and I have (prior to my sending out my message to debian-devel), post a bug to their bug tracking system requesting that they drop the debian directory. If they don't, I may regenerate the orig.tar.gz as I do not, but instead of using a tarball within a tarball, I'll just push everything down one level. Once the 3.0 (quilt) format becomes acceptable to use for regular packages in the archive, this becomes a non-issue, and I can use the upstream source download as the .orig.tar.gz file. Thanks for all the input and tips. -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Idea for improved diversions and alternatives handling
Goswin von Brederlow wrote: > working on dpkg reminded me that I wanted to propose a better > diversion and alternatives handling for debian packages. Currently > they have to be manually added and removed in the maintainer > scripts. This method is prone to errors and can easily leave > diversions or alternatives behind. Instead I suggest creating two new > control files detailing the diversions and alternatives a package > should have. Can symlinks be supported in the declarative control file stanzas? One problem within Emdebian is replacing coreutils etc. with busybox - currently we are having to use a rigid replacement where the options enabled in busybox must be removed from the package set (or added as Conflicts: in busybox) and then the symlinks for each applet are listed in the dpkg file list. This requires a particular level of coordination and makes it harder to customise Emdebian for a different scenario. If both /bin/foo and /bin/bar are called during the boot/init process, the issue is allowing for this scenario: Install package foo, includes symlink /bin/bar -> /bin/foo Also includes a variety of others (about 30 in total). At a later date, the installation needs to be customised to allow the "full" version of /bin/bar from package bar to be installed for extra functionality. If Replaces: is used, bar cannot be removed because the box would not be bootable anymore - the previous symlink has gone forever. How to divert a symlink such that it can be restored later? Alternatives isn't a good solution because it means reimplementing the alternatives support code to avoid the use of Perl - and alternatives (IIRC) does not support symlinks as alternatives. What I need to avoid is having to make dozens of changes to postinst scripts to enable diversions in a long list of packages. Busybox 1.10.3 (not yet in Debian) does support discrete binaries linked to a shared library version of busybox but the library is bigger than the current busybox binary and each discrete binary is just over 4Kb so that is an appreciable increase in total size. (Seeing as this is busybox, size increases must be avoided.) It would allow the use of alternatives (subject to replacement non-perl code) but that method also needs changes in other packages (currently). So that costs an extra 2Mb or so and involves rewriting the code supporting alternatives - not my favourite option when the entire OS has to fit into 32Mb (or 64Mb for a full GUI using glibc). -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: gnome, kde, xfce use non-policy main menu
Josselin Mouette wrote: > Therefore, I still feel that, despite it being a big mess, the current > situation is the best: > * the default menu contains only what is needed, and we are still > hunting down entries that are useless to make them not show up > by default; > * users wanting the Debian menu and its gazillions of entries > including window managers, terminal emulators and shell > interpreters can enable it easily in the menu editor; > * those really wanting only the Debian menu can replace > gnome-applications.menu by debian-menu.menu. > > If you want this to change, you need to seriously think about evolutions > to both XDG and Debian menu systems, to convince fd.o and the Debian > menu maintainer to implement them Actually, no, if you want this to change, you have only to do nothing. People (many of them MOTUs from Ubuntu in my experience) are filing lots of requestes for random packages to have .desktop files added to them, so they appear in the gnome menu. The criteria seems to be "a program that $RANDOM_USER would like to have on the menu and files a bug about || that $RANDOM_UPSTREAM ships a desktop file for, for whatever reason". So, after sufficient time, the gnome menu will contain a random assortment of the menu items that also appear in the debian menu. Not a well-chosen and consistent assortment, but the kind of random assortment that you get when you ignore policy and go off on your own way. -- see shy jo signature.asc Description: Digital signature
Re: gnome, kde, xfce use non-policy main menu
Twas brillig at 13:08:40 06.07.2008 UTC-04 when [EMAIL PROTECTED] did gyre and gimble: JH> So, after sufficient time, the gnome menu will contain a random JH> assortment of the menu items that also appear in the debian menu. fd.o menus are designed to allow distro-specific policy. It's the matter of Debian KDE/Gnome packaging/menu policy to get the proper subset of the packages in menu (e.g. moving Gnome/gtk applications deeper in KDE menu and Qt/KDE - in Gnome one). -- pgpojItIrtG20.pgp Description: PGP signature
Re: gnome, kde, xfce use non-policy main menu
On Sun, Jul 06, 2008 at 01:08:40PM -0400, Joey Hess wrote: > Josselin Mouette wrote: > > Therefore, I still feel that, despite it being a big mess, the current > > situation is the best: > > * the default menu contains only what is needed, and we are still > > hunting down entries that are useless to make them not show up > > by default; > > * users wanting the Debian menu and its gazillions of entries > > including window managers, terminal emulators and shell > > interpreters can enable it easily in the menu editor; > > * those really wanting only the Debian menu can replace > > gnome-applications.menu by debian-menu.menu. > > > > If you want this to change, you need to seriously think about evolutions > > to both XDG and Debian menu systems, to convince fd.o and the Debian > > menu maintainer to implement them > > Actually, no, if you want this to change, you have only to do nothing. > > People (many of them MOTUs from Ubuntu in my experience) are filing lots of > requestes for random packages to have .desktop files added to them, so > they appear in the gnome menu. The criteria seems to be "a program that > $RANDOM_USER would like to have on the menu and files a bug about || > that $RANDOM_UPSTREAM ships a desktop file for, for whatever reason". I wouldn't be surprised if most of those had "NoDisplay=true" as one of the fields[0]. While there may be a drive to add .desktop files to packaging, there's a similar (sometimes overzealous, IME) drive to have them not displayed by default. [0] - https://wiki.ubuntu.com/UbuntuPackagingChanges?highlight=%28NoDisplay%29#head-5c07e3429829189474d24f6bcc1f2bee2f385e9a -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: gnome, kde, xfce use non-policy main menu
Mikhail Gusarov wrote: > fd.o menus are designed to allow distro-specific policy. It's the matter > of Debian KDE/Gnome packaging/menu policy to get the proper subset of > the packages in menu (e.g. moving Gnome/gtk applications deeper in KDE > menu and Qt/KDE - in Gnome one). That might work for gnome and kde, which are both fairly well defined, to ignore menu items belonging to each other, but won't it be a game of whack-a-mole for the rest of the things with menu entries? (Just for example, I recently orphaned xgalaga, so its new maintainers decided to do something about #432398, which I had been sitting on for some time as this issue was not resolved. Now I check my gnome machine and it has two galaga menu items in amoungst the standard gnome games.) -- see shy jo signature.asc Description: Digital signature
Re: gnome, kde, xfce use non-policy main menu
On 2008-07-06, Mikhail Gusarov <[EMAIL PROTECTED]> wrote: > fd.o menus are designed to allow distro-specific policy. It's the matter > of Debian KDE/Gnome packaging/menu policy to get the proper subset of > the packages in menu (e.g. moving Gnome/gtk applications deeper in KDE > menu and Qt/KDE - in Gnome one). I actually don't like this - just as I don't like the "kde" and "gnome" package sections. The users should have equal access to good programs. Most people (no matter what desktop they are using) thinks that - amarok is better than the gnome equivalent (rythmbox?) - gimp is better than the kde equivalent (released versions of krita) - kontact and evolution - fits different to different people At least, the KDE section seems to be a nice dumping ground for anything that links against kdelibs - and in some cases just Qt. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#431066: install network/ip-up.d script to check for IP duplicates
On Jun 29, Robert Millan <[EMAIL PROTECTED]> wrote: > Note that duplicate IPs can be very harmful and even cause loss of data. For Come on, how often this happens? And it's disabled by default anyway. The major effect of this patch is to waste time on almost every system every time *any* interface is raised. It's concerning that more and more packages are adding useless scripts to the if-*.d directories, apparently without thinking about the consequences for firewalls with a large number of interfaces. -- ciao, Marco signature.asc Description: Digital signature
Re: Strange file problem
Andrea Ferraresi wrote: > Hello folks, > i have some trouble about a strange file problem experienced after > a filesystem [ReiserFS] crash. > In the /var/run directory I have 3 files (sshd.pid, sudo, motd) that cannot > be accessed in any way. I try to remove it but rm -f returns a > "permission denied" message > sshd doesn't work but sudo does. The Inode has value 0 in all cases. > Have you got any ideas? You may need to perform a reiserfsck --rebuild-tree http://www.linuxquestions.org/linux/answers/Hardware/ReiserFS_Data_Recovery_Tips http://tinyurl.com/9pl2e This option rebuilds the entire file system tree using leaf nodes found on the device. Normally you only need this option if the --check option reports "corruption that can be fixed only during --rebuild-tree". You are strongly encouraged to make a backup copy of the whole partition before attempting the --rebuild-tree option. Good luck. -- John H. Robinson, IV [EMAIL PROTECTED] http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnome, kde, xfce use non-policy main menu
On Sun, Jul 06, 2008, Sune Vuorela wrote: > On 2008-07-06, Mikhail Gusarov <[EMAIL PROTECTED]> wrote: > > fd.o menus are designed to allow distro-specific policy. It's the matter > > of Debian KDE/Gnome packaging/menu policy to get the proper subset of > > the packages in menu (e.g. moving Gnome/gtk applications deeper in KDE > > menu and Qt/KDE - in Gnome one). > > I actually don't like this - just as I don't like the "kde" and "gnome" > package sections. > > The users should have equal access to good programs. Are you commenting on OnlyShowIn? This feature is not meant to list all GNOME-ish apps in GNOME and KDE-ish apps in KDE. It's meant to prevent some silly things to display across desktops. For instance "gnome-about" (About GNOME) shouldn't show in the KDE menus, nor should the configuration applets for window management, keyboard etc. which touch GNOME specific GConf settings, or nautilus-cd-burner... There are "only" 47 desktop files with OnlyShowIn on my system out of 218 desktop files installed, so it's not used too wildly I would say. (Some of these are probably bogus.) > Most people (no matter what desktop they are using) thinks that > - amarok is better than the gnome equivalent (rythmbox?) there isn't "one" GNOME player; I don't know whether amarok is OnlyShowIn KDE, but Rhythmbox should show up in KDE menus, just like Banshee and I hope the other players as well (Quodlibet, etc.). > - gimp is better than the kde equivalent (released versions of krita) > - kontact and evolution - fits different to different people These don't have an OnlyShowIn here and should show up in KDE menus. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnome, kde, xfce use non-policy main menu
On 2008-07-06, Loïc Minier <[EMAIL PROTECTED]> wrote: >> > of Debian KDE/Gnome packaging/menu policy to get the proper subset of >> > the packages in menu (e.g. moving Gnome/gtk applications deeper in KDE >> > menu and Qt/KDE - in Gnome one). >> >> The users should have equal access to good programs. > > Are you commenting on OnlyShowIn? This feature is not meant to list No. the thing that makes "moving Gnome/gtk application deeper in KDE menu..." /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
correct definition of localhost?
Hi folks,
I've run across an ipv4/ipv6 configuration issue which I think needs to have
light cast on it so we can try to resolve this in time for lenny (whatever
the right resolution actually is), in order to avoid a pile-up of
/etc/hosts-related kludges as has been known to happen before...
In response to bug #427067, the netbase maintainer made a change that adds
localhost as an alias for ::1 on new installs. In April of this year, the
Debian Installer team followed suit, adding this line in the netcfg udeb.
The result of these changes is that since July 2007, any new lenny or sid
chroots have had two addresses listed for localhost, and since April of this
year, any new installs of lenny done using d-i have had it as well.
Now, the problem I ran into is that when I enabled the test suite in the
openldap2.3 package, the build failed mysteriously on a seemingly random set
of architectures. The reason? The test suite configures slapd to run on a
particular port on localhost, and the glibc "files" NSS backend
special-cases the ::1 IPv6 loopback address, so that when you request an
IPv4 address, it will map any ::1 entries to 127.0.0.1 for you. But of
course we already have an entry for localhost as 127.0.0.1, so now we end up
with duplicate addresses returned, and slapd tries to bind twice to the same
address and port!
A test program showing this behavior is attached - compile and run it on a
system with '::1 localhost' set in /etc/hosts, and you'll see 127.0.0.1
returned twice. An alternate test case, which also works on systems with
older /etc/hosts and which I think shows the counterintuitiveness of the
nss_files special-casing, is to run "getent ahostsv4 ip6-localhost".
I don't think it's the responsibility of callers such as slapd to check that
getaddrinfo() hasn't returned duplicate entries, so I see a couple of
solutions here:
- the ::1 address should *not* be special-cased by nss_files. I really
can't perceive any reason why it should be special-cased in the first
place; i.e., why should the files backend behave differently than the DNS
backend, and why would we want names that were specifically assigned to
::1, including names like "ip6-loopback", to be automatically mapped to
127.0.0.1?
- we should only set up a single 'localhost' entry in /etc/hosts, pointing
at ::1, and let nss_files handle the mapping to 127.0.0.1 automatically.
Are there other solutions that should be considered? Is one of these more
acceptable than the other? To me it seems obvious that the best choice is
to not treat the files backend specially in the first place, but I don't
know the rationale behind this special-casing either.
Cheers,
--
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/
[EMAIL PROTECTED] [EMAIL PROTECTED]
#include
#include
#include
#include
#include
#include
int main() {
const char *host= "localhost";
const char *port= "9011";
struct addrinfo hints, *res, *sai;
struct hostent *result;
char buf[INET6_ADDRSTRLEN];
int buflen = sizeof(buf);
int err;
/* this call is just here to force glibc to set up the internal
* _res state, so that it sees the "multi on" that's configured
* by default in /etc/host.conf when we call getaddrinfo() below.
* Of course we could just use gethostbyname_r() itself, but
* getaddrinfo() is a truer test case.
*/
gethostbyname_r(host, NULL, NULL, 0, &result, &err);
memset( &hints, '\0', sizeof(hints) );
hints.ai_flags = AI_PASSIVE;
hints.ai_socktype = SOCK_STREAM;
hints.ai_family = AF_UNSPEC;
err = getaddrinfo(host, port, &hints, &res);
if (err) {
perror("getaddrinfo failed");
exit(1);
}
for (sai = res; sai != NULL; sai = sai->ai_next)
{
switch (sai->ai_family) {
case AF_INET6:
inet_ntop(AF_INET6,
&((struct sockaddr_in6 *)sai->ai_addr)->sin6_addr,
buf, buflen);
break;
case AF_INET:
inet_ntop(AF_INET,
&((struct sockaddr_in *)sai->ai_addr)->sin_addr,
buf, buflen);
break;
}
printf("name returned: %s\n",buf);
}
}
Bug#489587: ITP: python-scriptutil -- Python module which provides the functionality of find and grep
Package: wnpp Severity: wishlist Owner: Matthew Johnson <[EMAIL PROTECTED]> X-Debbugs-CC: debian-devel@lists.debian.org Source package: python-scriptutil Binary package(s): python-scriptutil Version: 1 Licence: BSD Author: Muharem Hrnjadovic Homepage: http://hrnjad.net/src/7/scriptutil.py Description: Python module which provides the functionality of find and grep This package contains a python module which provides a recursive find on the filesystem and searching within those files. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnome, kde, xfce use non-policy main menu
On Mon, 07 Jul 2008 00:13:30 +0700 Mikhail Gusarov <[EMAIL PROTECTED]> wrote: > Twas brillig at 13:08:40 06.07.2008 UTC-04 when [EMAIL PROTECTED] did > gyre and gimble: > > JH> So, after sufficient time, the gnome menu will contain a random > JH> assortment of the menu items that also appear in the debian menu. > > fd.o menus are designed to allow distro-specific policy. It's the > matter of Debian KDE/Gnome packaging/menu policy to get the proper > subset of the packages in menu (e.g. moving Gnome/gtk applications > deeper in KDE menu and Qt/KDE - in Gnome one). But that's just the point; there is no policy. -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org No more sea shells: Daniel's Webloghttp://cshore.wordpress.com signature.asc Description: PGP signature
Re: correct definition of localhost?
On Sun, Jul 06, 2008 at 03:09:09PM -0700, Steve Langasek wrote: > Hi folks, > > I've run across an ipv4/ipv6 configuration issue which I think needs to have > light cast on it so we can try to resolve this in time for lenny (whatever > the right resolution actually is), in order to avoid a pile-up of > /etc/hosts-related kludges as has been known to happen before... > > In response to bug #427067, the netbase maintainer made a change that adds > localhost as an alias for ::1 on new installs. In April of this year, the > Debian Installer team followed suit, adding this line in the netcfg udeb. > > The result of these changes is that since July 2007, any new lenny or sid > chroots have had two addresses listed for localhost, and since April of this > year, any new installs of lenny done using d-i have had it as well. > > Now, the problem I ran into is that when I enabled the test suite in the > openldap2.3 package, the build failed mysteriously on a seemingly random set > of architectures. The reason? The test suite configures slapd to run on a > particular port on localhost, and the glibc "files" NSS backend > special-cases the ::1 IPv6 loopback address, so that when you request an > IPv4 address, it will map any ::1 entries to 127.0.0.1 for you. But of > course we already have an entry for localhost as 127.0.0.1, so now we end up > with duplicate addresses returned, and slapd tries to bind twice to the same > address and port! You don't seem to request ipv4 addresses, you request AF_UNSPEC, which should get you both ipv4 and ipv6. You get 127.0.0.1 twice, and ::1 one time. > A test program showing this behavior is attached - compile and run it on a > system with '::1 localhost' set in /etc/hosts, and you'll see 127.0.0.1 > returned twice. An alternate test case, which also works on systems with > older /etc/hosts and which I think shows the counterintuitiveness of the > nss_files special-casing, is to run "getent ahostsv4 ip6-localhost". > > I don't think it's the responsibility of callers such as slapd to check that > getaddrinfo() hasn't returned duplicate entries, so I see a couple of > solutions here: > > - the ::1 address should *not* be special-cased by nss_files. I really > can't perceive any reason why it should be special-cased in the first > place; i.e., why should the files backend behave differently than the DNS > backend, and why would we want names that were specifically assigned to > ::1, including names like "ip6-loopback", to be automatically mapped to > 127.0.0.1? I can't find any good reason why it should be changing ::1 to 127.0.0.1. So I think that atleast glibc should stop doing that. In any case, it shouldn't return 127.0.0.1 twice when it's not configured to return it twice. > - we should only set up a single 'localhost' entry in /etc/hosts, pointing > at ::1, and let nss_files handle the mapping to 127.0.0.1 automatically. - You could also argue that openldap should get fixed to deal with cases where it tries to bind to the same ip/port twice. On the other hand, I don't think it a normal case, and I think it's unlikely that people would set up dns to have 2 times the same IP address and then try to bind to that hostname. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: correct definition of localhost?
On Mon, Jul 07, 2008 at 01:39:37AM +0200, Kurt Roeckx wrote: > You don't seem to request ipv4 addresses, you request AF_UNSPEC, which > should get you both ipv4 and ipv6. You get 127.0.0.1 twice, and ::1 one > time. You'll find that the duplication of 127.0.0.1 is still there if you specify AF_INET instead, because the problematic duplication happens when requesting records for the ipv4 address family. I left it as AF_UNSPEC in the test case to show that the problem exists when using protocol-agnostic best practices, which is what slapd does. >> - the ::1 address should *not* be special-cased by nss_files. I really >> can't perceive any reason why it should be special-cased in the first >> place; i.e., why should the files backend behave differently than the DNS >> backend, and why would we want names that were specifically assigned to >> ::1, including names like "ip6-loopback", to be automatically mapped to >> 127.0.0.1? > I can't find any good reason why it should be changing ::1 to 127.0.0.1. > So I think that atleast glibc should stop doing that. In any case, it > shouldn't return 127.0.0.1 twice when it's not configured to return > it twice. What do you mean by "configured to return it twice"? Would that mean duplicate lines in /etc/hosts (i.e., misconfiguration)? >> - we should only set up a single 'localhost' entry in /etc/hosts, pointing >> at ::1, and let nss_files handle the mapping to 127.0.0.1 automatically. > - You could also argue that openldap should get fixed to deal with cases > where it tries to bind to the same ip/port twice. On the other hand, > I don't think it a normal case, and I think it's unlikely that people > would set up dns to have 2 times the same IP address and then try > to bind to that hostname. Well, as I said before, >> I don't think it's the responsibility of callers such as slapd to check that >> getaddrinfo() hasn't returned duplicate entries [...] so if you have an argument of why extra complexity should be added to the caller to deal with duplicate records which, one way or another, should not exist (IMHO), I'm interested to hear it. As for DNS, at least in the case of bind I find that duplicate records are weeded out by the server. If you can suggest a DNS server that would not condense the duplicate records, I'd be happy to test to see what the behavior of nss_dns is. -- 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tarball in tarball: opinions
On Sat, Jul 05, 2008 at 08:17:21PM +0200, Bernhard R. Link wrote: > * Jay Berkenbilt <[EMAIL PROTECTED]> [080705 18:22]: > > * I like to have an exact copy of the downloaded source tarball with > >the same md5 checksum, gpg detached signature, etc. Using the > >rules/tarball.mk from cdbs provides a very convenient way of > >handling this. > > I consider this the main reason I personally consider tarball in tarball > bad: The .orig.tar.gz is totally different to the upstream tarball. > If upstream already has a .tar.gz then there is no excuse in my eyes > and even with .tar.bz2 it's easier to download this, check it, unpack > both and compare some checksums, than to first look into the file if it > is the same, then detecting it is not supposed to be the upstream file, > unpack it, look how the file is named in there and then comparing those. All the 3.0 formats allow bzip2 tarballs so that will no longer be a reason to do this. 3.0 (quilt) also allows multiple upstream tarballs which used to be a good reason for using tarball-in-tarball. Ben. -- Ben Hutchings Design a system any fool can use, and only a fool will want to use it. signature.asc Description: Digital signature
Re: Bug#431066: install network/ip-up.d script to check for IP duplicates
On Sun, Jul 06, 2008 at 08:03:13PM +0200, Marco d'Itri wrote: > On Jun 29, Robert Millan <[EMAIL PROTECTED]> wrote: > > > Note that duplicate IPs can be very harmful and even cause loss of data. > > For > Come on, how often this happens? And it's disabled by default anyway. > The major effect of this patch is to waste time on almost every system > every time *any* interface is raised. And DHCP clients should double-check their assigned address with ARP anyway, so it's duplicating this check on most systems. > It's concerning that more and more packages are adding useless scripts > to the if-*.d directories, apparently without thinking about the > consequences for firewalls with a large number of interfaces. Seems like this script really belongs in the examples directory. Ben. -- Ben Hutchings Design a system any fool can use, and only a fool will want to use it. signature.asc Description: Digital signature
Re: correct definition of localhost?
On Sun, 2008-07-06 at 17:14 -0700, Steve Langasek wrote: > > As for DNS, at least in the case of bind I find that duplicate records > are > weeded out by the server. If you can suggest a DNS server that would > not > condense the duplicate records, I'd be happy to test to see what the > behavior of nss_dns is. PowerDNS doesn't condense anything. It returns whatever is in the MySQL database... William signature.asc Description: This is a digitally signed message part
Re: gnome, kde, xfce use non-policy main menu
On Mon, Jul 7, 2008 at 1:41 AM, Joey Hess <[EMAIL PROTECTED]> wrote: > (Just for example, I recently orphaned xgalaga, so its new maintainers > decided to do something about #432398, which I had been sitting on for > some time as this issue was not resolved. Now I check my gnome machine > and it has two galaga menu items in amoungst the standard gnome games.) On my system it goes in the Games/Arcade menu. I think GNOME adapts its menus to the number of items and the hints and categories in the desktop files, doesn't seem to be a strict heirarchy like the Debian menu is. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: correct definition of localhost?
Steve Langasek a écrit : > Hi folks, > > I've run across an ipv4/ipv6 configuration issue which I think needs to have > light cast on it so we can try to resolve this in time for lenny (whatever > the right resolution actually is), in order to avoid a pile-up of > /etc/hosts-related kludges as has been known to happen before... > > In response to bug #427067, the netbase maintainer made a change that adds > localhost as an alias for ::1 on new installs. In April of this year, the > Debian Installer team followed suit, adding this line in the netcfg udeb. > > The result of these changes is that since July 2007, any new lenny or sid > chroots have had two addresses listed for localhost, and since April of this > year, any new installs of lenny done using d-i have had it as well. > > Now, the problem I ran into is that when I enabled the test suite in the > openldap2.3 package, the build failed mysteriously on a seemingly random set > of architectures. The reason? The test suite configures slapd to run on a > particular port on localhost, and the glibc "files" NSS backend > special-cases the ::1 IPv6 loopback address, so that when you request an > IPv4 address, it will map any ::1 entries to 127.0.0.1 for you. But of > course we already have an entry for localhost as 127.0.0.1, so now we end up > with duplicate addresses returned, and slapd tries to bind twice to the same > address and port! > > A test program showing this behavior is attached - compile and run it on a > system with '::1 localhost' set in /etc/hosts, and you'll see 127.0.0.1 > returned twice. An alternate test case, which also works on systems with > older /etc/hosts and which I think shows the counterintuitiveness of the > nss_files special-casing, is to run "getent ahostsv4 ip6-localhost". > > I don't think it's the responsibility of callers such as slapd to check that > getaddrinfo() hasn't returned duplicate entries, so I see a couple of > solutions here: > > - the ::1 address should *not* be special-cased by nss_files. I really > can't perceive any reason why it should be special-cased in the first > place; i.e., why should the files backend behave differently than the DNS > backend, and why would we want names that were specifically assigned to > ::1, including names like "ip6-loopback", to be automatically mapped to > 127.0.0.1? > > - we should only set up a single 'localhost' entry in /etc/hosts, pointing > at ::1, and let nss_files handle the mapping to 127.0.0.1 automatically. > > Are there other solutions that should be considered? Is one of these more > acceptable than the other? To me it seems obvious that the best choice is > to not treat the files backend specially in the first place, but I don't > know the rationale behind this special-casing either. There is a bug upstream, but marked as invalid: http://sources.redhat.com/bugzilla/show_bug.cgi?id=4980 According to the upstream developer, there is a rationale for that, but he never explained it, despite having been asked numerous times. Somebody has published a patch, if it works as expected, it may be worth to include it in Debian. Cheers, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: correct definition of localhost?
On Sun, Jul 06, 2008 at 05:14:44PM -0700, Steve Langasek wrote: > On Mon, Jul 07, 2008 at 01:39:37AM +0200, Kurt Roeckx wrote: > > > You don't seem to request ipv4 addresses, you request AF_UNSPEC, which > > should get you both ipv4 and ipv6. You get 127.0.0.1 twice, and ::1 one > > time. > > You'll find that the duplication of 127.0.0.1 is still there if you specify > AF_INET instead, because the problematic duplication happens when requesting > records for the ipv4 address family. I left it as AF_UNSPEC in the test > case to show that the problem exists when using protocol-agnostic best > practices, which is what slapd does. I was just confused when reading it, and understood it as only requesting AF_INET. That was just to make it clear. > >> - the ::1 address should *not* be special-cased by nss_files. I really > >> can't perceive any reason why it should be special-cased in the first > >> place; i.e., why should the files backend behave differently than the DNS > >> backend, and why would we want names that were specifically assigned to > >> ::1, including names like "ip6-loopback", to be automatically mapped to > >> 127.0.0.1? > > > I can't find any good reason why it should be changing ::1 to 127.0.0.1. > > So I think that atleast glibc should stop doing that. In any case, it > > shouldn't return 127.0.0.1 twice when it's not configured to return > > it twice. > > What do you mean by "configured to return it twice"? Would that mean > duplicate lines in /etc/hosts (i.e., misconfiguration)? Yes. > >> - we should only set up a single 'localhost' entry in /etc/hosts, pointing > >> at ::1, and let nss_files handle the mapping to 127.0.0.1 automatically. > > > - You could also argue that openldap should get fixed to deal with cases > > where it tries to bind to the same ip/port twice. On the other hand, > > I don't think it a normal case, and I think it's unlikely that people > > would set up dns to have 2 times the same IP address and then try > > to bind to that hostname. > > Well, as I said before, > > >> I don't think it's the responsibility of callers such as slapd to check > >> that > >> getaddrinfo() hasn't returned duplicate entries [...] > > so if you have an argument of why extra complexity should be added to the > caller to deal with duplicate records which, one way or another, should not > exist (IMHO), I'm interested to hear it. The only case I can come up with would be misconfiguration, which I don't think is a good reason. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnome, kde, xfce use non-policy main menu
Twas brillig at 18:52:35 06.07.2008 UTC-04 when [EMAIL PROTECTED] did gyre and gimble: >> fd.o menus are designed to allow distro-specific policy. It's the >> matter of Debian KDE/Gnome packaging/menu policy to get the proper >> subset of the packages in menu (e.g. moving Gnome/gtk applications >> deeper in KDE menu and Qt/KDE - in Gnome one). DD> But that's just the point; there is no policy. And that's the problem need to be solved, not the fd.o menu system or Ubuntu MOTU - misusing the spec does not give the right to anyone to blame spec or those who follow it. -- pgpAdJQXW7BpV.pgp Description: PGP signature
Re: Not stopping daemons, where are we?
* Bernd Eckenfels | In article <[EMAIL PROTECTED]> you wrote: | > Why are all of you talking as though sending SIGTERM were not the | > standard way to tell a process to save its state and exit gracefully? | | Thats not the point. It is a quesion of sequence. When you get the killall5 | sigterm, then everybody else also gets it. Especially maybe your file | service server. So you might not able to save. If the local admin introduces other dependencies than what can reasonably be set as defaults, he should also make sure to adjust dependency and stop-level headers in init scripts. If he fails to do that, he might break his system, just like if he doesn't take care when doing all other kinds of maintenance to the system. We can give the admin reasonable tools to do his job, but we can't do it for him, nor can we divine any setup that an admin might come up with and which might confuse the tools we have provided. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnome, kde, xfce use non-policy main menu
On Sun, 6 Jul 2008 13:41:30 -0400 Joey Hess <[EMAIL PROTECTED]> wrote: > Mikhail Gusarov wrote: > > fd.o menus are designed to allow distro-specific policy. It's the > > matter of Debian KDE/Gnome packaging/menu policy to get the proper > > subset of the packages in menu (e.g. moving Gnome/gtk applications > > deeper in KDE menu and Qt/KDE - in Gnome one). > > That might work for gnome and kde, which are both fairly well defined, > to ignore menu items belonging to each other, but won't it be a game > of whack-a-mole for the rest of the things with menu entries? And depends on the package maintainer being cooperative. Because there is no debian policy on this if a package maintainer disagrees they don't have to hide their menu entry. -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org No more sea shells: Daniel's Webloghttp://cshore.wordpress.com signature.asc Description: PGP signature
Re: Multiarch and idea for improved diversions and alternatives handling
* Neil Williams (Please respect my Mail-Followup-To and my Mail-Copies-To: never) | On Fri, 2008-07-04 at 08:33 +0200, Tollef Fog Heen wrote: | | > How would you then handle libraries that go in /lib? (Apart from the | > fact that I think just using a subdirectory of /usr/lib is much neater | > than random subdirectories in /usr. | | /lib/ | /arm-linux-gnu/lib/ | | (did I miss that bit?) Yes. | A single subdirectory of /usr is, IMHO, neater than a subdirectory | of /usr/include and /usr/lib/. It would be a subdirectory of / as well. | It would also mean less changes for those who are currently using | multiple architectures on one system for the purposes of cross | building. I wouldn't want to go the whole hog though and have | /arm-linux-gnu/usr/lib /arm-linux-gnu/lib because that would be | ugly, at least to me. I think it'd be about as ugly as having /$triplet anyway. | > | /usr/include/ | > | /usr/arm-linux-gnu/include/ | > | > Please note that the initial goal of multiarch at least has been just | > running of packages from foreign architectures. Not building them. | | True but the current usage of these mechanisms is in cross-building so | sometimes the results of having to do something without major changes | elsewhere can be helpful in designing the subsequent mechanism. Part of the point of multiarch is we don't actually need to make major changes. We need to do some fairly localised changes. | > | multiarch could even add: | > | /usr/share/ | > | /usr/arm-linux-gnu/share | > | > Pardon my language, but this is crack. The point of /usr/share is you | > can share it between systems. If you go down this route, just use a | > chroot and some wrapper scripts to bounce between them instead. | | It was only a suggestion for /usr/share - it was an alternative to | renaming the package to get a different directory in /usr/share/ as the | current tools do. Until all suitable packages have things like | translations separated out into TDebs and other things like images in a | -data or -common package instead of being packaged along with the | architecture-dependent binaries, conflicts will occur if /usr/share is | used as intended. Or we could get the file exclusion branch in dpkg applied and add support for excluding files based on the arch of the package being installed. Voila, no problems with file conflicts in /usr/share. | > I don't believe anybody has suggested using just /usr/lib/i386, but | > rather /usr/lib/i486-linux-gnu? | | OK - as I said, my connection has been flaky and I might have missed | that bit. This bit has been public and on the table at least since I wrote my master thesis in 2005. :-P I don't think anybody has suggested anything else since then. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
