On Sun, Mar 07, 2004 at 01:17:46PM +0100, Andreas Metzler wrote:
> On 2004-03-07 Colin Watson <[EMAIL PROTECTED]> wrote:
> > On Sun, Mar 07, 2004 at 11:23:40AM +0100, Andreas Metzler wrote:
> >> When jumping from 4.3 to 4.5 I'd like to rename pgrep to pcregrep and
>
e also tried something like this, but without
> any success.
Put a file in each chroot (in /etc, say) identifying it, and then read
it into a shell variable in .bashrc so that your prompt can use it.
--
Colin Watson [EMAIL PROTECTED]
ildpackage to force .orig.tar.gz to be
included in the .changes.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
still need to apply thought to the output.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
ck.debian.org",
login => $ENV{DEBUSER} || getlogin() || $ENV{USER} || $ENV{LOGNAME},
incoming => "~tfheen$delayed",
dinstall_runs => 1,
method => "scpb",
};
I then do 'DEB_NMU_DELAY=7 dupload --to tfheen-delayed foo.changes'.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
they're manually removed. I suggest making them empty packages (save for
a /usr/share/doc/foo symlink to /usr/share/doc/python-epydoc) that just
depend on python-epydoc, and then make python-epydoc Conflict/Replace
pythonX.Y-epydoc (<< whatever-the-first-empty-version-is).
--
Colin Watson [EMAIL PROTECTED]
that bug be release critical instead of important?
"Should" violations aren't release-critical. Also, it's not listed here:
http://release.debian.org/sarge_rc_policy.txt
> Is it worth trying to change that so that this gets fixed for Sarge?
It
re in the .diff.gz (as is usual), then dpkg-source
will not preserve the execute bit when other people extract your source
package. It's better to be consistent.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
an't use that until sarge has been released.
In the absence of that, something like 0.69-really-0.70-rc-1 (or what
you suggest) is a common workaround. It's not too bad to change the
tarball name.
--
Colin Watson [EMAIL PROTECTED]
.
>
> read the errors. it is clear what you have forgotten.
> you doesn't have a distclean target in your rules file in the debian
> directory.
Not quite; he doesn't have a distclean target in Makefile (not
debian/rules).
--
Colin Watson [EMAIL PROTECTED]
On Sun, Mar 21, 2004 at 11:13:36AM +0100, Arnaud Vandyck wrote:
> Colin Watson <[EMAIL PROTECTED]> writes:
> > Tollef Fog Heen opened a delayed queue on gluck a little while ago. My
> > .dupload.conf rune for this reads as follows:
[...]
> Is there a way to achieve th
should refer to policy and use the
sensible-pager system instead.
--
Colin Watson [EMAIL PROTECTED]
pkg-buildpackage, do something morally equivalent to 'debian/rules
build && fakeroot debian/rules binary'.
Use dpkg-buildpackage (or debuild, a wrapper around it which sorts out
fakeroot and the like) rather than 'debian/rules binary'.
--
Colin Watson [EMAIL PROTECTED]
r
> each locale and be able to recode every config file, man page,
Not possible. UTF-8 man pages are not yet supported by groff, and won't
be until groff 2.0.
--
Colin Watson [EMAIL PROTECTED]
[Please honour my Mail-Followup-To: header.]
On Wed, Mar 31, 2004 at 04:41:44PM +0300, Martin-Éric Racine wrote:
> On Wed, 31 Mar 2004, Colin Watson wrote:
> > On Wed, Mar 31, 2004 at 09:05:04AM +0300, Martin-Éric Racine wrote:
> > > Heck, if you ask me, Sarge should be known
version number to look for the source, so -1.0.1
becomes -1 and -1.1.1 becomes -1.1.
Beyond that, I don't believe they care.
--
Colin Watson [EMAIL PROTECTED]
to find the source (which
> would be impossible too, is 1.2-0.0.1 a binary NMU of 1.2, or of
> 1.2-0? Though nonstandard, the latter isn't forbidden)
katie tries both of those possibilities.
--
Colin Watson [EMAIL PROTECTED]
ad katie (and jennifer), you will find it doesn't
> care, it uses afaics the 'Source:' header from the .changes.
Please see the source_exists function here:
http://cvs.debian.org/*checkout*/dak/katie.py?rev=1.45&cvsroot=dak
--
Colin Watson [EMAIL PROTECTED]
On Fri, Apr 02, 2004 at 04:29:54PM +0200, Jeroen van Wolffelaar wrote:
> On Fri, Apr 02, 2004 at 12:28:32PM +0100, Colin Watson wrote:
> > On Fri, Apr 02, 2004 at 11:53:43AM +0200, Jeroen van Wolffelaar wrote:
> > > Any .deb indicates its source, including binary-only NMU'
doesn't
appeal (remember that neither of us has access to all the
architectures). Also I just don't think this is particularly urgent.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
se.
Every package containing dynamically linked binaries should use
${shlibs:Depends}.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
"$(echo *.foo)" = "*.foo" ] || for X in *.foo ; do foo "${X}"; done
There might actually be a file called "*.foo" :-)
I'd probably give up and use find/xargs instead myself.
--
Colin Watson [EMAIL PROTECTED]
goes, no schedule as such, but it's certainly planned
and is reasonably high up the list. I'd be surprised if there weren't
already a bug filed about it, but even if there isn't it's known.
--
Colin Watson [EMAIL PROTECTED]
cludes it should not run
> ldconfig.
And what's it doing messing about in /tmp?
--
Colin Watson [EMAIL PROTECTED]
it
> > doesn't matter if they co-exist?
>
> i think the correct way is to retitle the RFP to ITP and change the
> submitter to yourself
No, don't change the submitter; change the owner instead. See
http://www.debian.org/devel/wnpp/ for instructions.
--
Colin Watson
On Wed, May 05, 2004 at 09:31:10PM +0200, Andreas Barth wrote:
> * Robert Lemmen ([EMAIL PROTECTED]) [040505 21:25]:
> > On Wed, May 05, 2004 at 07:29:27PM +0100, Colin Watson wrote:
> > > No, don't change the submitter; change the owner instead. See
> > > http:
rent things...
I evidently missed the previous discussion, but I correct misconceptions
where I can.
--
Colin Watson [EMAIL PROTECTED]
Furthermore it won't actually close the bug as apparently desired. See
the policy manual for the syntax of "closes".
--
Colin Watson [EMAIL PROTECTED]
ator
> capable of running most PowerPC operating systems
It's kind of disappointing that this hasn't been ported to powerpc
itself. :( (Take a look at src/cpu_generic/ppc_tools.h for starters.)
Since ppc_tools.h currently hardcodes HOST_IS_X86, I suspect this
release will only bu
ackages won't be accepted into the Debian archive. You need to
create a proper Debian source package; there's documentation in the
"Developers' Corner" section of the Debian web site.
--
Colin Watson [EMAIL PROTECTED]
ar case, but it should be just fine to
say "the copyright owner gave permission to do this" (as long as it's
not specific to Debian, etc.), without necessarily having to wait for a
new upstream release. Of course, I'd be inclined to include the full
text of the e-mail in question.
--
Colin Watson [EMAIL PROTECTED]
ll "Architecture: any"
> and it has therefore built and been uploaed by s390 *again*.
It doesn't matter what the source package says anyway. In order to get
s390 to stop building it, you need to get it added to
Packages-arch-specific.
--
Colin Watson [EMAIL PROTECTED]
>
> I haven't submitted a bug since this is not a 'complete' removal (as
> read on devel-ref 5.9.2) but I wrote to them directly ([EMAIL PROTECTED]).
> Am I wrong wrt to this procedure?
The file itself
(http://buildd.debian.org/quinn-diff/Packages-arch-specific) l
ly wrong.
"Architecture: i386" was needlessly common at one point.
--
Colin Watson [EMAIL PROTECTED]
p the upstream source to do
this; in the name of pristine .orig.tar.gz files, you can just upload
the full upstream tarball but only build part of it.
--
Colin Watson [EMAIL PROTECTED]
checking for perl... /usr/bin/perl
> configure: error: XML::Parser perl module is required for intltool
>
> Anyway I think as perl is not build-essential, itself should show up in
> Build-Depends even.
/usr/bin/perl is in perl-base, which is Essential and therefor
On Sat, Jul 03, 2004 at 01:32:37PM +0200, Pierre HABOUZIT wrote:
> But I have a doubt suddently, since the (close: #ITP_nb) is not in the
> changelog of the _last_ revision ... Do I need it to be in the last
> revision to be taken into account ?
dpkg-buildpackage -v is your friend.
or similar, you could run
that yourself.
> and no in directory name.
That doesn't actually matter, despite dpkg-source's warnings.
--
Colin Watson [EMAIL PROTECTED]
very good precedent for
modifying upstream tarballs when necessary, such as removing non-free
material.
--
Colin Watson [EMAIL PROTECTED]
nk I'll like it.)
I avoid svn-buildpackage too.
> (ii)
> postgrey includes perldoc documentation. Obviously this should be
> included with the package as a manpage.
That's fairly easy; just run pod2man over it at build-time.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
On Tue, Jul 06, 2004 at 10:01:40AM +0200, David Weinehall wrote:
> On Tue, Jul 06, 2004 at 08:54:44AM +0100, Colin Watson wrote:
> > On Tue, Jul 06, 2004 at 08:50:38AM +0200, Adrian 'Dagurashibanipal' von
> > Bidder wrote:
> > > (i)
> > > I have the pac
ver, man page sections do vary between Unixes, so it seems
reasonable to change this in the packaging.
--
Colin Watson [EMAIL PROTECTED]
, you'd want /usr/share/man/man1/foo.1L.gz, yes.
This is only really necessary if you're having problems with man page
name clashes, though; and I'd prefer '1latex' or '1tex' myself.
--
Colin Watson [EMAIL PROTECTED]
On Wed, Jul 21, 2004 at 05:22:39PM +0100, Steve McIntyre wrote:
> On Wed, Jul 21, 2004 at 05:07:36PM +0100, Colin Watson wrote:
> >I think lintian is way too pedantic here. It doesn't actually make any
> >particular difference to anything; the only thing I know of that
>
ince it isn't closed.
> Send a follow-up without changing the state of the bug?
This is the right thing to do.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
.
debhelper is well enough deployed now that that build-dependency isn't a
problem, and I find that it enhances readability enough over plain
dpkg-dev that it's worth it. I tend to find it very hard to work out
what a cdbs package is really doing behind the scene
pages.
(You can use the workaround in /usr/share/doc/groff/README.Debian
locally; upstream disapproves of this being the default, though, and I
tend to agree.)
Cheers,
--
Colin Watson [EMAIL PROTECTED]
ion, so there's no reason for the upstream
source to be listed in the .changes file.
--
Colin Watson [EMAIL PROTECTED]
d straightforward.
> Even if it were not ugly, it is sly and I cannot trust it. How can I
> fix it? All I want the script to do is to find a module. The module
> is not sneaking around, hiding somewhere, after all; it stands right
> there at the script's shoulder, ready to serve.
e prototype and adjust the
code that's using it to use that argument as a normal function argument,
then read the remaining arguments using va_arg().
Cheers,
--
Colin Watson [EMAIL PROTECTED]
gt;
> OK, how do I cope with missing build-depends? I tried to build on one of
> the chroots on pergolesi, but that doesn't know about dpkg-checkbuilddeps
> or dpkg-buildpackage...
There's no point in building on pergolesi for uploads to the archive yet
an
r/lib//scriptname;
fi
[ ! -f /usr/lib//scriptname ] || /usr/lib//scriptname
Cheers,
--
Colin Watson [EMAIL PROTECTED]
does uninstallable means here? missing dependencies?
>
> I think it means: not tried yet. Because neither hurd, nor sh are part
> of the official release.
sh doesn't even have a libc6 in the archive. I always ignore both of
these.
--
Colin Watson [EMAIL PROTECTED]
e (e.g. the text of an e-mail) in
debian/copyright.
> And using Raster3D for commercial purposes, still includes it on
> non-free category?
Restrictions on commercial use definitely exclude it from main. Sounds
like non-free.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
rticular .orig.tar.gz
has been part of a previous upload, it need not and probably should not
be mentioned in later .changes that use the same original upstream
source archive.
HTH,
--
Colin Watson [EMAIL PROTECTED]
tch mandatory?
... or indeed any such obfuscated patching system ...
--
Colin Watson [EMAIL PROTECTED]
On Fri, Sep 03, 2004 at 11:02:26PM +0200, Michael Schiansky wrote:
> On Fri, Sep 03, 2004 at 07:04:52PM +0100, Colin Watson wrote:
> > ... or indeed any such obfuscated patching system ...
>
> Why do you call dpatch 'obfuscated' ?
> Before I used it for one of my pa
On Sat, Sep 04, 2004 at 09:17:20AM +0200, Andreas Metzler wrote:
> On 2004-09-04 Colin Watson <[EMAIL PROTECTED]> wrote:
> > I recommend using a good revision control system instead, which offers
> > similar benefits to developers while leaving things clear for users.
>
&
On Sat, Sep 04, 2004 at 02:50:35PM +0100, James Troup wrote:
> Colin Watson <[EMAIL PROTECTED]> writes:
> > On Fri, Sep 03, 2004 at 11:02:26PM +0200, Michael Schiansky wrote:
> >> Why do you call dpatch 'obfuscated' ?
> >> Before I used it for one of my
ormal (but if someone has a way around this, I'm
> interested).
It happens because the md5sum of the signed .dsc has to be included in
the .changes, so two separate gpg runs are required.
--
Colin Watson [EMAIL PROTECTED]
g for a sponsor - please mail me
if you want to help!
Thanks,
--
Colin Watson [EMAIL PROTECTED]
e and
apache-ssl both provide httpd, so this simplifies to:
Depends: httpd, libapache-mod-perl
--
Colin Watson [EMAIL PROTECTED]
"Jaldhar H. Vyas" <[EMAIL PROTECTED]> wrote:
>On Sun, 26 Mar 2000, Colin Watson wrote:
>> "Jaldhar H. Vyas" <[EMAIL PROTECTED]> wrote:
>> >((apache || apache-ssl) && libapache-mod-perl) || apache-perl
>> >
>> >How ca
f you use dpkg-buildpackage or debuild,
they'll produce the appropriate files for you.)
The resulting .deb looks fair enough to me, though.
(Disclaimer: I'm only in the new-maintainer queue myself, I'm not a
developer yet.)
--
Colin Watson [EMAIL PROTECTED]
ort for sound, rather than
support in sndconfig. I imagine the answer's "yes", from when I last
looked at sndconfig.
It's good to see version 0.43 is packageable; I concluded that 0.38
wasn't because of the heavy dependency on kudzu.
--
Colin Watson [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>Thus spake Colin Watson ([EMAIL PROTECTED]):
>> It's good to see version 0.43 is packageable; I concluded that 0.38
>> wasn't because of the heavy dependency on kudzu.
>
>What's wrong with kudzu? sndconfig still depends
m than it is to
patch it up when you get it wrong; using 'dh_make' from the start will
also get this right, if you don't delete the extra .orig directory it
gives you.
Good luck!
--
Colin Watson [EMAIL PROTECTED]
uild do it for you?); also, the .orig.tar.gz
should contain files in the directory mp3html-1.3.8/ rather than
mp3html-1.3.8.orig/, and debian/rules should probably be executable.
Other than that the package seems to be fine now (the binary package
certainly looks OK).
--
Colin Watson [EMAIL PROTECTED]
Fredrik Steen <[EMAIL PROTECTED]> wrote:
>On Wed, May 10, 2000 at 03:25:42PM +0100, Colin Watson wrote:
>| Well, I can't do 'dpkg-source -x mp3html_1.3.8-1.dsc', so something is
>| wrong (are you building the source archives yourself rather than letting
>| dpkg-
cording to debian policy, games should be
>setuid games in order to write to score files.
That's set*g*id. Policy 5.10 explicitly says that games must not be
setuid.
--
Colin Watson [EMAIL PROTECTED]
gt;to my mail.
>So is there any unexpected problems with NM ?
There's also a complete absence of traffic at the nm-discuss mailing
list web archives; are said archives still working, or has discussion
simply died down?
--
Colin Watson [EMAIL PROTECTED]
Julian Gilbey <[EMAIL PROTECTED]> wrote:
>On Thu, Jun 29, 2000 at 01:33:17PM +0100, Mark Brown wrote:
>> On Tue, Jun 27, 2000 at 01:03:31PM +0100, Colin Watson wrote:
>> > There's also a complete absence of traffic at the nm-discuss mailing
>> > list web arc
section 10.4 of the Developer's Reference:
# Technically speaking, the following Perl regular expression is what is
# used:
# /closes:\s*(bug)?\#\d+(,\s*(bug)?\#\d+)*/gi
--
Colin Watson [EMAIL PROTECTED]
but perhaps something like 'gpg --passphrase-fd 0
--no-verbose --batch --output -' (roughly from /etc/Muttrc) might work
as a viewer in /etc/mailcap.
--
Colin Watson [EMAIL PROTECTED]
at foo
all:
echo '\\$$'
[EMAIL PROTECTED] ~]$ make -f foo
echo '\\$'
\\$
[EMAIL PROTECTED] ~]$
--
Colin Watson [EMAIL PROTECTED]
ge) and the New
Maintainers' Guide (in the maint-guide package) instead.
--
Colin Watson [EMAIL PROTECTED]
get notified (just a wild guess, might
>be the changelog entry too).
>
>At least /I/ got a few xzyz is INSTALLED|REJECTED|NEW mails.
Hmm, I didn't for denemo, and I'm listed both as Maintainer: and in the
changelog. Maybe Debian's mail or my mail was a bit broken at that time.
--
Colin Watson [EMAIL PROTECTED]
nd I'm not sure about the remaining two
cases.
Could we please have some guidance about this in the packaging manual?
Every time I try to work this out I get a different answer. At least if
all packages do it the same way then any future bugs in
update-alternat
s handle this?
Should I just leave the symlinks in there and build-depend on automake?
--
Colin Watson [EMAIL PROTECTED]
stalled already... yucks.
It happens every time I build a package inside fakeroot (i.e. every time
I build a package). It doesn't actually cause a dependency on fakeroot,
though.
--
Colin Watson [EMAIL PROTECTED]
hen build one binary package for main and one for non-free.
Are the X fonts required for the rest of it to work? If so, the
dictionary and scripts will have to go into contrib.
--
Colin Watson [EMAIL PROTECTED]
Josip Rodin <[EMAIL PROTECTED]> wrote:
>On Tue, Sep 19, 2000 at 09:04:19PM +0100, Colin Watson wrote:
>> It happens every time I build a package inside fakeroot (i.e. every time
>> I build a package).
>
>Eww. Is the bug filed, with an appropriate severity?
Yes,
lace, you might
want to post your debian/rules so we can see if there's some other bug
there.
--
Colin Watson [EMAIL PROTECTED]
re for
>advice first.
No, see /usr/doc/debian/bug-maint-mailcontrol.txt for how to use the
'retitle' command to [EMAIL PROTECTED]
--
Colin Watson [EMAIL PROTECTED]
m; unfortunately, libhdb is part of heimdal-lib on Debian, and
since I didn't have the relevant development packages installed the
build then failed. As a workaround, I added a line to debian/Policy.sh
to specify exactly which optional libraries I wanted to be used.
--
Colin Watson [EMAIL PROTECTED]
Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote:
>On 2927T182035+0100, Colin Watson wrote:
>> configuration system should probably be patched so that you can. Anybody
>> should be able to install all the build-dependencies, build the package,
>> and get the same
Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote:
>On 2928T012303+0100, Colin Watson wrote:
>> I couldn't see it in policy, which was why I weakened my original
>> statement.
>
> If build-time dependencies are specified, it must be possible to build
>
Alexander Kotelnikov <[EMAIL PROTECTED]> wrote:
>But I want to know where it is written about what should go to -dev
>package, and what to the library one.
/usr/share/doc/debian-policy/policy.html/ch4.html#s4.3
/usr/share/doc/packaging-manual/packaging.html/ch-sharedlibs.htm
or a higher epoch for the lifetime of that package name.
>If that works, why are the KDE packages using an epoch (4) instead of
>just 2.0-DATE-DEBIANRELEASE?
I guess there was some numbering problem at some point in the past.
--
Colin Watson [EMAIL PROTECTED]
u.
> dh_installdirs
[...]
> cd debian/tmp && install -d `cat ../dirs`
dh_installdirs should already have done this.
> install -s crafty debian/tmp/usr/games/crafty.bin
A DEB_BUILD_OPTIONS=nostrip facility (see policy 4.1) would be nice
here.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
t for you of
sorting near xemacs21, so that users would be more likely to notice it.
--
Colin Watson [EMAIL PROTECTED]
[EMAIL PROTECTED] (Colin Watson) wrote:
>Ola Lundqvist <[EMAIL PROTECTED]> wrote:
>>dpkg-gencontrol: error: source package has two conflicting values -
>>xemacs21 and gtk-xemacs21
>>dh_gencontrol: command returned error code
>[...]
>>When do dpkg-gencontrol s
ch will make the decision for you. And this is all in the base
system, so you don't need any extra dependencies.
There is no pager virtual package - that's easy enough to find out by
looking at the Packages entries for 'less', 'most', etc., or by looking
in /usr/share/doc/debian-policy/virtual-package-names-list.text.gz. No
need to guess.
--
Colin Watson [EMAIL PROTECTED]
Forwarding to debian-mentors; it didn't make it last time due to a silly
typo.
- Forwarded message from Colin Watson <[EMAIL PROTECTED]> -
Date: Wed, 6 Dec 2000 00:33:17 +
From: Colin Watson <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: ITP: binfmt-support --
this particular
class of Lintian warnings, if you're sure that the dependencies are
correct.
--
Colin Watson [EMAIL PROTECTED]
use /etc/init.d rather than /etc/rc.d/init.d, and expect packages with
initialization scripts to use update-rc.d.
As well as the New Maintainer's Guide, you should read the Packaging
Manual, which will probably go a long way to answering other questions
you may have.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
priate code fragments in these scripts for you, though you
may have to poke it a bit to get update-rc.d to do exactly what you
want.
--
Colin Watson [EMAIL PROTECTED]
really a redundant test.
Your best bet would probably be to look at the init.d script that
dh_make installs by default (you'll find it in
/usr/share/debhelper/dh_make/debian/init.d.ex) and modify that to suit
your circumstances, rather than trying to rewrite the existing script
for the Debian setup.
--
Colin Watson [EMAIL PROTECTED]
w.bitwizard.nl/sig11/>.
--
Colin Watson [EMAIL PROTECTED]
Colin Watson <[EMAIL PROTECTED]> wrote:
>Packages are at http://www.chiark.greenend.org.uk/~cjwatson/debian>
>(1.0.2 will be there shortly after I submit this bug report).
In case people were discouraged by 1.0.2 being somewhat broken with
regard to upgrading (oops), I uploaded 1.0
101 - 200 of 1012 matches
Mail list logo
