Building on arm.
Hi, I have packaged a program, vcdimager. It doesn't build on arm because it uses bitfields, and gcc on arm doesn't seem to pack bitfields. I tried to use -mno-bit-align to force it, but the option is not recognised by gcc on arm. Is there a way to get around this ? The ideal way would be to get rid of the bitfields altogether, but that would take a non-trivial amount of work, and is on the TODO list. Is it possible to make the package available only for specific arches, such as i386, alpha, powerpc etc. and not arm. Whether this is right or not is by itself another issue. What would be the right thing to do ? Thanks, viral Please cc: me replies posted to debian-devel. I do read debian-mentors however. -- You are young and life is long and there is time to kill today. pgpHHqwSvEMqS.pgp Description: PGP signature
[no subject]
Hey there, I found a great retail site with all kinds of products. Home decor, office decor, travel, outdoors, kitchen, etc... Take a look around at http://www.merchandisewholesale.com just click on the images of the product to enlarge it for a better view. Sincerely, John
Re: dpkg tries to remove a config file twice ...
On Mon, May 21, 2001 at 08:10:59PM +0200, Robert Bihlmeyer wrote: > Ben Collins <[EMAIL PROTECTED]> writes: > > > Change it to "rm -f ...". That way, you wont get an error. You should do > > it this way anyway, else your package becomes uninstallable if the user > > removes the file before removing the package. Everyone is in agreement that "rm -f" is the correct procedure, for the reason stated above. But I'm still curious about the cause of the initial question: why does the file get removed twice? -S -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants
Does debhelper handle build-indep ?
Hello, I have a multi-binary package which produce arch-dependant .deb (binaries) and arch-independant (documentation). I would like debian/rules binary-indep create the arch-independant package and debian/rules binary-arch create the arch dependant package Does the policy requires this ? (I read it but it was unclear (to me:)) My debian/rules file is based on dh_make and look like this: # Build architecture-independent files here. binary-indep: build install # We have nothing to do by default. # Build architecture-dependent files here. binary-arch: build install ... dh_gencontrol dh_md5sums dh_builddeb binary: binary-indep binary-arch So everything is done in build-arch. I look at the doc of debhelper and does not find comment about this. Thanks for your help! Bill.(please CC)
Re: Does debhelper handle build-indep ?
Bill Allombert <[EMAIL PROTECTED]> wrote:
>I have a multi-binary package which produce arch-dependant .deb (binaries)
>and arch-independant (documentation).
>
>I would like
>debian/rules binary-indep
>create the arch-independant package
>and
>debian/rules binary-arch
>create the arch dependant package
>
>Does the policy requires this ? (I read it but it was unclear (to me:))
Yes, in section 5.2 (`debian/rules' - the main building script):
`binary-arch' builds the binary packages which are specific to a
particular architecture, and `binary-indep' builds those which are
not.
>My debian/rules file is based on dh_make and look like this:
>
># Build architecture-independent files here.
>binary-indep: build install
># We have nothing to do by default.
>
># Build architecture-dependent files here.
>binary-arch: build install
>...
>dh_gencontrol
>dh_md5sums
>dh_builddeb
>
>binary: binary-indep binary-arch
>
>So everything is done in build-arch.
>
>I look at the doc of debhelper and does not find comment about this.
If you're already using dh_make-generated stuff, try
/usr/share/debhelper/dh_make/debianm/rules for an example. It passes -a
and -i to various debhelper commands to work on architecture-dependent
and -independent binary packages respectively. Aside from that you need
to have the appropriate Architecture: lines in debian/control ('any' for
arch-dependent, 'all' for arch-independent).
--
Colin Watson [EMAIL PROTECTED]
What to do about old package left over from move to non-US?
Hi all. I have moved my package althea to non-US because it now supports SSL. The old package, version 0.4.4a, is still in main. Once the new version is installed into non-US, should I file a bug (what severity?) against ftp.debian.org requesting the old version's removal? Or, should I keep it around until security problems are found in it so that those people who don't use non-US will see my package? I should mention, the package soon to be in non-US can easily be compiled without SSL with a simple and short Makefile change which I have documented in README.Debian and referred to in the package description, so it is of use to people who can't use non-US. - Jimmy Kaplowitz [EMAIL PROTECTED] / [EMAIL PROTECTED] P. S. - although I am subscribed to the list, please cc me so that the message shows up in my main box, not only my -mentors box.
Re: 2 packages sharing the same config file.
On Mon, May 21, 2001 at 03:55:42PM +0200, Robert Bihlmeyer wrote: > Domenico Andreoli <[EMAIL PROTECTED]> writes: > > > maybe using an abacus-common package which owns that conffile... > > > > my question now is, is a file worth of a package on its own?!? > > Nope. Why not just leave the packages conflicting until someone with a > real need to have both installed stands up? Well :-) This is the message I got from A. Bunk who handed me the package : >It's your package. One thing you could do when you start working on it is >to remove the conflict between xabacus and xmabacus - there are better >solutions in Debian when two packages share the same file. > >cu >Adrian I'm just looking for the 'better solutions' he mentions but still clueless. Any hint ? -- Eric VAN BUGGENHAUT [EMAIL PROTECTED]
Re: What to do about old package left over from move to non-US?
On Tue, May 22, 2001 at 07:48:44PM -0400, Jimmy Kaplowitz wrote: > Hi all. I have moved my package althea to non-US because it now supports SSL. > The old package, version 0.4.4a, is still in main. Once the new version is > installed into non-US, should I file a bug (what severity?) against > ftp.debian.org requesting the old version's removal? Or, should I keep it > around until security problems are found in it so that those people who don't > use non-US will see my package? I should mention, the package soon to be in > non-US can easily be compiled without SSL with a simple and short Makefile > change which I have documented in README.Debian and referred to in the package > description, so it is of use to people who can't use non-US. Hi Jimmy, If you want it in non-US, then file a bug against ftp.debian.org requesting its removal, however I would recommend splitting the package into althea (no crpyto, in ftp.debian.org), and althea-ssl (crypto, in non-US), or althea (with crypto, non-US), and althea-nossl (no crypto, in ftp.debian.org), with that simple Makefile change you suggested. :) d -- Daniel Stone<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
No Subject
Hey there, I found a great retail site with all kinds of products. Home decor, office decor, travel, outdoors, kitchen, etc... Take a look around at http://www.merchandisewholesale.com just click on the images of the product to enlarge it for a better view. Sincerely, John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg tries to remove a config file twice ...
On Mon, May 21, 2001 at 08:10:59PM +0200, Robert Bihlmeyer wrote: > Ben Collins <[EMAIL PROTECTED]> writes: > > > Change it to "rm -f ...". That way, you wont get an error. You should do > > it this way anyway, else your package becomes uninstallable if the user > > removes the file before removing the package. Everyone is in agreement that "rm -f" is the correct procedure, for the reason stated above. But I'm still curious about the cause of the initial question: why does the file get removed twice? -S -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Does debhelper handle build-indep ?
Hello, I have a multi-binary package which produce arch-dependant .deb (binaries) and arch-independant (documentation). I would like debian/rules binary-indep create the arch-independant package and debian/rules binary-arch create the arch dependant package Does the policy requires this ? (I read it but it was unclear (to me:)) My debian/rules file is based on dh_make and look like this: # Build architecture-independent files here. binary-indep: build install # We have nothing to do by default. # Build architecture-dependent files here. binary-arch: build install ... dh_gencontrol dh_md5sums dh_builddeb binary: binary-indep binary-arch So everything is done in build-arch. I look at the doc of debhelper and does not find comment about this. Thanks for your help! Bill.(please CC) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Does debhelper handle build-indep ?
Bill Allombert <[EMAIL PROTECTED]> wrote:
>I have a multi-binary package which produce arch-dependant .deb (binaries)
>and arch-independant (documentation).
>
>I would like
>debian/rules binary-indep
>create the arch-independant package
>and
>debian/rules binary-arch
>create the arch dependant package
>
>Does the policy requires this ? (I read it but it was unclear (to me:))
Yes, in section 5.2 (`debian/rules' - the main building script):
`binary-arch' builds the binary packages which are specific to a
particular architecture, and `binary-indep' builds those which are
not.
>My debian/rules file is based on dh_make and look like this:
>
># Build architecture-independent files here.
>binary-indep: build install
># We have nothing to do by default.
>
># Build architecture-dependent files here.
>binary-arch: build install
>...
>dh_gencontrol
>dh_md5sums
>dh_builddeb
>
>binary: binary-indep binary-arch
>
>So everything is done in build-arch.
>
>I look at the doc of debhelper and does not find comment about this.
If you're already using dh_make-generated stuff, try
/usr/share/debhelper/dh_make/debianm/rules for an example. It passes -a
and -i to various debhelper commands to work on architecture-dependent
and -independent binary packages respectively. Aside from that you need
to have the appropriate Architecture: lines in debian/control ('any' for
arch-dependent, 'all' for arch-independent).
--
Colin Watson [[EMAIL PROTECTED]]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
What to do about old package left over from move to non-US?
Hi all. I have moved my package althea to non-US because it now supports SSL. The old package, version 0.4.4a, is still in main. Once the new version is installed into non-US, should I file a bug (what severity?) against ftp.debian.org requesting the old version's removal? Or, should I keep it around until security problems are found in it so that those people who don't use non-US will see my package? I should mention, the package soon to be in non-US can easily be compiled without SSL with a simple and short Makefile change which I have documented in README.Debian and referred to in the package description, so it is of use to people who can't use non-US. - Jimmy Kaplowitz [EMAIL PROTECTED] / [EMAIL PROTECTED] P. S. - although I am subscribed to the list, please cc me so that the message shows up in my main box, not only my -mentors box. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2 packages sharing the same config file.
On Mon, May 21, 2001 at 03:55:42PM +0200, Robert Bihlmeyer wrote: > Domenico Andreoli <[EMAIL PROTECTED]> writes: > > > maybe using an abacus-common package which owns that conffile... > > > > my question now is, is a file worth of a package on its own?!? > > Nope. Why not just leave the packages conflicting until someone with a > real need to have both installed stands up? Well :-) This is the message I got from A. Bunk who handed me the package : >It's your package. One thing you could do when you start working on it is >to remove the conflict between xabacus and xmabacus - there are better >solutions in Debian when two packages share the same file. > >cu >Adrian I'm just looking for the 'better solutions' he mentions but still clueless. Any hint ? -- Eric VAN BUGGENHAUT [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What to do about old package left over from move to non-US?
On Tue, May 22, 2001 at 07:48:44PM -0400, Jimmy Kaplowitz wrote: > Hi all. I have moved my package althea to non-US because it now supports SSL. > The old package, version 0.4.4a, is still in main. Once the new version is > installed into non-US, should I file a bug (what severity?) against > ftp.debian.org requesting the old version's removal? Or, should I keep it > around until security problems are found in it so that those people who don't > use non-US will see my package? I should mention, the package soon to be in > non-US can easily be compiled without SSL with a simple and short Makefile > change which I have documented in README.Debian and referred to in the package > description, so it is of use to people who can't use non-US. Hi Jimmy, If you want it in non-US, then file a bug against ftp.debian.org requesting its removal, however I would recommend splitting the package into althea (no crpyto, in ftp.debian.org), and althea-ssl (crypto, in non-US), or althea (with crypto, non-US), and althea-nossl (no crypto, in ftp.debian.org), with that simple Makefile change you suggested. :) d -- Daniel Stone<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2 packages sharing the same config file.
On Wed, May 23, 2001 at 03:06:26AM +0200, Eric Van Buggenhaut wrote: > This is the message I got from A. Bunk who handed me the package : > > >It's your package. One thing you could do when you start working on it is > >to remove the conflict between xabacus and xmabacus - there are better > >solutions in Debian when two packages share the same file. > > > >cu > >Adrian > > I'm just looking for the 'better solutions' he mentions but still clueless. Any > hint ? > I don't know the details here, but can't you just modify the package to use seperate config files for each binary so they no longer conflict? The only other thing I can think of is to put the common files in one package and have the other dependant on it... That might not be a good solution though. Just wanted to throw that out for comment... -- Brett -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dh_installinit and dh_installkpatches questions.
Hi, I am packaging mosix, which is a cluster computing tool which does fault tolerance, load balancing and process migration. It comes as 2 kernel patches. One is a standard kernel patch which I handle with dh_installkpatches. The other is a tar file, which has to be untarred in /usr/src/linux. Can I handle this too with dh_installkpatches ? How otherwise would be a good way to do it ? Currently, I just have a note in README.Debian to do it manually. Also, with dh_installinit, the init.d script gets a default priority of 20. How do I change it ? I tried dh_installinit -- defaults s90 k10 It makes the debs fine, but during installation, update-rc.d grumbles of bad parameters. Am I using the wrong syntax ? I'm using debhelper 3.0.19. Thanks, viral -- You are young and life is long and there is time to kill today. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
