th.
passing my first try at that off to Anton as I'm
heading off to sea in a few minutes..
Hamish wrote:
>> aside: Anyone know the redistribution terms for
>> vcredist_x86.exe ?
>> MS's download site does not make it obvious and
>> I guess you have to actually in
orrect dir to use for 3rd party plugins is not obvious to the casual user.
* to put "dfsg" in the version number or not?
Hamish wrote:
>> You'll notice our source tarball is labeled dfsg. This is because
>> there were some included DLLs to help build the MS Windows
o use for 3rd party plugins is not obvious to the casual user.
* to put "dfsg" in the version number or not?
Hamish wrote:
>> You'll notice our source tarball is labeled dfsg. This is because
>> there were some included DLLs to help build the MS Windows
>> version o
gz
version number having to match the final binary package number.
Is there a work around? Does there have to be? (I mean do the
debian buildbots care if the source.orig.tar.gz version exactly
matches?) I am using debuild and don't experience the problem
myself..
thanks,
Hamish
--
To
pencpn_plugins is being
> created.
I will investigate and fix that today.
(I thought I had already taken care of that, maybe I missed
something or the new beta changes in a way I didn't expect)
Also I need to double check the dispersion of the provided docs
after the upstream path change th
ler than 16 in
libGARMINHOST.a(gpsapp.c.o)
?
> > valgrind analysis:
--volunteers welcome.
> > Your Standards-Version is out of date,
--todo.
> > A lot of the source code contains CVS $Id lines
--further cleaned out in the lastest push.
thanks,
Hamish
--
To UNSUBSCRIB
oad will run lintian, nor that lintian knows about the
> specific embedded code copies you are using. Think of it as an
> additional safety net.
This possibility is not something which would keep me awake at
night, but no harm in it, so will do.
Hamish:
> > ok, sid's lintian now rep
Hamish:
> > I've no answer, but I notice that `apt-file search
> > paypal` turns up a handful of other debian packages in the
> > same boat, for good or bad.
> >
> > If it is deemed to be copyright/trademark problematic,
> > there should be no trouble goi
ightly suspect. I'd like to know its lineage,
> > > copyright and license. Same for macutils.c
> [+]
> > > sercomm.cpp macsercomm.h macutils.h
> > > sercomm.h
>
> Hamish replied:
> > src/about.cpp lists seriallib as being GPL.
> > We can reque
package: source version 2.4.612-1
[...]
---
["origin: vendor"??]
which one to keep and which one to drop?
if dpkg-buildpackage's is to be dropped, how would one accomplish
that in the rules file?
thanks,
Hamish
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debia
[several issues mentioned in yesterday's summary have now been
fixed upstream, more on that soon]
Paul wrote:
> > What is the license for src/bitmaps/paypal_donate.xpm?
Hamish:
> -> TODO
> I don't know, but we need to find out as a priority.
I've no answer, but
know its lineage,
> > copyright and license. Same for macutils.c
[+]
> > sercomm.cpp macsercomm.h macutils.h
> > sercomm.h
Hamish replied:
> src/about.cpp lists seriallib as being GPL.
> We can request better header comments.
requested, waiting.
http://www.opencpn.org/f
th the code. It is expected that more
will come along (see the opencpn download page for some works in
progress), and when that happens we will most likely split them out
into their own binary package. But for now it's not worth the effort.
As for src/mygdal and src/myiso8211, GDAL does supply nic
package which allows backdrop
tile servers from a number of (AFAIK) clean sources.
regards,
Hamish
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/476378.33703...@web110001.mail.gq1.yahoo.com
tained package.
For example the Makefile.{am,in} COPYING change: this is purely
cosmetic. I disagree that your solution is the best; maintaining patches
to upstream sources is a nuisance, while fixing things up afterwards in
debian/rules is easier.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROT
ng of your package description for cogito,
the name GIT (the version control system) doesn't seem to
mean anything in particular. So renaming it would not be a big loss.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
It might get us an initial package of some
new software, but will it get us a package that is continually and well
maintained?
We already have hundreds (if not thousands) of poor quality packages;
I don't think we need new technology to churn these out.
Hamish
--
Hamish Moffatt VK3SB <
e
> dependencies or other complications.
I think libstroke is fairly straightforward.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
e
> dependencies or other complications.
I think libstroke is fairly straightforward.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Mon, Oct 21, 2002 at 04:41:01PM +0200, Oliver Kurth wrote:
> On Tue, Oct 22, 2002 at 12:08:01AM +1000, Hamish Moffatt wrote:
> > I want to move some conffiles from one directory to another in a package
> > upgrade. Can I simply move it in the preinst? I suppose I will possi
On Mon, Oct 21, 2002 at 04:41:01PM +0200, Oliver Kurth wrote:
> On Tue, Oct 22, 2002 at 12:08:01AM +1000, Hamish Moffatt wrote:
> > I want to move some conffiles from one directory to another in a package
> > upgrade. Can I simply move it in the preinst? I suppose I will possi
Hi,
I want to move some conffiles from one directory to another in a package
upgrade. Can I simply move it in the preinst? I suppose I will possibly
have to create the target directory too unless I pre-depend on the
package which would own it (not desirable).
Thanks
Hamish
--
Hamish Moffatt
ur package would be better described as a "spelling-checker
add-on" rather than a "spell-checking addon", unless it really checks
spells. Also, addon isn't a word.
Regards
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To U
/usr/share/doc/tkxcd/examples.
I think dh_compress will take care of compressing the man page, so
you don't need to do that yourself.
You should install the upstream HISTORY file as the changelog,
using "dh_installchangelogs HISTORY".
As Ben mentioned, the menu entry isn'
o in /usr/share/doc/tkxcd/examples.
I think dh_compress will take care of compressing the man page, so
you don't need to do that yourself.
You should install the upstream HISTORY file as the changelog,
using "dh_installchangelogs HISTORY".
As Ben mentioned, the menu entry isn'
em I used to build the package.
> Is there a way to tell dh_shlibdeps to ignore a given lib (e.g. tcl and
> tk) so that I could give the dependency manually ?
You could remove ${shlib:Depends} from the control file?
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTE
system I used to build the package.
> Is there a way to tell dh_shlibdeps to ignore a given lib (e.g. tcl and
> tk) so that I could give the dependency manually ?
You could remove ${shlib:Depends} from the control file?
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTE
> right to ITA the package? (It's a very small, non-essential package.)
> If not, what should I do?
Could you find someone who is willing to sponsor you before officially
adopting the package?
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
all
> right to ITA the package? (It's a very small, non-essential package.)
> If not, what should I do?
Could you find someone who is willing to sponsor you before officially
adopting the package?
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
of
> paths for all binaries. (This filtering is not done on RPATH
> currently. That feature won't be necessary until libc actually
> changes major version.)
OK, I see. As long as no binaries have hard-coded paths (RPATH)
to libc, why would ldconfig need to change?
Hamish
--
ing of
> paths for all binaries. (This filtering is not done on RPATH
> currently. That feature won't be necessary until libc actually
> changes major version.)
OK, I see. As long as no binaries have hard-coded paths (RPATH)
to libc, why would ldconfig need to change?
Hamish
--
the above excerpt correctly, ldconfig would need to be
> extended to know about "libc7", but then it'd work.
I don't see how ldconfig enters into it in this case.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
the above excerpt correctly, ldconfig would need to be
> extended to know about "libc7", but then it'd work.
I don't see how ldconfig enters into it in this case.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, ema
to install into /usr/lib/
>
> Is that right?
Yes. Binaries which users/administrators won't run directly should
go into /usr/lib/, anything that will be run directly should
go in /usr/(s)bin.
regards,
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
.so.conf?
If your binary contains a hard path to /lib/libc.so.6, and then we
move that library to /usr/i386-glibc2-linux/lib instead because
libc.so.7 is available, your binary will no longer work.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
to install into /usr/lib/
>
> Is that right?
Yes. Binaries which users/administrators won't run directly should
go into /usr/lib/, anything that will be run directly should
go in /usr/(s)bin.
regards,
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
.so.conf?
If your binary contains a hard path to /lib/libc.so.6, and then we
move that library to /usr/i386-glibc2-linux/lib instead because
libc.so.7 is available, your binary will no longer work.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
ackage closed it.
Admittedly, the bug (in the xawtv package) was fixed, but the
overall problem was not.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
ackage closed it.
Admittedly, the bug (in the xawtv package) was fixed, but the
overall problem was not.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Wed, Jan 16, 2002 at 07:15:13PM +0900, Oohara Yuuma wrote:
> I want to adopt osh (#89433), but I am not a Debian developer.
> Is it OK just to change the title of the wnpp bug and find a sponsor?
> (I am in the NM queue.)
Please find a sponsor first. Thanks.
This is my opinion only
On Wed, Jan 16, 2002 at 07:15:13PM +0900, Oohara Yuuma wrote:
> I want to adopt osh (#89433), but I am not a Debian developer.
> Is it OK just to change the title of the wnpp bug and find a sponsor?
> (I am in the NM queue.)
Please find a sponsor first. Thanks.
This is my opinion only
"/'
mv libtool-2 libtool
chmod 755 libtool
make
touch build-stamp
I thought I heard that modern libtool didn't do this any more.
Maybe you can run libtoolize on the sources and solve the
problem that way.
This patch also makes a shared librar
ibs"/'
mv libtool-2 libtool
chmod 755 libtool
make
touch build-stamp
I thought I heard that modern libtool didn't do this any more.
Maybe you can run libtoolize on the sources and solve the
problem that way.
This patch also makes a shared librar
/rules
ie it will be not be executable after the patch is applied. It has
to be changed by the build process (debuild does it and the autobuilders
must too; dpkg-buildpackage bombs out instead).
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
/rules
ie it will be not be executable after the patch is applied. It has
to be changed by the build process (debuild does it and the autobuilders
must too; dpkg-buildpackage bombs out instead).
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSC
On Fri, Dec 28, 2001 at 02:29:05PM +0100, Robert Bihlmeyer wrote:
> Hamish Moffatt <[EMAIL PROTECTED]> writes:
> > I heard it was a bug in apt-get; it needs "A | B" as it can't
> > select something itself to provide B. dpkg itself is fine.
>
> apt should
On Fri, Dec 28, 2001 at 02:29:05PM +0100, Robert Bihlmeyer wrote:
> Hamish Moffatt <[EMAIL PROTECTED]> writes:
> > I heard it was a bug in apt-get; it needs "A | B" as it can't
> > select something itself to provide B. dpkg itself is fine.
>
> apt should
>
> I will read up on this, but i think it is a bug in dpkg behavior.
I heard it was a bug in apt-get; it needs "A | B" as it can't
select something itself to provide B. dpkg itself is fine.
> and will this work when A is not installed, but another package providing B ?
Yes, A | B is "A or B".
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
>
> I will read up on this, but i think it is a bug in dpkg behavior.
I heard it was a bug in apt-get; it needs "A | B" as it can't
select something itself to provide B. dpkg itself is fine.
> and will this work when A is not installed, but another package providing B ?
On Thu, Dec 13, 2001 at 04:20:52PM +0100, A Mennucc1 wrote:
> may someone give a look?
>
> #include
You should be #including instead of ;
try that.
Please use your real name when posting to debian lists.
It is common courtesy.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECT
On Thu, Dec 13, 2001 at 04:20:52PM +0100, A Mennucc1 wrote:
> may someone give a look?
>
> #include
You should be #including instead of ;
try that.
Please use your real name when posting to debian lists.
It is common courtesy.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECT
On Mon, Nov 05, 2001 at 12:30:15AM +0100, Eric Van Buggenhaut wrote:
> OTOH, please fix your mail client, I received your message 3 (!) times.
Suggest you fix yours.. I only saw one copy here, and twice today
I've seen you tell people you received multiple copies of their message.
cheer
g is pretty standard. Anybody can upload anybody's
public key.
For Debian, you can email [EMAIL PROTECTED] I think, but
uploading is the preferred option.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
uploading is pretty standard. Anybody can upload anybody's
public key.
For Debian, you can email [EMAIL PROTECTED] I think, but
uploading is the preferred option.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
wit
version to close the ITP bug though,
as you can just mail [EMAIL PROTECTED] and say why it's
being closed.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
this I will be most glad to accept any help.
I tried to build your package to check this out, but make (or is it
gendep?) segfaults! But only when using gcc/g++ 3.0. Very strange.
Maybe the bug is in gendep instead.
make[1]: Entering directory `/local/home/hamish/tmp/texmacs-0.3.4.6/gencc
On Fri, Oct 12, 2001 at 05:19:11PM +0200, Eduard Bloch wrote:
> Hamish Moffatt wrote on Fri Oct 12, 2001 um 10:34:06PM:
> > Diversions (dpkg-divert) would be appropriate in this case.
>
> OTOH only one package can apply diversion on a file, this would not work
> with multi
version to close the ITP bug though,
as you can just mail [EMAIL PROTECTED] and say why it's
being closed.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
this I will be most glad to accept any help.
I tried to build your package to check this out, but make (or is it
gendep?) segfaults! But only when using gcc/g++ 3.0. Very strange.
Maybe the bug is in gendep instead.
make[1]: Entering directory `/local/home/hamish/tmp/texmacs-0.3.4.6/gencc
On Fri, Oct 12, 2001 at 05:19:11PM +0200, Eduard Bloch wrote:
> Hamish Moffatt wrote on Fri Oct 12, 2001 um 10:34:06PM:
> > Diversions (dpkg-divert) would be appropriate in this case.
>
> OTOH only one package can apply diversion on a file, this would not work
> with multi
ivert another's files. However, all packages must
agree to use alternatives to manage a particular file.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
ivert another's files. However, all packages must
agree to use alternatives to manage a particular file.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Tue, Oct 09, 2001 at 08:40:29PM +0100, Colin Watson wrote:
> However, I can see we aren't going to get anywhere with argument by
> repeated assertion. :)
Do we need to take this to debian-devel, and find out what the
dpkg developers (Wichert, Adam etc) intended with the new fiel
On Tue, Oct 09, 2001 at 08:40:29PM +0100, Colin Watson wrote:
> However, I can see we aren't going to get anywhere with argument by
> repeated assertion. :)
Do we need to take this to debian-devel, and find out what the
dpkg developers (Wichert, Adam etc) intended with the new fiel
Is the correct way to build a sponsored package with just
eg -m"Hamish Moffatt <[EMAIL PROTECTED]>" to dpkg-buildpackage
or debuild?
I get Changed-By: the sponsoree, and Maintainer: me in the
.changes file as a result. That seems backwards.
thanks
Hamish
--
Hamish Moffa
Is the correct way to build a sponsored package with just
eg -m"Hamish Moffatt <[EMAIL PROTECTED]>" to dpkg-buildpackage
or debuild?
I get Changed-By: the sponsoree, and Maintainer: me in the
.changes file as a result. That seems backwards.
thanks
Hamish
--
Hamish Moffa
ng later? It
has an extra level of subdirectory than is usual eg
rocketworkbench-1.0.20010807.orig/rocketworkbench/...
/usr/share/doc/rocketworkbench/README.txt only contains build
instructions; are they useful to the end user of the package?
I haven't sponsored anyone before but I can i
aring later? It
has an extra level of subdirectory than is usual eg
rocketworkbench-1.0.20010807.orig/rocketworkbench/...
/usr/share/doc/rocketworkbench/README.txt only contains build
instructions; are they useful to the end user of the package?
I haven't sponsored anyone before but I can i
ple "this is a dead
> package, we won't help you, go find something else".
>
> If this abuse continues, I might just exercise my ability to disable the
> close command in the control bot one day...
Do it. There's not much reason to use the close command, when
you c
ried this last week, and katie told me some md5sums were wrong in
the changes file. I don't know which one; I uploaded both builds
separately instead.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
u tell people "this is a dead
> package, we won't help you, go find something else".
>
> If this abuse continues, I might just exercise my ability to disable the
> close command in the control bot one day...
Do it. There's not much reason to use the close command, when
you c
ried this last week, and katie told me some md5sums were wrong in
the changes file. I don't know which one; I uploaded both builds
separately instead.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
On Mon, Aug 20, 2001 at 03:14:57PM +0200, Stefano Zacchiroli wrote:
> On Mon, Aug 20, 2001 at 09:22:38PM +1000, Hamish Moffatt wrote:
> > Why do you need to remove them? As long as they are not installed
> > into the binary package it is not a problem.
>
> right! but thes
On Mon, Aug 20, 2001 at 03:14:57PM +0200, Stefano Zacchiroli wrote:
> On Mon, Aug 20, 2001 at 09:22:38PM +1000, Hamish Moffatt wrote:
> > Why do you need to remove them? As long as they are not installed
> > into the binary package it is not a problem.
>
> right! but thes
as they are not installed
into the binary package it is not a problem.
regards,
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
as they are not installed
into the binary package it is not a problem.
regards,
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
packages.
But I don't see how you can make this conditional on idle
being installed previously. The above will force idle-python1.5
to be installed.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
On Sat, Jul 28, 2001 at 02:18:41PM +0100, Will Newton wrote:
> On Saturday 28 July 2001 5:24 am, Hamish Moffatt wrote:
>
> > It doesn't look right. Your two packages (otcl1 and otcl-dev) can't
> > share the same tmpdir.
>
> Erm, why not? Surely the job of dh_mov
On Sat, Jul 28, 2001 at 02:18:41PM +0100, Will Newton wrote:
> On Saturday 28 July 2001 5:24 am, Hamish Moffatt wrote:
>
> > It doesn't look right. Your two packages (otcl1 and otcl-dev) can't
> > share the same tmpdir.
>
> Erm, why not? Surely the job of dh
l -d debian/tmp
> $(MAKE) install DESTDIR=`pwd`/debian/tmp
>
> Is this right or just lucky?
It doesn't look right. Your two packages (otcl1 and otcl-dev) can't
share the same tmpdir.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
l -d debian/tmp
> $(MAKE) install DESTDIR=`pwd`/debian/tmp
>
> Is this right or just lucky?
It doesn't look right. Your two packages (otcl1 and otcl-dev) can't
share the same tmpdir.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
some sort of protective environment which
means it can't do much damage.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
some sort of protective environment which
means it can't do much damage.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cros that
the macros may be viruses. Outlook could look for attachments which
have executable extensions and do the same thing.
Or maybe MS could get out of the habit of hiding file extensions.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
cros that
the macros may be viruses. Outlook could look for attachments which
have executable extensions and do the same thing.
Or maybe MS could get out of the habit of hiding file extensions.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSCRIB
oc.com.
Would you think MS would release an Outlook update that would address this
in some way? It's not exactly a new trick.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
oc.com.
Would you think MS would release an Outlook update that would address this
in some way? It's not exactly a new trick.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
hey're coming
from two different people.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
hey're coming
from two different people.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ion. However, no changes are made on disk.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
ion. However, no changes are made on disk.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
However since I have no idea what any of
these tools do I didn't get very far.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
f. However since I have no idea what any of
these tools do I didn't get very far.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
d and section: base. Is it
necessary for packages to declare an explicit dependency in that
case?
Admittedly, it's not essential: yes. Nor is libc6.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
d and section: base. Is it
necessary for packages to declare an explicit dependency in that
case?
Admittedly, it's not essential: yes. Nor is libc6.
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
On Wed, May 02, 2001 at 10:50:16PM -0400, Joey Hess wrote:
> Hamish Moffatt wrote:
> > Now it's just an annoyance. Only the binary target needs root access.
>
> Not quite. The clean target still should run as root unless you're building
> with fakeroot. For a variety
On Wed, May 02, 2001 at 10:50:16PM -0400, Joey Hess wrote:
> Hamish Moffatt wrote:
> > Now it's just an annoyance. Only the binary target needs root access.
>
> Not quite. The clean target still should run as root unless you're building
> with fakeroot. For a variety
was standard practise before we had fakeroot.
I suppose when you were building as root (non-fake), you would end up
with directories owned by root, so it made sense that you would need
root access to clean up as well.
Now it's just an annoyance. Only the binary target needs root access.
Hamish
-
was standard practise before we had fakeroot.
I suppose when you were building as root (non-fake), you would end up
with directories owned by root, so it made sense that you would need
root access to clean up as well.
Now it's just an annoyance. Only the binary target needs root access.
Hamish
-
On Fri, Apr 20, 2001 at 01:03:09PM +0300, Eray Ozkural (exa) wrote:
> Hamish Moffatt wrote:
> > No, just go ahead and change it. An upload is considered an NMU
> > if the name in the changelog entry does not match the Maintainer
> > field in the control file. As long as you ch
1 - 100 of 305 matches
Mail list logo
