Re: from / to /usr/: a summary

Jonathan Nieder writes: > Hi, > > Just a quick side-note. >... > The main technical difficulty seems to be platforms where it is common > to boot without an initramfs (for example, if it is hard to > reconfigure the bootloader and the bootloader is already set up to use > a plain kernel). > > Hop

Re: Getting dh_install to do what we need

Goswin von Brederlow writes: >> Compared to writing overrides, it's less effort. Compared to just >> writing the variable and expecting it to work, it's two commands more. I >> believe that's not much. >> >> On the other hand, though, making it obvious that it's a script, and >> there's magic (=

Re: from / to /usr/: a summary

m...@linux.it (Marco d'Itri) writes: > Some people also argued that they would be more comfortable with a > smaller root file system which can act as a rescue system, but I am > not sure about which tools they would miss from an initramfs with > busybox and fsck. lvm, dmsetup, mdadm, crypto stuff

Re: Getting dh_install to do what we need

Gergely Nagy writes: > Thomas Goirand writes: > >> Disclaimer: I didn't write any multiarch packaging (yet). >> >> The incentive for doing all this seems to be multiarch. Why >> instead don't we have a mechanism to have variables in >> debian/*.install instead, or a dh_helper to move things to >

Re: Getting dh_install to do what we need

Goswin von Brederlow writes: >> I'll happily use the new dh_install feature instead of whining. > > You are forgetting that there are more people than just you looking at > your package. By using an obviously verry controversial feature you will > make everybody else life more difficult. You're

Re: Getting dh_install to do what we need

Bernd Zeimetz writes: > On 12/07/2011 11:47 PM, Josselin Mouette wrote: >> Now that we’ve made incredible progress in terms of obfuscation, I’d >> appreciate if we could have a working solution that does not require >> scripting for the most trivial operations. So what remains? >> * Co

Re: from / to /usr/: a summary

Marco d'Itri wrote: > In this case, it has been made repeatedly clear by the upstream > maintainers that they have no desire to accept code to support this and > other things. _If_ upstream is taking the stance that portability to other platforms is something they want nothing to do with, then th

Re: Getting dh_install to do what we need

Gergely Nagy writes: > Steve Langasek writes: > >> On Thu, Dec 08, 2011 at 10:07:12PM +0100, Gergely Nagy wrote: >>> Kees Cook writes: >> >>> > Which means I can't use DEB_HOST_MULTIARCH in the config-scripts, >>> > unfortunately. >> >>> Not to worry! dh-subst will be coming in a day or two (+

Re: Increasing minimum 'i386' processor

Ian Jackson writes: >> The 486-class processors that would no longer be supported are: >> 1. All x86 processors with names including '486' > > I'm still running the machine below, and it would be irritating to > have to replace it. ... > vendor_id : CentaurHauls > cpu family: 6 > model

GNU/Linux COM development and Wine/Samba

Hi there. I've got several projects in SourceForge, one of which is v3c-dcom http://sourceforge.net/projects/v3c-dcom/ I'm quickly coming to the realisation that I would need several headers/tools from Wine http://www.winehq.org/ , the idea being to be able to develop COM components n

Bug#651489: ITP: webfinance-front-office -- manage invoices and handle client contacts

Package: wnpp Severity: wishlist Owner: "Roberto C. Sanchez" -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: webfinance-front-office Version : 0.0~git+20111207 Upstream Author : Cyril Bouthors * URL : https://github.com/cyrilb/WebFinance/tree/webfinan

Re: Getting dh_install to do what we need

On 11-12-08 at 05:48pm, Russ Allbery wrote: > Jonas Smedegaard writes: > > > Well, in a way this one is too: compat level 9 is not yet finalized, > > as I understand it. Just prematurely gotten into use due to its > > upcoming ability to handle multiarch. > > Yeah, and that was a little unfor

Re: from / to /usr/: a summary

Wookey writes: > this is not waste time with an intramfs that will soon be superceded > with a pivot-root. Not really related to the main issue but do note that pivot_root syscall has not been used for quite some time. run-init basically just uses unlink, mount, chroot and execve. > Most arm boo

Re: Getting dh_install to do what we need

Jonas Smedegaard writes: > Well, in a way this one is too: compat level 9 is not yet finalized, as > I understand it. Just prematurely gotten into use due to its upcoming > ability to handle multiarch. Yeah, and that was a little unfortunate. There are packages I've not converted to multiarch

Bug#651485: ITP: python-django-coverage -- test coverage reporting tool for Django

Package: wnpp Severity: wishlist Owner: "Roberto C. Sanchez" -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: python-django-coverage Version : 1.2.1 Upstream Author : Mikhail Korobov * URL : http://pypi.python.org/pypi/django-coverage * License

Re: Getting dh_install to do what we need

On 11-12-08 at 03:02pm, Russ Allbery wrote: > Gergely Nagy writes: > > > Apart from the reason explained in debhelper's git history, I can > > offer another: variable substitution would be an incompatible > > change, as it's perfectly legit to have '/usr/bin/${oh hai I broke > > your system}'

Work-needing packages report for Dec 9, 2011

The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 392 (new: 2) Total number of packages offered up for adoption: 143 (new: 4) Total number of packages request

Re: Getting dh_install to do what we need

Gergely Nagy writes: > Apart from the reason explained in debhelper's git history, I can offer > another: variable substitution would be an incompatible change, as it's > perfectly legit to have '/usr/bin/${oh hai I broke your system}' or > '/usr/lib/${DEB_HOST_MULTIARCH}' files. > So, we'd need

Orphaning genesis -- general-purpose neural simulator

reassign 648645 wnpp retitle 648645 O: genesis -- general-purpose neural simulator severity 648645 normal thanks I am hereby orphaning genesis on behalf of its maintainer. The description of genesis is: """ general-purpose neural simulator GENESIS is a general purpose simulation platform which

Re: Getting dh_install to do what we need

Steve Langasek writes: > On Thu, Dec 08, 2011 at 10:07:12PM +0100, Gergely Nagy wrote: >> Kees Cook writes: > >> > Which means I can't use DEB_HOST_MULTIARCH in the config-scripts, >> > unfortunately. > >> Not to worry! dh-subst will be coming in a day or two (+ NEW waiting >> time), which will

Re: from / to /usr/: a summary

On Dec 08, Wookey wrote: > However in practice it is very hard to support this sort of thing in > Debian anyway, because the way you get fast booting is by removing all > the generality in scripts which check what sort of hardware and then Agreed. Also, emebedded devices will probably either have

Re: from / to /usr/: a summary

On Dec 08, Jonathan Nieder wrote: > There is a third option: help upstream to maintain what they consider > the "legacy" alternative. Many upstreams, including at Red Hat, seem > to be willing to work with downstream packagers that contribute > patches. In this case, it has been made repeatedly

Orphaning emile

reassign 648933 wnpp retitle 648933 O: emile -- the Early Mac Image LoadEr severity 648933 normal thanks I am here by orphaning emile on behalf of the maintainers. The description of emile is: """ the Early Mac Image LoadEr EMILE provides a way to natively boot Macintosh computers which normal

Re: Getting dh_install to do what we need

On Thu, Dec 08, 2011 at 01:36:48PM -0800, Steve Langasek wrote: > On Thu, Dec 08, 2011 at 10:07:12PM +0100, Gergely Nagy wrote: > > Kees Cook writes: > > > Which means I can't use DEB_HOST_MULTIARCH in the config-scripts, > > > unfortunately. > > Not to worry! dh-subst will be coming in a day or

Re: Getting dh_install to do what we need

Thomas Goirand writes: > P.S: Is there any valid lintian clean package in the archive that doesn't > use any helper tools at all? That's would be very instructive... dpatch, for example. There are plenty of other examples in the archive. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ.

Re: Getting dh_install to do what we need

On Thu, Dec 08, 2011 at 10:07:12PM +0100, Gergely Nagy wrote: > Kees Cook writes: > > Which means I can't use DEB_HOST_MULTIARCH in the config-scripts, > > unfortunately. > Not to worry! dh-subst will be coming in a day or two (+ NEW waiting > time), which will allow you to use DEB_HOST_MULTIARC

Bug#651470: ITP: imagevis3d -- desktop volume rendering application for large data

Package: wnpp Severity: wishlist Owner: Mathieu Malaterre * Package name: imagevis3d Version : 2.1 Upstream Author : Tom Fogal * URL : http://www.imagevis3d.com * License : MIT Programming Lang: C++ Description : desktop volume rendering application fo

Re: Getting dh_install to do what we need

On 12/09/2011 03:58 AM, Gergely Nagy wrote: > [...] I don't know about you [...] > If it goes down to me, I would like using install -D -m [...] manually in my debian/rules files, but as others don't, I try avoiding such hacks these days... :) Note that using the BSD install is compatible with

Re: Getting dh_install to do what we need

Kees Cook writes: > Which means I can't use DEB_HOST_MULTIARCH in the config-scripts, > unfortunately. Not to worry! dh-subst will be coming in a day or two (+ NEW waiting time), which will allow you to use DEB_HOST_MULTIARCH as you'd expect to. -- |8] -- To UNSUBSCRIBE, email to debian-dev

Re: from / to /usr/: a summary

On Thu, 08 Dec 2011 at 21:14:05 +0100, Iustin Pop wrote: > Please excuse me if I misunderstand things, but there was no information > about this in the previous thread: why would gnome _ever_ care when /usr > is mounted? For "GNOME" read "system services which GNOME depends on", presumably. S

Re: Getting dh_install to do what we need

Kees Cook wrote: > We must be talking about separate things: Yes, there are so many ill-advised variables floating around the build system these days that I have trouble keeping them all straight. > Which means I can't use DEB_HOST_MULTIARCH in the config-scripts, > unfortunately. Happily there

Re: from / to /usr/: a summary

On Thu, Dec 08, 2011 at 08:16:57PM +0100, Marco d'Itri wrote: > On Dec 07, Stephan Seitz wrote: > > > If this is the future way and the way the developer want to go, then > > the way will succeed in time, but as Goswin said, it will take time. > > > > The admins who think the new way is bad will

Re: from / to /usr/: a summary

On Thu, Dec 08, 2011 at 07:46:41PM +, Wookey wrote: > +++ Marco d'Itri [2011-12-08 20:16 +0100]: > > On Dec 07, Stephan Seitz wrote: > > > > - the platform does not support an initramfs > > * I am still waiting for somebody to enumerate them, but I believe > > that I can design a

Re: Getting dh_install to do what we need

Steve Langasek wrote: > Also, I'm pretty sure the *FLAGS export happens only for dh_auto_* and > not for dh itself (set_buildflags is called from > /usr/share/perl5/Debian/Debhelper/Dh_Buildsystems.pm), so it still doesn't > help when called from dh_install. joey@gnu:~/src/debhelper>grep set_build

Re: from / to /usr/: a summary

+++ Marco d'Itri [2011-12-08 20:16 +0100]: > On Dec 07, Stephan Seitz wrote: > > - the platform does not support an initramfs > * I am still waiting for somebody to enumerate them, but I believe > that I can design a suitable workaround Anything that needs to boot fast (which is a lo

Re: Getting dh_install to do what we need

Thomas Goirand writes: > Disclaimer: I didn't write any multiarch packaging (yet). > > The incentive for doing all this seems to be multiarch. Why > instead don't we have a mechanism to have variables in > debian/*.install instead, or a dh_helper to move things to > the multiarch folder instead o

Re: Getting dh_install to do what we need

Chow Loong Jin writes: > On 09/12/2011 02:10, Gergely Nagy wrote: >> Chow Loong Jin writes: >> See my workaround in the mail you quoted. "#! /bin/sh $PATH" should work for kFreeBSD and pretty much anything else out there too. An extra /bin/sh never hurt anybody! >>> >>> Except th

Re: Getting dh_install to do what we need

+++ Thomas Goirand [2011-12-09 02:39 +0800]: > On 12/08/2011 06:47 AM, Josselin Mouette wrote: > > Closes: #235302, #372310, #235302, #614731, > > Closes: #438601, #477625, #632860, #642129 > > > > The incentive for doing all this seems to be multiarch. It's not just multiarch. The li

Re: from / to /usr/: a summary

Hi, Just a quick side-note. Marco d'Itri wrote: > Some changes are coming from upstream and we will have to either embrace > them or actively revert them. There is a third option: help upstream to maintain what they consider the "legacy" alternative. Many upstreams, including at Red Hat, seem

Re: Red Hat is moving from / to /usr/

+++ Sune Vuorela [2011-12-07 13:05 +]: > > Recovering involved > - a base64 decoder written in shell > - a statically linked busybox uuencoded and pasted into the console > - overwriting /bin/ln > - /bin/ln /bin/ln /bin/busybox We all had hardcore geeking fun that afternoon :-) Wookey -

from / to /usr/: a summary

On Dec 07, Stephan Seitz wrote: > If this is the future way and the way the developer want to go, then > the way will succeed in time, but as Goswin said, it will take time. > > The admins who think the new way is bad will not change their > systems. New admins may think otherwise, and if the ol

Re: Red Hat is moving from / to /usr/

On Dec 08, Guillem Jover wrote: > > I am not really looking forward to keep reverting these changes in my > > package, and since Red Hat controls most Linux infrastructure now other > > packages will face the same problem. > I might be missing something but given the link your posted, and looking

Re: Getting dh_install to do what we need

On Thu, Dec 08, 2011 at 02:47:00PM -0400, Joey Hess wrote: > Steve Langasek wrote: > > While I had originally believed this to be the case when drafting > > , feedback from those > > implementing this in practice is that dh does *not* export these va

Re: Getting dh_install to do what we need

On Thu, Dec 08, 2011 at 02:47:00PM -0400, Joey Hess wrote: > Steve Langasek wrote: > > While I had originally believed this to be the case when drafting > > , feedback from those > > implementing this in practice is that dh does *not* export these va

Re: Getting dh_install to do what we need

On 12/08/2011 06:47 AM, Josselin Mouette wrote: > For those who haven’t followed, the latest debhelper upload includes the > following change: > >* Debhelper config files may be made executable programs that output the > desired configuration. No further changes are planned to the config f

Re: Getting dh_install to do what we need

On 09/12/2011 02:10, Gergely Nagy wrote: > Chow Loong Jin writes: > >>> See my workaround in the mail you quoted. "#! /bin/sh $PATH" should work >>> for kFreeBSD and pretty much anything else out there too. An extra >>> /bin/sh never hurt anybody! >> >> Except that it forces your interpreter to b

Re: Getting dh_install to do what we need

Steve Langasek wrote: > While I had originally believed this to be the case when drafting > , feedback from those > implementing this in practice is that dh does *not* export these variables, > it only passes them to autoconf. That's not correct, dh

Re: Getting dh_install to do what we need

On Thu, Dec 08, 2011 at 06:51:51PM +0100, Andreas Metzler wrote: > Josselin Mouette wrote: > [...] > > So, to sum it up. Before, you would do in debian/rules: > >sed s/@DEB_HOST_MULTIARCH@/${DEB_HOST_MULTIARCH}/ > > debian/libfoo.install.in > debian/libfoo.install > [...] > a little bit

Re: Getting dh_install to do what we need

On 12/07/2011 11:47 PM, Josselin Mouette wrote: > Now that we’ve made incredible progress in terms of obfuscation, I’d > appreciate if we could have a working solution that does not require > scripting for the most trivial operations. So what remains? > * Convincing Joey to revert this usele

Re: Getting dh_install to do what we need

Chow Loong Jin writes: >> See my workaround in the mail you quoted. "#! /bin/sh $PATH" should work >> for kFreeBSD and pretty much anything else out there too. An extra >> /bin/sh never hurt anybody! > > Except that it forces your interpreter to be written in sh, which Debian > doesn't > like[1]

Re: Getting dh_install to do what we need

On 09/12/2011 01:40, Gergely Nagy wrote: > Adam Borowski writes: > *tad* It would need to be a compiled program, since you can’t use scripts in shebangs. >>> >>> Wrong, you can. >> >> On Linux and Hurd, yeah. >> On kFreeBSD, you can't. >> >> But hey, FreeBSD folks learned about

Re: Red Hat is moving from / to /usr/

On Wed, 2011-12-07 at 11:34:34 +0100, Marco d'Itri wrote: > I am not really looking forward to keep reverting these changes in my > package, and since Red Hat controls most Linux infrastructure now other > packages will face the same problem. I might be missing something but given the link your po

Re: Getting dh_install to do what we need

Josselin Mouette wrote: [...] > So, to sum it up. Before, you would do in debian/rules: >sed s/@DEB_HOST_MULTIARCH@/${DEB_HOST_MULTIARCH}/ > debian/libfoo.install.in > debian/libfoo.install [...] Hello, a little bit beside the point, but since the example seems to propagate through the

Re: Getting dh_install to do what we need

Adam Borowski writes: >> > *tad* >> > It would need to be a compiled program, since you can’t use scripts in >> > shebangs. >> >> Wrong, you can. > > On Linux and Hurd, yeah. > On kFreeBSD, you can't. > > But hey, FreeBSD folks learned about basic niceties like tab completion just > last yea

Re: Red Hat is moving from / to /usr/

Igor Pashev writes: > Goswin, thanks for the explanation. > Now I'm inclined to move all to /usr :-) We live to serve. :) I'm kind of undecided. I know eventualy this will just work and have eliminate all those "Hey, I have a strange setup and xyz needs to be in / for this" bugs. But I also am

Re: Getting dh_install to do what we need

On Thu, Dec 08, 2011 at 05:12:08PM +0100, Gergely Nagy wrote: > Josselin Mouette writes: > > > Le jeudi 08 décembre 2011 à 00:12 +0100, Gergely Nagy a écrit : > >> , > >> | #! /usr/bin/dh_multiarchify > >> | /usr/lib/${DEB_HOST_MULTIARCH}/* > >> ` > >> > >> The /usr/bin/dh_multiarchify

Re: Getting dh_install to do what we need

Goswin von Brederlow writes: >>> override_dh_auto_install: >>> debian/libfoo.my-install-script >> [..] >> >>> This new feature stinks of black-box magic that will make people crazy >>> trying to find/fix a prolem in somebody elses package. The thing that >>> make cdbs so bad. >> >> >> I beg t

Re: Getting dh_install to do what we need

On Thu, Dec 08, 2011 at 01:03:18PM -0400, Joey Hess wrote: > Kees Cook wrote: > > - Export DEB_* environment variables to the script. This really feels > > like the missing piece to me. > dh already does that in v9 mode. While I had originally believed this to be the case when drafting

Re: Getting dh_install to do what we need

Kees Cook wrote: > - Export DEB_* environment variables to the script. This really feels > like the missing piece to me. dh already does that in v9 mode. -- see shy jo signature.asc Description: Digital signature

Re: Getting dh_install to do what we need

Arno Töll writes: > Hello, > > On 08.12.2011 10:44, Goswin von Brederlow wrote: >> Or for the more general case: >> >> override_dh_auto_install: >> debian/libfoo.my-install-script > [..] > >> This new feature stinks of black-box magic that will make people crazy >> trying to find/fix a prole

Re: Getting dh_install to do what we need

Kees Cook writes: > - Export DEB_* environment variables to the script. This really feels > like the missing piece to me. I'd love this too. I already have a half-baked patch, implementing some generic substitution-foo that could use this (see #651393 for the details). -- |8] -- To UNSUBSC

Re: Red Hat is moving from / to /usr/

Stephan Seitz writes: > On Thu, Dec 08, 2011 at 10:25:07AM +0100, Goswin von Brederlow wrote: >>I guess mounting /usr is no more complicated than mounting / in >>initramfs. Finding out what modules and software is needed for that >>should be the same code as for /. > > That depends. I have some s

Re: Getting dh_install to do what we need

After looking at the bugs that are solved with this change, I don't think it's an unreasonable solution. That said, I think it feels incomplete. On Wed, Dec 07, 2011 at 11:47:49PM +0100, Josselin Mouette wrote: > So, to sum it up. Before, you would do in debian/rules: > sed s/@DEB_HOST_MU

Re: Getting dh_install to do what we need

Josselin Mouette writes: > Le jeudi 08 décembre 2011 à 00:12 +0100, Gergely Nagy a écrit : >> , >> | #! /usr/bin/dh_multiarchify >> | /usr/lib/${DEB_HOST_MULTIARCH}/* >> ` >> >> The /usr/bin/dh_multiarchify script > > *tad* > It would need to be a compiled program, since you can’t u

Re: Getting dh_install to do what we need

08.12.2011 18:49, Josselin Mouette пишет: Le jeudi 08 décembre 2011 à 00:12 +0100, Gergely Nagy a écrit : , | #! /usr/bin/dh_multiarchify | /usr/lib/${DEB_HOST_MULTIARCH}/* ` The /usr/bin/dh_multiarchify script *tad* It would need to be a compiled program, since you can’t use scri

Re: Getting dh_install to do what we need

Le jeudi 08 décembre 2011 à 00:12 +0100, Gergely Nagy a écrit : > , > | #! /usr/bin/dh_multiarchify > | /usr/lib/${DEB_HOST_MULTIARCH}/* > ` > > The /usr/bin/dh_multiarchify script *tad* It would need to be a compiled program, since you can’t use scripts in shebangs. -- .''`.

Re: Red Hat is moving from / to /usr/

08.12.2011 13:40, Goswin von Brederlow пишет: Igor Pashev writes: 07.12.2011 04:43, Marco d'Itri пишет: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=12a362be5c1982f80dbfb75bda070208a2c99cdf Discuss. I don't see any reason to move all into /usr from /, and make initr

Bug#651416: ITP: glyr -- search engine for music-related metadata

Package: wnpp Severity: wishlist Owner: Etienne Millon * Package name: glyr Version : 0~git20111205 Upstream Author : Christopher Pahl * URL : https://github.com/sahib/glyr * License : GPL-3+ Programming Lang: C Description : search engine library for

Re: Red Hat is moving from / to /usr/

On Thu, 08 Dec 2011 at 11:06:46 +0100, Stephan Seitz wrote: > That depends. I have some systems where all file systems except > /boot are encrypted. Since I don’t use Debian kernels and initramfs, > I created a small one myself to ask for the /-partition password. > Now I would have to put the whol

Re: Getting dh_install to do what we need

08.12.2011 13:49, Goswin von Brederlow пишет: Arno Töll writes: Your own script-fu in debian/rules or external scripts isn't exactly the next best thing to read and learn how a foreign package works and there /are/ use cases where dh_install isn't flexible enough to deal with the problem by u

Re: ecofont

On Thu, Dec 08, 2011 at 09:36:36AM +, 810d4rk wrote: > The font can be downloaded in the website after you enter an email and > name in a box. > There is currently a discussion in libreoffice devel mailing list > about this type of font and there is also a discussion about the > license: > htt

Re: Getting dh_install to do what we need

Jon Dowland writes: > On Thu, Dec 08, 2011 at 08:14:52AM +0100, Gergely Nagy wrote: >> I disagree. Look at dpatch. It had executable patches since the >> beginning, and a standardised script from 2.0 onwards. > > One problem with executable patches was the fact you couldn't reason > about the pac

Re: ecofont

Please do not top-post: http://catb.org/jargon/html/T/top-post.html On Thu, Dec 08, 2011 at 09:36:36AM +, 810d4rk wrote: > There is currently a discussion in libreoffice devel mailing list > about this type of font and there is also a discussion about the > license: > http://lists.freedesktop

Re: Getting dh_install to do what we need

On Thu, Dec 08, 2011 at 08:14:52AM +0100, Gergely Nagy wrote: > I disagree. Look at dpatch. It had executable patches since the > beginning, and a standardised script from 2.0 onwards. One problem with executable patches was the fact you couldn't reason about the packaging without first executing

Re: Getting dh_install to do what we need

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On 08.12.2011 10:44, Goswin von Brederlow wrote: > Or for the more general case: > > override_dh_auto_install: > debian/libfoo.my-install-script [..] > This new feature stinks of black-box magic that will make people crazy > trying to fin

Re: Red Hat is moving from / to /usr/

On Thu, Dec 08, 2011 at 10:25:07AM +0100, Goswin von Brederlow wrote: I guess mounting /usr is no more complicated than mounting / in initramfs. Finding out what modules and software is needed for that should be the same code as for /. That depends. I have some systems where all file systems ex

Re: Getting dh_install to do what we need

Goswin von Brederlow writes: > Arno Töll writes: > >> Your own script-fu in debian/rules or external scripts isn't exactly the >> next best thing to read and learn how a foreign package works and there >> /are/ use cases where dh_install isn't flexible enough to deal with the >> problem by usin

Re: ecofont

The font can be downloaded in the website after you enter an email and name in a box. There is currently a discussion in libreoffice devel mailing list about this type of font and there is also a discussion about the license: http://lists.freedesktop.org/archives/libreoffice/2011-December/date.htm

Re: Getting dh_install to do what we need

Arno Töll writes: > Your own script-fu in debian/rules or external scripts isn't exactly the > next best thing to read and learn how a foreign package works and there > /are/ use cases where dh_install isn't flexible enough to deal with the > problem by using the possibilities you had before. Re

Re: Getting dh_install to do what we need

Don Armstrong writes: > On Wed, 07 Dec 2011, Josselin Mouette wrote: >> So, to sum it up. Before, you would do in debian/rules: >> sed s/@DEB_HOST_MULTIARCH@/${DEB_HOST_MULTIARCH}/ >> debian/libfoo.install.in > debian/libfoo.install >> >> Now, you will do in debian/foo.install: >>

Re: Red Hat is moving from / to /usr/

Igor Pashev writes: > 07.12.2011 04:43, Marco d'Itri пишет: >> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=12a362be5c1982f80dbfb75bda070208a2c99cdf >> >> Discuss. >> > > I don't see any reason to move all into /usr from /, > and make initrd for minimal system: > > Making

Re: Red Hat is moving from / to /usr/

m...@linux.it (Marco d'Itri) writes: > On Dec 07, Goswin von Brederlow wrote: > >> Give everyone at least 10 years headstart to migrate existing systems >> away from having a seperate /usr partition and for people to stop making >> a seperate /usr on new installs. > Actually, Red Hat's goal *is*

Re: Red Hat is moving from / to /usr/

Philip Hands writes: > On Wed, 7 Dec 2011 09:00:35 +, Simon McVittie wrote: >> On Wed, 07 Dec 2011 at 01:43:34 +0100, Marco d'Itri wrote: >> > http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=12a362be5c1982f80dbfb75bda070208a2c99cdf >> > >> > Discuss. >> >> As far as I can ma

Re: Getting dh_install to do what we need

Mike Hommey writes: > Note you also need to add a chmod +x debian/*.sh in debian/rules, since > apart from debian/rules, nothing has the executable bit after > dpkg-source -x. I believe the 3.0 (quilt) format fixes this. -- Russ Allbery (r...@debian.org)

Re: Getting dh_install to do what we need

On Wed, Dec 07, 2011 at 11:47:49PM +0100, Josselin Mouette wrote: > For those who haven’t followed, the latest debhelper upload includes the > following change: > >* Debhelper config files may be made executable programs that output the > desired configuration. No further changes are plan