Hello,
I am not quite sure it is the best place to post this, but anyway.
I wrote a Python script to create and manage APT repositories which has
the following features:
- supports repositories with a structure almost identical to that of
the Debian archive, with distributions, the main/co
Gerber van der Graaf <[EMAIL PROTECTED]> wrote:
> I am trying to repair the libgpiv package I've build. The
> libgpiv_0.3.2-1_i386.deb contains a configuration file /etc/gpiv.conf,
> as reported by dpkg -c. Extracting the .deb to tmpdir/ (with dpkg -x)
This shows it is a conffile. This is more pr
Andrea Bolognani <[EMAIL PROTECTED]> wrote:
> Rhinote is designed to be "keyboard friendly", that is, every single action
> is binded to a specific keystroke.
^^
bound
(I'm not a native English speaker, though)
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Andrea Bolognani <[EMAIL PROTECTED]> wrote:
> Rhinote is designed to be "keyboard friendly", that is, every single action
> is bount to a specific keystroke.
^
bound
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [E
Norbert Preining <[EMAIL PROTECTED]> wrote:
> that it can be backported to woody (sarge already has tetex3).
... on http://www.backports.org/!
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
"Sandro Tosi" <[EMAIL PROTECTED]> wrote:
> No, I'm not sure at all! :) I suppose that field should tell the
> package builder "Ehi, use debian policy version XXX while building
> this package" and so every script involved will use this information
> to validate the package against the d-p specifie
Justin Pryzby <[EMAIL PROTECTED]> wrote:
> Agreed; my motivation for leaving commented lines around is that it is
> arguably easier to merge with newer dh_make template files (if one
> were to do that ..). The reason to not leave them around is that not
> doing so indicates some level of familiar
Bart Martens <[EMAIL PROTECTED]> wrote:
> Anyway, I don't see a problem with the readability of debian/rules with
> the commented dh_ lines, and I agree with Jari Aalto that leaving the
> commented dh_ lines can be useful, so I would vote "allow" if a
> discussion would be held for this.
I disagr
Panu Kalliokoski <[EMAIL PROTECTED]> wrote:
> Well, I must add that I don't find the recommendation very smart either,
> but probably there's somebody out there that has terrible difficulties
> in not reading commented-out lines or something like that. I personally
The threshold where commented
Jari Aalto <[EMAIL PROTECTED]> wrote:
> I disagree with comments about removing the lines from from
> debian/rules (debhelper calls that are unused). This file is used by
> the maintainer of the package and he knows best what is the most
> effective way to organize his works.
IME, it is not very
Romain Beauxis <[EMAIL PROTECTED]> wrote:
> Would you argue that you are not skilled if you comment your dh_* calls?
No, rather that if you're skilled, you don't need to comment them.
> You could simply not want to loose time to find back the good order...
I'd say that if you're ready to sacrif
Simon Richter <[EMAIL PROTECTED]> wrote:
> Exactly. So in order to understand my own packages better I leave the
> dh_* calls in, commented out so I can grep for them and see that they
> are disabled.
Well, I never felt this need.
> Being a DD, I think I should be able to make that judgement for
Franz Pletz <[EMAIL PROTECTED]> wrote:
> W: lopster; A binary links against a library it does not use symbols from
> This package contains a binary that links against a library that is
> not in the Depends line. This may also be a bug in the library which
> does not have a shlibs file.
>
> I've
Hi,
Yaroslav Halchenko <[EMAIL PROTECTED]> wrote:
> .pdf.gz versions. And at least I would expect all -doc packages to have
> uncompressed .pdfs since neither of the pdf viewers to me experience
> handle transparent decompression of pdf.gz
I know it doesn't really answer your question, but a sim
Kevin Bube <[EMAIL PROTECTED]> wrote:
> Yes, the package is done for unstable. Is X.org 7 expected to go into
> etch? Or is it better to use the X11R6 locations for now?
No, packaging for X.org was the right decision.
I'll try to have a look at your package one of these days, but probably
not th
Pádraig Brady <[EMAIL PROTECTED]> wrote:
> Done. The following "source package" was built with:
> dpkg-source -b fslint-2.15 fslint_2.15.orig.tar.gz
[...]
> I'm confused as to why it didn't ask me to sign it.
I don't know if that's expected (I usually use 'debuild' to build my
source packages),
Hi,
Kevin Bube <[EMAIL PROTECTED]> wrote:
> Hi mentors,
>
> I am looking for a sponsor for the urw-garamond package (ITP #367223).
> It builds cleanly with debuild and installs and works with
> unstable. This is my first attempt for a Debian package so comments are
> very welcome.
Your package i
Hi,
Ralf Stubner <[EMAIL PROTECTED]> wrote:
> I have valid E-Mail addresses that do not contain my surname. ;-)
Sure, but the license says you have to indicate your name *and* email
address. You can't hide. :)
> However, it was indeed an oversight to not mark the changed file
> properly as requ
Jean Parpaillon <[EMAIL PROTECTED]> wrote:
> - Manpage is in upstream. But manpage is in nroff format as I don't know
> autotools enough to handle manpage transformation with it...
What do you mean by manpage transformation? Transformation to .dvi? It's
not unusual to have manpages in *roff forma
Jean Parpaillon <[EMAIL PROTECTED]> wrote:
> It's because someone suggested me to have the manpage in xml format so
> that I could get it in pdf or dvi or I don't know...
Well, XML isn't necessary for that. You can get DVI from *roff with
'man -Tdvi' and PDF with dvipdfm(x)...
> ...Of course *ro
Hi,
Kevin Bube <[EMAIL PROTECTED]> wrote:
> The defoma-hints and scale files are indeed quite tricky. I modified the
> scales file by hand as the font itself declares all shapes as medium, so
> fontscale duplictes all fonts. I will reread the docs and rework the
> defoma-hints.
OK. BTW, since th
Hi,
Kevin Bube <[EMAIL PROTECTED]> wrote:
> After reading bug #366234 I set debhelper requirement to >=5.0.35. See
Fine. That's also what I had done with lmodern in the meantime.
>> 3. I'm not a native english speaker, but I would modify the Description
>>field this way:
>
> [snip]
>
>>
>
>
Nicolas Duboc <[EMAIL PROTECTED]> wrote:
> About the second issue, the current state of my work includes the
> modules in the diff.gz file. This file is then 531K. Do you think it is
> acceptable ?
Maybe you'd be better off with something like quilt, dpatch or cdbs,
that would allow clean separa
Charles Plessy <[EMAIL PROTECTED]> wrote:
> Le Fri, Jun 02, 2006 at 04:10:29PM +0200, Florent Rougon a écrit :
>> The files pertaining to the Debian packaging are
>> (c) 2006 Kevin Bube.
>>
Charles Plessy <[EMAIL PROTECTED]> wrote:
> I have made /usr/share/doc/probcons-extra a symlink to
> /usr/share/doc/probcons (probcons-extra depends on probcons). Is it OK
> to do such things? ^^
this is important
Yes, this
Vedran Furaè <[EMAIL PROTECTED]> wrote:
> Thanks for uploading. I see that parser at NEW didn't catch the "Closes:"
> line. I will close that bug once it's accepted.
If you used the right syntax, that probably happened because it wasn't
part of the last changelog entry, in which case dpkg-buildpa
"Redefined Horizons" <[EMAIL PROTECTED]> wrote:
> Here is my question. Can I create a custom Debian package for Library A that
> satisfies the dependency requirements of Package A, but still keep the older
> version of Library A required by my other programs?
Of course. Look for example at the GT
Bas Wijnen <[EMAIL PROTECTED]> wrote:
> Not at all, I am entirely looking at it from a user's perspective, in
> particular a user which doesn't want non-free software (those people are the
> reason contrib and non-free exist, so it seems appropriate to look especially
> at them).
No, there is a m
Kevin Bube <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I uploaded a new package version to mentors.debian.net. The changelog
> file lists all changes done. I think I addressed all problems which
> still remained.
http://mentors.debian.net/debian/pool/non-free/u/ is currently empty.
Huh?
> A slight
Justin Pryzby <[EMAIL PROTECTED]> wrote:
> It's my understanding that test ! is more portable than ! test (same
> for [ !).
I would be very surprised to know why.
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Grrmpfff...
Florent Rougon <[EMAIL PROTECTED]> wrote:
> I would be very surprised to know why.
^
interested (of course)
And yes, surprised if that was true.
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of &qu
Olly Betts <[EMAIL PROTECTED]> wrote:
> The autoconf manual, section 10.10 "Limitations of Shell Builtins" (in
> the CVS HEAD version at least) says:
>
> `!'
> The Unix version 7 shell did not support negating the exit status
> of commands with `!', and this feature is still absent from
"LI Daobing" <[EMAIL PROTECTED]> wrote:
> These two files were not added by me. they are in the original
> source[1]. so I think I have to repackage the source if I want to clear
> the warnings.
>
> [1]
> $ tar tzvf qterm_0.4.0pre4.orig.tar.gz | grep ex$
> -rw-r--r-- nichloas/nichloas1877 2003
Often, changelog entries explain why certain technical packaging
decisions were made (for instance, Build-Depend on "foo >= $version"
because of $reason). These entries are definitely useful, even if they
happened before the first release uploaded to the Debian archive.
--
Florent
--
To UNSUBS
Rogério Brito <[EMAIL PROTECTED]> wrote:
> I have been using your package for some time right now and it seems to
> work fine.
>
> I would love to see your package uploaded to Debian and I have seen that
> the latest version you published is both lintian and linda clean.
This is all very nice, bu
Hi,
Rogério Brito <[EMAIL PROTECTED]> wrote:
> I just read the copyright file and I thought that it would be
> distributable. Are there any conflicts in what is written there?
I pointed out the problems I saw in the initial thread about this RFS.
Please check the debian-mentors archives.
> Ple
"Andrew Donnellan" <[EMAIL PROTECTED]> wrote:
>> What does this do that python-xmms/pyxmms does not do?
>
> Maybe this might just be a *standalone application* rather than a library?
The standalone application corresponding to (and relying on) PyXMMS is
PyXMMS-remote (found in the pyxmms-remote D
Bas Wijnen <[EMAIL PROTECTED]> wrote:
> Also, someone noted that this script is vulnerable to a symlink attack in
> /tmp. I haven't found a good solution for that though, because I want to have
> a reachable build tree under a "normal" name, where I can see what all the
> files look like.
If you
[EMAIL PROTECTED] (Francesco Namuri) wrote:
> I think this is the problem... It's a packaging problem?
Doesn't look so. Maybe ask the buildd admins...
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
"Kurt B. Kaiser" <[EMAIL PROTECTED]> wrote:
> The QA upload switched from Build-Depends-Indep to Build-Depends and
> I left that alone. Maybe both of these (identical) should exist?
> Build-Depends: debhelper is necessary because dh_clean is in the clean
> target, and Build-Depends-Indep might be
Hi,
Charles Plessy <[EMAIL PROTECTED]> wrote:
> 1) How can I know if they are redistributable at all, for instance if
> they contain non-free fonts? In the worst case, do I have to repackage
> the sources as well?
I'll leave that to the real experts on the matter.
> 2) There are simple text ver
gregor herrmann <[EMAIL PROTECTED]> wrote:
> TTBOMK MS Office files don't contain any fonts (that's why they often look
> suboptimal if used on a machine where the referenced fonts are
> missing).
I believe there is[1] an option in MSWord to embed the fonts in a
document. But since it's an option
Kapil Hari Paranjape <[EMAIL PROTECTED]> wrote:
> As far as I understand it the DFSG does not apply to Copyright license
> documents. For example the GNU "COPYING" document contains exactly
> the same sentence.
That's right.
> The file "copying.dj" is DJ Delorie's copyright license document so i
Hi,
Székelyi Szabolcs <[EMAIL PROTECTED]> wrote:
> The soversion is usually added to the -dev package name to be able to
> support multiple versions of a library off-line, which means all
> versions can be found in the archive, but only one can be installed on
> the user's machine. The question i
Székelyi Szabolcs <[EMAIL PROTECTED]> wrote:
> That's right. But why is Replaces needed in the case of an MTA? If a
> package Providing mail-transport-agent is installed, and the user is
> about to explicitly install another package which also Provides and
> Conflicts with mail-transport-agent, th
Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> Reduces the memory wasted and speeds up processing in dpkg, dselect,
> apt, aptitude, britney, ...
It's also useful for simple humans looking at the dependencies of a
package: having all dependencies, including those on essential packages,
would c
Mike Hommey <[EMAIL PROTECTED]> wrote:
> If you mean rotation of pictures depending on the orientation tag in
> the exif data, jhead already does that, lossless, with jpegtran (which
> is in libjpeg-progs)
Since we are talking about this, I'd like to mention exifautotran(1),
which also does that,
Daniel Baumann <[EMAIL PROTECTED]> wrote:
> * this is ugly:
>
> ---snip---
> #! /bin/sh /usr/share/dpatch/dpatch-run
> ---snapp---
>
> and this is beautiful:
>
> ---snipp---
> #!/bin/sh /usr/share/dpatch/dpatch-run
> ---snapp---
How so?
There are two reasons why I always use the first styl
Hi,
Ben Hutchings <[EMAIL PROTECTED]> wrote:
> The requirement for "#! /" was documented in 4.1BSD but the
> implementation never really required it - compare
> http://www.in-ulm.de/~mascheck/various/shebang/exec.2.html and
> http://www.in-ulm.de/~mascheck/various/shebang/sys1.c.html
>
> (Found v
Warren Turkal <[EMAIL PROTECTED]> wrote:
> Okay, the build deps now look like:
> Build-Depends: cdbs, debhelper (>= 5), autotools-dev, gfortran, tex, texi2dvi
Ugh, what's this 'tex' package?
Before blindly doing what others tell you, you'd better think a little
bit (I'm sure Patrick didn't want
Hi,
Joachim Reichel <[EMAIL PROTECTED]> wrote:
> Hi,
>
> section 7.6 of the policy states that Build-Depends-Indep must be
> satisfied if the build target is invoked.
[...]
> Now, if my sponsor uploads this package, it will still fail, right? If
> Build-Depends-Indep is not satisfied by acciden
Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> The underlying problem is that build-arch/indep are not mandatory and
> thus building must call the "build" target.
This makes sense, thanks for pointing it out.
> If build-indep does take a considerable time then you can use the
> following hack
While we're at it, you should also consider adding the appropriate
texlive packages to your B-D as an alternative to the tetex packages.
Sooner or later (may well happen for lenny), the tetex packages will be
removed, so you'll have to do that anyway.
--
Florent
--
To UNSUBSCRIBE, email to [EM
Asheesh Laroia <[EMAIL PROTECTED]> wrote:
> I'm not a Debian developer, but I would think the easiest thing to do is to
> install pbuilder and create a chroot for Debian. Since the source package
> will be the same (libgmp-dev, I'd guess) for both, you can use pbuilder to
> generate the Debian pa
Daniel Baumann <[EMAIL PROTECTED]> wrote:
> * a build-depends on gawk | awk doesn't make sense. either you use
> specifically features of gawk, and then you only depend on gawk, or
> your depends is fulfilled by any awk implementations, which means,
> you don't need to list it
Err,
"Paul Cager" <[EMAIL PROTECTED]> wrote:
> The policy *does* distinguish between lines starting with one space
> (paragraphs with word-wrapping) and lines starting with two or more spaces
> (non-wrapped if panning is possible, otherwise hard-wrapped), so I think
> there is a strong policy basis for
Hi,
I'm not expert in these matters, but since nobody answered, I'll give it
a try.
Hynek Hanke <[EMAIL PROTECTED]> wrote:
> I have no direct controll over /dev/softsynth and /proc/speakup as
> they are not created by my package.
Sounds like the crucial point to me. As for /proc/speakup, I thin
Daniel Baumann <[EMAIL PROTECTED]> wrote:
> * $(MAKE) install DESTDIR=`pwd`/debian/fspanel
>
> -> do *not* use `pwd`, but $(CURDIR).
And when using $(CURDIR), please enclose the path in double quotes (""),
because $(CURDIR) may well contain spaces. There are so many packages
that get this w
Hi,
Marc Haber <[EMAIL PROTECTED]> wrote:
> I have a package with a bunch of configuration files that are managed
> by my maintainer scripts and not by dpkg.
Therefore, these configuration files are *not* conffiles. Your Subject
line was misleading (especially considering we are on -mentors).
>
Santiago Vila <[EMAIL PROTECTED]> wrote:
> Instead of 1,2,3 you could do 1,2,3 only when upgrading from a version
> previous than the one not having a.conf anymore
Sure.
> and in case that (3) happens, keep a.conf untouched, instead of
> renaming it (assuming the program will not read a.conf any
Marc Haber <[EMAIL PROTECTED]> wrote:
> The file is under ucf control (I omitted that to lessen complexity),
Hey! We are doctors. You have to tell us _everything_. :-)
> but ucf does not know about the file any more if it is not in the new
> package and will therefore not handle it.
Uh, if you
"Margarita Manterola" <[EMAIL PROTECTED]> wrote:
> The subject still says "configuration file" and not "conffile".
> There's a difference between them, and you should know it.
The subject here says "configuration file" because I fixed it. It seems
you are the one who doesn't know the difference b
"Andrew Donnellan" <[EMAIL PROTECTED]> wrote:
> So for a snapshot of revision 91 between stable version 2.0 and future
> version 2.1, would something like:
>2.1~20070123svn.r91
>
> be OK?
Ah, so now that we have this '~' allowed by dpkg, we have to use it
everywhere?
You cannot predict the f
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>> Ah, so now that we have this '~' allowed by dpkg, we have to use it
>> everywhere?
>
> No, but we should use it in situations for which is was
> specifically designed for, no?
Precisely. And it was *not* designed for CVS/SVN/whatever RCS sna
Marc Haber <[EMAIL PROTECTED]> wrote:
> These are 23 lines of code which have the potential for a lot of bugs.
> I do not think it is a good idea to cut&paste this code into a hundred
> packages.
I didn't know you were alone maintaining a hundred of packages that need
this particular removal code
Marc Haber <[EMAIL PROTECTED]> wrote:
>> I didn't know you were alone maintaining a hundred of packages that need
>> this particular removal code. Interesting.
>
> You seem to be deliberately misunderstanding me. I'll stop wasting my
> time.
I meant that when a maintainer copies code in its maint
Russ Allbery <[EMAIL PROTECTED]> wrote:
> In other words, use + if you're packaging
> that version plus some additional upstream modifications, and use
> + if you're packaging an alpha or beta arelease
^
I hope you meant '~' here.
> of .
Well, you're free to do what you want with
Marc Haber <[EMAIL PROTECTED]> wrote:
> I doubt this.
The code is definitely not what I call complex. The tetex-bin package
is, but not that particular piece of code, once isolated.
> Additionally, this is a huge waste of maintainer time. Code like this
> _BELONGS_ into a standardized tool. Foll
Damyan Ivanov <[EMAIL PROTECTED]> wrote:
> 3.7.2.2Oct 2006
> * Maintainer scripts must not be world writeable (up from a
> should to a must) [6.1]
>
> IMHO, this is something that makes 3.7.2.0 and 3.7.2.2 two non-equal
olaf <[EMAIL PROTECTED]> wrote:
> I havnt uploaded anything yet and I doubt that I am able to upload the files
> with suse-linux at my school (no dput?). What shall I do? :(
Presumably, putting all the following files:
/usr/bin/dput
/usr/bin/dcut [not sure if this one is actually needed]
Hi,
Daniel Leidert <[EMAIL PROTECTED]> wrote:
>> Definitely README.Debian; probably a good idea in "copyright", where you
>> mention the download location.
The Developers Reference gives several useful hints for this situation
and suggests[1] to use a more specific file: README.Debian-source.
Russ Allbery <[EMAIL PROTECTED]> wrote:
> I still think that debian/copyright is a more natural location for this
> information. debian/copyright is where we're required to specify the
> source of the upstream tarball. Any customizations to the upstream
> tarball seem to me to be part and parcel
Charles Plessy <[EMAIL PROTECTED]> wrote:
> #!/bin/sh
> echo -e "AMAP is now available under /usr/bin/amap.\nThis wrapper
> (/usr/bin/amap-align) will be removed in the future."
> exec /usr/bin/amap "$@"
'echo -e' is not specified by POSIX. If you want to use escapes such as
\n, you'd better use
Charles Plessy <[EMAIL PROTECTED]> wrote:
> As one of the program I package was recently automakified, I had to
> change debian/rules to deal with this. While comparing with other
> packages, I realised that often $(MAKE) is used instead of make in
> debian/rules. In case of trivial packages which
[Running X apps in a chroot]
Székelyi Szabolcs <[EMAIL PROTECTED]> wrote:
> You can. Just run an sshd inside the chroot and enable X forwarding on
> the ssh server sitting inside and the ssh client connecting from outside
> (from an xterm, of course).
There is another way, which I've been using
Hi,
Romain Beauxis <[EMAIL PROTECTED]> wrote:
> Well, if it's only meant for using the application in your current X server,
> you simply have to bind mount the /tmp directory in the chroot:
> mount -t none -o bind /tmp /path/to/chroot/tmp
>
> I think it's enough to get the chroot to use the X se
Joachim Reichel <[EMAIL PROTECTED]> wrote:
>> Now here's the part that I forgot: debian/rules usually has a binary-arch and
>> binary-indep target. Run "debian/rules clean binary-arch" and now you can
>> check whether the package will also run fine on a Debian autobuilder.
>
> The problem is that
Warren Turkal <[EMAIL PROTECTED]> wrote:
> Why does this matter? I don't see every other package specifically
> mentioning who made it or what OS it was originally developed for.
Of course it matters. I don't know whether there is an official (i.e.,
from Apple) public full specification for HFS+,
Hi,
Long before I heard about reprepro, I also wrote my own Python script to
manage my local and remote Debian repositories (and I'm still using it):
http://people.debian.org/~frn/fmdr
documented at:
http://people.debian.org/~frn/fmdr.txt
To follow the pattern on
http://wiki.debian.org/How
Hi,
Siegfried-Angel <[EMAIL PROTECTED]> wrote:
> The package appears to be lintian clean, except for this messages
> (checking the .deb):
> - E: qttube: postinst-does-not-call-updatemenus usr/share/menu/qttube
> - E: qttube: postrm-does-not-call-updatemenus usr/share/menu/qttube
> However, qttu
Siegfried-Angel <[EMAIL PROTECTED]> wrote:
> Sorry, the files had wrong versioning (-0ubuntu1) and I corrected
> that. You can dget it from here now:
> http://mentors.debian.net/debian/pool/main/q/qttube/qttube_0.2~pre1-1.dsc
OK.
> 2007/8/8, Florent Rougon <[EMAIL PROTE
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
Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> wrote:
> And don't count on dh_make, that it'll make everything for you.
> Sometimes you have to move files to proper directories using other
> tools, like dh_install for example.
I would say this is quite an understatement.
> Debhelper can help you t
Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote:
> Also, upon installation you should somehow create precompiled python
> files (*.pyc). I don't know python myself, but there must be some
> preferred way to do so, iirc there is a (unofficial?) python policy.
Right. I would not say it is unofficia
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
kamaraju kusumanchi <[EMAIL PROTECTED]> wrote:
> $tree fortranposix-0.1/debian/tmp/
> fortranposix-0.1/debian/tmp/
> `-- usr
> `-- lib
> |-- libfortranposix.a
> `-- libfortranposix.so.0.0.0
>
> 2 directories, 2 files
It seems you are using a debhelper compatibility level (see
Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> wrote:
> And don't count on dh_make, that it'll make everything for you.
> Sometimes you have to move files to proper directories using other
> tools, like dh_install for example.
I would say this is quite an understatement.
> Debhelper can help you t
Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote:
> Also, upon installation you should somehow create precompiled python
> files (*.pyc). I don't know python myself, but there must be some
> preferred way to do so, iirc there is a (unofficial?) python policy.
Right. I would not say it is unofficia
1 - 100 of 147 matches
Mail list logo
