Xavier Antoviaque <[EMAIL PROTECTED]> wrote:
> Yes, I read the policy, and I know about this script. But the problem is
> that byte-compilation is specific to a version of Python, and I was
> trying to package leo for both 2.2 and 2.3. It seems, from what I have
> read since my last post, that the
Hi,
Anibal Monsalve Salazar <[EMAIL PROTECTED]> wrote:
> Install ssmtp in the chroot.
Or nullmailer. Also, I have created the attached file in the normal
system (not in the chroot) to start the daemon in the chroot when the
system is booted.
local-sid-root-nullmailer
Description: Bourne shell
Frank Küster <[EMAIL PROTECTED]> wrote:
> Yes, technically this works. But then the version numbers do not
> correspond at all to the version numbers used by upstream. And you get
> in trouble if upstream changes his packaging and distributes all data in
> a single tar.gz:
>
> dpkg --compare-versi
Blars Blarson <[EMAIL PROTECTED]> wrote:
> In other words, this looks like yet another vaction clone by someone who
> didn't bother to read the vacation man page.
IMO, such judgments are not acceptable on public mailing-lists[1]. If
the upstream author felt like writing a program similar to vacat
Don Armstrong <[EMAIL PROTECTED]> wrote:
> The author(s) can spend free time in any way the author(s) wish to.
I'm glad to learn that.
> Likewise, Blars and myself are free to tell authors that what they
> have written appears to be a waste of their time when Free alternative
> "foo" exists. Jus
Foreword: you're lucky I happened to relate your mail to mine. Please do
the necessary so that your future messages actually appear as replies to
the messages you are replying to (hint: the "References" field does the
job).
"Richard A. Hecker" <[EMAIL PROTECTED]> wrote:
> You used a judgement to
jano kupec <[EMAIL PROTECTED]> wrote:
>> 3) I think you should build-depends on qt3-dev-tools and not only on
>>the libs (as you need qmake from the former).
>
> i added it there, but i thought it shouldn't be necessary since the
> libqt3-mt-dev already depends on qt3-dev-tools, according to a
Justin Pryzby <[EMAIL PROTECTED]> wrote:
> In fact, I believe all symlinks should be relative, except top-level
> symlinks. And packages probably shouldn't ship any of those:)
Not exactly. cf. Policy § 10.5:
,
| In general, symbolic links within a top-level directory should be
| relative, a
Shachar Shemesh <[EMAIL PROTECTED]> wrote:
> two questions:
> 1. My package has a password file. Where is the best place to store it?
> /etc/name/password? /var/lib/name/password?
If the password file is a system configuration file (i.e., a file that
can be customized by the admin to modify the
In case Justin's mail didn't answer all your questions...
Shachar Shemesh <[EMAIL PROTECTED]> wrote:
> Well, you would need a helper program to actually change it, as the
> password is encrypted. Otherwise, yes it's a configuration file.
Well, the line is a bit blurry here, I admit. Note that pa
Shachar Shemesh <[EMAIL PROTECTED]> wrote:
> After your explanation, the only thing I still have doubts over is
> whether the files should not go into /var/cache instead.
Erm, which files?
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Cont
Shachar Shemesh <[EMAIL PROTECTED]> wrote:
> The slight dilemma is whether /var/cache or /var/spool would be a
> better choice. I'm leaning towards spool, as they tend to be big, and
> it would really be better not to erase them.
Well, if you ask me, I think /var/cache doesn't look that bad for t
Justin Pryzby <[EMAIL PROTECTED]> wrote:
> Note that there was a relevant thread on -devel around about last
> October. Someone complained that their thesis was in /var/log/apache/
> and was deleted when they purged the package. As such, you might
> consider something like rm -f /var/log/apache/
Michelle Konzack <[EMAIL PROTECTED]> wrote:
> I asume, that
>
> rm -f /var/log/tddyndns/-??.log
>
> should work in all shells, because the logs are -MM.log.
It should work in /bin/sh.
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13
--
Florent
--
Justin Pryzby <[EMAIL PROTECTED]> wrote:
> You list the build-dependencies as best you know them, and then build
> in pbuilder. If it does not build, then you look at the last line,
> and figure out what it needs that it didn't have, and add the
> appropriate thing. If it does build, then you re
David Clarke <[EMAIL PROTECTED]> wrote:
> Why is it better to have the debian directory separate to the main
> tarball? I had a read of the thread a little while ago about the
> developers including a debian directory, and am still unsure why this is
> neccessarily a bad thing if the person produ
Ben Finney <[EMAIL PROTECTED]> wrote:
> Is '/usr/bin/env' part of the POSIX spec? Is its behaviour with regard
> to command arguments defined? Where would I find out?
It is part of POSIX:
http://www.opengroup.org/onlinepubs/009695399/utilities/env.html
The problem is not with env, but with sh
Li Daobing <[EMAIL PROTECTED]> wrote:
> If I want to modify the source tarball, for example, I want to delete
> the admin/CVS and debian/*.ex in the source, should I modify the version
> number, for example, called it 0.4.0pre2.dfsg.1-1 or some other name?
The version number consists of two parts
Bas Wijnen <[EMAIL PROTECTED]> wrote:
> For all platforms, it says that the compilation was "maybe-successful".
> That sounds like it could be better. Now I haven't seen anything
> "successful" for other packages either, so perhaps it is simply impossible.
>
> Is there anything I can (and should
Peter S Galbraith <[EMAIL PROTECTED]> wrote:
> > Splitting the docs when it doessn't have to happen, it not useful.
>
> It depends. Don't do it gratuitously, but it's worth doing if the docs
> are large.
OK, I am packaging a small Python extension (PyXMMS, the Debian package
being called pytho
Peter S Galbraith <[EMAIL PROTECTED]> wrote:
> It's probably overkill. If users are likely to install EITHER
> python2.1-xmms or python2.2-xmms but not both, then repeat the docs in
> each and forget about python-xmms-common (the license needs to be in
> every binary package anyway).
Hmmm. The
Junichi Uekawa <[EMAIL PROTECTED]> wrote:
> Users don't really need to care about python-version compatibility,
> do they ? Their primary aim is to write code that works for them, not
> write code that works on both.
They may care about Python version, because python*-xmms are Python
bindings
Hello,
I prepared packages for the two following programs:
- PyXMMS, a set of Python bindings to libxmms, plus some higher-level
functions; the source package generates four binary packages:
python2.1-xmms, python2.2-xmms, python-xmms (which depends on
python2.1-xmms) and python-xmm
Colin Watson <[EMAIL PROTECTED]> wrote:
> > dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> >
> > which I think should be OK since it is in the debhelper(1) manual page.
>
> Only if you're using one of the debhelper programs that actually adds to
> misc:Depends ('g
Andrea Mennucc <[EMAIL PROTECTED]> wrote:
> ... there is non-free-software that can be distributed, and
> non-free-sw that cannot be distributed (regardless of where)
And? Nobody said the contrary. Jérôme simply said that software that
can't be distributed is non-free software, which is (was?) t
Colin Watson <[EMAIL PROTECTED]> wrote:
[explanations about the advocate and sponsor's roles]
I was a bit confused between advocate and sponsor. That is why I found
stupid to pretend to sponsor someone only after he applied as a NM. Yes,
it would be stupid to pretend to advocate someone only aft
Hello,
I have a package that uses dh_installmime to put a file in
/usr/lib/mime/packages/ so as to register itself for some MIME types.
>From the man pages (update-mime(8) and dh_installmime(1)) and the Debian
MIME support sub-policy at
http://www.debian.org/doc/packaging-manuals/mime-policy/ it
Matt Zimmerman <[EMAIL PROTECTED]> wrote:
>> This should probably be a bug on packaging-manual if the bug is still
>> present in the most recent document.
>
> Er, packaging-manual doesn't exist anymore, of course. mime-policy is part
> of the policy manual, yes?
Not quite, but you are close. It
Hi,
My packages python2.{1,2,3}-xmms are not entering testing although they
have met (as far as I can see) all the required conditions for four days
now. The reason invoked on http://packages.qa.debian.org/p/pyxmms.html
is :
out of date on m68k: python2.1-xmms, python2.2-xmms, python2.3-xmms
Mark Brown <[EMAIL PROTECTED]> wrote:
> Check the archive to see if the package has actually been uploaded for
> m68k - the buildd web page reports the build when it happens but the
> changes file still needs to be signed before the package is uploaded.
You guessed right, it seems: I looked in th
Patrick Geschinski <[EMAIL PROTECTED]> wrote:
> Hi group,
Hello,
> So my question is why doesnt't Oracle certify his product for Debian ?
> What's the obstacle ?
> In my opinion it is very, very important that big companies certify their
> products for debian.
In my opinion, the relevant entity
Martin Michlmayr <[EMAIL PROTECTED]> wrote:
> (If anyone knows how to convert a string to UTF-8 in Python regardless
> of whether it's UTF-8 or Latin or ASCII, and to convert a string to
> ASCII/Latin regardless to whether it's UTF-8 or Latin, speak up now...)
I would say it is impossible, be it
Steve Langasek <[EMAIL PROTECTED]> wrote:
> The best heuristic is to first check whether it's valid UTF-8, and if it
> isn't, convert it from latin-1 to UTF-8. This correctly detects the
> vast majority of texts; but if what you want is UTF-8, it's always
> better to use that in the first place.
Florent Rougon <[EMAIL PROTECTED]> wrote:
> The script works with Python 2.2 or greater. I think it could be made to
> work relatively easily with 2.1, but I didn't bother.
OK, I didn't have much time to look at it yesterday, but it indeed was
easy to make it work with P
Marco Herrn <[EMAIL PROTECTED]> wrote:
> And, btw. I had some difficulties creating the package, mainly getting
> the manpage into the package. I created the file debian/hatari.manpages
> to get the actual manpage included, but as far as I know this shouldn't be
> necessary for only one manpage. C
"Peggy Pultke" <[EMAIL PROTECTED]> wrote:
> I thought so, too. But it doesn't work. It is enabled in debian/rules and
> since the manpage is installed when listed in debian/hatari.manpages this
> can't be the problem. I called the manpage hatari.1 and it lies in the
> debian directory, too. As far
Zenaan Harkness <[EMAIL PROTECTED]> wrote:
> Anyway, I know I wouldn't want to spend time learning _two_
> packaging systems - .deb (and .tar of course) are surely enough?
It seems you don't realize that converting from one packaging system to
another and hoping the results works correctly in mos
Hi, Frank!
Frank Küster <[EMAIL PROTECTED]> wrote:
> Note that there is one advantage of pbuilder: When you compile in a
> pbuilder environment, you know that there are no packages installed
> beside the base ones installed by debbootstrap and build-essential. So
> you know when you make it insta
Peter S Galbraith <[EMAIL PROTECTED]> wrote:
> > Splitting the docs when it doessn't have to happen, it not useful.
>
> It depends. Don't do it gratuitously, but it's worth doing if the docs
> are large.
OK, I am packaging a small Python extension (PyXMMS, the Debian package
being called python
Peter S Galbraith <[EMAIL PROTECTED]> wrote:
> It's probably overkill. If users are likely to install EITHER
> python2.1-xmms or python2.2-xmms but not both, then repeat the docs in
> each and forget about python-xmms-common (the license needs to be in
> every binary package anyway).
Hmmm. The s
Junichi Uekawa <[EMAIL PROTECTED]> wrote:
> Users don't really need to care about python-version compatibility,
> do they ? Their primary aim is to write code that works for them, not
> write code that works on both.
They may care about Python version, because python*-xmms are Python
bindings f
Hello,
I prepared packages for the two following programs:
- PyXMMS, a set of Python bindings to libxmms, plus some higher-level
functions; the source package generates four binary packages:
python2.1-xmms, python2.2-xmms, python-xmms (which depends on
python2.1-xmms) and python-xmms
Colin Watson <[EMAIL PROTECTED]> wrote:
> > dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> >
> > which I think should be OK since it is in the debhelper(1) manual page.
>
> Only if you're using one of the debhelper programs that actually adds to
> misc:Depends ('gr
Andrea Mennucc <[EMAIL PROTECTED]> wrote:
> ... there is non-free-software that can be distributed, and
> non-free-sw that cannot be distributed (regardless of where)
And? Nobody said the contrary. Jérôme simply said that software that
can't be distributed is non-free software, which is (was?) th
Oohara Yuuma <[EMAIL PROTECTED]> wrote:
> * I don't sponsor anyone who is not in the NM queue or
> who doesn't have a GPG key signed by a Debian developer.
Well, so I assume you never sponsor anyone since it appears to me that
one needs a sponsor before applying as a NM (if the NM task targette
Colin Watson <[EMAIL PROTECTED]> wrote:
> > | If you intend to package software, do you have a Debian package you have
> > | adopted or created ready to show your AM? [...] You may want to get
> ^^^
> > | sponsorship to achieve this goal.
>
Colin Watson <[EMAIL PROTECTED]> wrote:
[explanations about the advocate and sponsor's roles]
I was a bit confused between advocate and sponsor. That is why I found
stupid to pretend to sponsor someone only after he applied as a NM. Yes,
it would be stupid to pretend to advocate someone only afte
101 - 147 of 147 matches
Mail list logo
