r. I haven't really been giving it the
attention it deserves (*blush*).
If you need a sponsor, I'd be happy to oblidge.
--
Itai Zukerman <http://www.math-hat.com/~zukerman/>
r. I haven't really been giving it the
attention it deserves (*blush*).
If you need a sponsor, I'd be happy to oblidge.
--
Itai Zukerman <http://www.math-hat.com/~zukerman/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Je Thu, 31 May 2001 11:54:09 -0400,
[EMAIL PROTECTED] (Jason Lunz) scribis:
> >> # Automatically added by dh_installinit
> >> if [ -e "/etc/init.d/pure-ftpd" ]; then
> >> update-rc.d pure-ftpd defaults >/dev/null
> >> /etc/init.d/pure-ftpd start
> >>
Je Thu, 31 May 2001 11:54:09 -0400,
[EMAIL PROTECTED] (Jason Lunz) scribis:
> >> # Automatically added by dh_installinit
> >> if [ -e "/etc/init.d/pure-ftpd" ]; then
> >> update-rc.d pure-ftpd defaults >/dev/null
> >> /etc/init.d/pure-ftpd start
> >>
Je Mon, 28 May 2001 14:03:14 -0400,
Joey Hess <[EMAIL PROTECTED]> scribis:
> When possible, packages should use the config script, and only the
> config script to interact with the user, since using debconf to ask
> questions in other scripts will result in the install pausing in the
> middle to as
Je Mon, 28 May 2001 14:03:14 -0400,
Joey Hess <[EMAIL PROTECTED]> scribis:
> When possible, packages should use the config script, and only the
> config script to interact with the user, since using debconf to ask
> questions in other scripts will result in the install pausing in the
> middle to a
Je Sun, 27 May 2001 23:59:48 -0400,
"Christian T. Steigies" <[EMAIL PROTECTED]> scribis:
> Also I am confused by this section in the tutorial:
>
> The Config Script
> [...]
> Do not make your postinst use debconf to ask questions.
> ^^^
>
> Bu
Je Sun, 27 May 2001 23:59:48 -0400,
"Christian T. Steigies" <[EMAIL PROTECTED]> scribis:
> Also I am confused by this section in the tutorial:
>
> The Config Script
> [...]
> Do not make your postinst use debconf to ask questions.
> ^^^
>
> B
> The reason one might need to recompile might be that
> glibc2.1 had a bug which was fixed in 2.2. You don't want the package
> to be rebuilt on every other architecture, just because of that.
In that case, wouldn't you want to add an architecture-specific
build-depends on glibc2.2, so I don't a
> The reason one might need to recompile might be that
> glibc2.1 had a bug which was fixed in 2.2. You don't want the package
> to be rebuilt on every other architecture, just because of that.
In that case, wouldn't you want to add an architecture-specific
build-depends on glibc2.2, so I don't
> You fall between two chairs - as noted in 7.4.3:
>
> What if you are simply recompiling the package? In this case, the
> process is different for porters than it is for non-porters, as
> mentioned above. If you are not a porter and are doing an NMU
> that simply requires a reco
> You fall between two chairs - as noted in 7.4.3:
>
> What if you are simply recompiling the package? In this case, the
> process is different for porters than it is for non-porters, as
> mentioned above. If you are not a porter and are doing an NMU
> that simply requires a rec
I'm not sure if this was covered in the last round of ROM-talks, but:
If I have free source to a ROM image (GPL, say) for a free emulator,
but the tools to build the image are DFSG non-free, does the resulting
binary image need to go into non-free or contrib?
I'm guessing contrib, and then the em
I'm not sure if this was covered in the last round of ROM-talks, but:
If I have free source to a ROM image (GPL, say) for a free emulator,
but the tools to build the image are DFSG non-free, does the resulting
binary image need to go into non-free or contrib?
I'm guessing contrib, and then the e
> > Anybody should be able to build a package when its build-time dependencies
> > are satisfied and end up with the same result as anyone else. This is
> > a policy recommendation.
>
> But, if the user has something *extra* installed, that the configure script
> picks up and uses, because it is o
> > Anybody should be able to build a package when its build-time dependencies
> > are satisfied and end up with the same result as anyone else. This is
> > a policy recommendation.
>
> But, if the user has something *extra* installed, that the configure script
> picks up and uses, because it is
A few days ago I had to rebuild gimp1.1 from source to fix a little
bug that was stalling my work. I noticed that since I have LPRng
installed on my system, ./configure came up with different settings
than the gimp binary in the archive was compiled with (specifically,
lpstat support was enabled i
A few days ago I had to rebuild gimp1.1 from source to fix a little
bug that was stalling my work. I noticed that since I have LPRng
installed on my system, ./configure came up with different settings
than the gimp binary in the archive was compiled with (specifically,
lpstat support was enabled
I remember some time ago the proposed system was:
1. File an ITP bug against wnpp.
2. Upload the new package.
3. Reassign the bug to the new package.
4. Close the bug.
However, the instructions (and recent new uploads) seem to omit #3, I
guess because it's easier just to close the bug in the
I remember some time ago the proposed system was:
1. File an ITP bug against wnpp.
2. Upload the new package.
3. Reassign the bug to the new package.
4. Close the bug.
However, the instructions (and recent new uploads) seem to omit #3, I
guess because it's easier just to close the bug in the
> > 2. The source archive does not come with a Makefile, only a
> > Makefile.in; autoconf must be run before make.
>
> Unless you mean configure and configure.in, this is a non-issue.
Yikes! Yes, of course I meant configure and configure.in, and
"autoconf must be run before configure" inst
I've come across two source archives that I'd like to package, that
have these characteristics:
1. The source archive contains CVS subdirectories.
Should I remove these before building? Does it matter?
2. The source archive does not come with a Makefile, only a
Makefile.in; autoconf must
22 matches
Mail list logo
