Hi mentors!
Here I am sending this RFC/RFS again.
Having corrected all the bugs/wishlist items which came up here on the list,
I feel Rhinote is finally ready to be uploaded.
Obviously, if someone finds any other problem, I'll be happy to fix it and
learn a little more :)
Below is the info about
On Sun, Apr 23, 2006 at 06:33:04PM -0500, Joe Wreschnig wrote:
On Thu, 2006-04-20 at 15:51 -0700, Steve Langasek wrote:
If it's not supposed to be a public module, it shouldn't be in a public
directory, and then there's no reason to provide more packages than just the
application package.
On 4/25/06, Frank Küster [EMAIL PROTECTED] wrote:
Theppitak Karoonboonyanan [EMAIL PROTECTED] wrote:
Dear mentors,
I have adopted the orphaned thailatex package in the bug:
http://bugs.debian.org/357871
And now the brand new package has been dressed up,
waiting for sponsoring.
Damyan Ivanov wrote:
apt-ftparchive(1) gives:
release
The release command generates a Release file from a directory
tree. It recursively searches the given directory for Packages,
Packages.gz, Packages.bz2, Sources, Sources.gz, Sources.bz2, Re‐
lease and md5sum.txt
Dear Mentors,
I have one question about changelog handling in debian packages.
I'm building a new source package with multiple sub-packages.
The sub-packages, however, were formerly built separately as
single sources, despite the fact that they were from the same
upstream source, due to some
Theppitak Karoonboonyanan [EMAIL PROTECTED] wrote:
Thank you for your comments. I've tried to cover all of them.
Please check the updated package at the old place:
http://linux.thai.net/~thep/debian/source/thailatex/
I'll not be able to do this today (I think), please remind me if I don't
Dear Mentors,
I'm thinking about having the new package's changelog been
started as a fresh new one, and keeping each sub-package's
previous changelog as changelog-preX.Y.Z.Debian.gz.
Is this OK according to Debian policy? Or is there other
recommended way?
That seems ok, AFAIK there is
Hi !
I have just recieved a bug: #364742 - and piuparts is as always right.
Something fails in removing alternatives again.
/usr/share/icons/default/index.theme pointing into alternatives
# update-alternatives --display x-cursor-theme
x-cursor-theme - status is auto.
link currently points to
Tomas Davidek [EMAIL PROTECTED] writes:
Damyan Ivanov wrote:
apt-ftparchive(1) gives:
release
The release command generates a Release file from a directory
tree. It recursively searches the given directory for Packages,
Packages.gz, Packages.bz2, Sources, Sources.gz,
Am Dienstag, den 25.04.2006, 10:34 +0200 schrieb Tomas Davidek:
Damyan Ivanov wrote:
apt-ftparchive(1) gives:
release
The release command generates a Release file from a directory
tree. It recursively searches the given directory for Packages,
Packages.gz,
On 4/25/06, Frank Küster [EMAIL PROTECTED] wrote:
Theppitak Karoonboonyanan [EMAIL PROTECTED] wrote:
I've logged the closing of #344554 separately, but decided
not to close #351501, because the closing in previous change
was simply from the fact that it's gone when I tried installing.
On Mon, 24 Apr 2006, Don Armstrong wrote:
On Mon, 24 Apr 2006, Yaroslav Halchenko wrote:
...
1. There are two possible packaging schemes
a. Keep only original .xpi in the .orig.tar.gz, and extract/dpatch it
at build time.
b. Keep unzipped .xpi in .orig.tar.gz.
c.
On 4/25/06, Arjan Oosting [EMAIL PROTECTED] wrote:
Dear Mentors,
I'm thinking about having the new package's changelog been
started as a fresh new one, and keeping each sub-package's
previous changelog as changelog-preX.Y.Z.Debian.gz.
Is this OK according to Debian policy? Or is
Yaroslav Halchenko [EMAIL PROTECTED] writes:
xpi and jar is the source -- it is just packaged with the other
than tar/gzip archiver and nested in each other to make our life fun ;-)
That is why there is no alternative tarball with the true source is
often provided (even if the license is GPL)
Pinning and other fanciness aside, I just use this quick and dirty
bit of script to build my in-place repositories for me:
rm -f Contents.bz2 Contents.gz Packages.bz2 Packages.gz \
Release Release.gpg Sources.bz2 Sources.gz
apt-ftparchive contents . Contents
bzip2 -k Contents
Le mardi 25 avril 2006 à 11:20 +0800, Paul Wise a écrit :
On Mon, 2006-04-24 at 23:48 +0200, Le_Vert wrote:
spcaview : package review needed
The convention is RFC: package -- package description
http://www.le-vert.net/divers/debian-package/spcaview/spcaview_20051212-1.dsc
Best to
The Fungi wrote:
I'm not sure I've seen what seems to me to be the obvious solution
come through in a reply yet, but why not just create a custom chroot
for your target distribution (be it RHEL 4 or SUSE 9 or whatever)
and build in there?
Apparently this works pretty well for most people. If
On Tue, Apr 25, 2006 at 10:09:34PM +0200, Le_Vert wrote:
Le mardi 25 avril 2006 ?? 11:20 +0800, Paul Wise a ??crit :
On Mon, 2006-04-24 at 23:48 +0200, Le_Vert wrote:
spcaview : package review needed
The convention is RFC: package -- package description
I had the same problem with a package nyself. What I did was put the old
ones in the format changelog-oldpackagename.Debian.old.
--
Felipe Sateler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hi,
glosstex was orphaned two month ago. However I use it everyday and I
furthermore I correct a few bugs and I improve it (hyperref).
Therefore I am searching a sponsor.
Regards
Bastien ROUCARIES
PS: GlossTeX is a tool for the automatic preparation of glossaries, lists
of acronyms and
On Tue, Apr 25, 2006 at 10:32:24PM +, roucaries bastien wrote:
Hi,
glosstex was orphaned two month ago. However I use it everyday and I
furthermore I correct a few bugs and I improve it (hyperref).
Could you provide a hypertext link (url) to the source package you
wish to have uploaded?
Russ Allbery [EMAIL PROTECTED] wrote:
The separate debian/ directory is sort of a psychological
separation of hats that keeps it clearer that I may not always and forever
wear both hats.
The idea of a --with-debian-policy configure script argument
occured to me today; having that
Tyler MacDonald [EMAIL PROTECTED] writes:
Anyways, I've successfully moved to a non-native package and removed
all lintian warnings, except one that shows up on my work machine, but not
on my home machine:
W: libapache2-mod-bt: binary-or-shlib-defines-rpath
On Tue, Apr 25, 2006 at 12:15:57PM +, Sune Vuorela wrote:
I have just recieved a bug: #364742 - and piuparts is as always right.
Something fails in removing alternatives again.
/usr/share/icons/default/index.theme pointing into alternatives
# update-alternatives --display x-cursor-theme
Russ Allbery [EMAIL PROTECTED] wrote:
Tyler MacDonald [EMAIL PROTECTED] writes:
Anyways, I've successfully moved to a non-native package and removed
all lintian warnings, except one that shows up on my work machine, but not
on my home machine:
W: libapache2-mod-bt:
Tyler MacDonald [EMAIL PROTECTED] writes:
Russ Allbery [EMAIL PROTECTED] wrote:
W: libapache2-mod-bt: binary-or-shlib-defines-rpath
./usr/lib/apache2/modules/mod_bt.so /usr/local/lib
It's not clear where this is coming from, as the Debian apxs2 should
not be doing this. But I haven't
Russ Allbery [EMAIL PROTECTED] wrote:
However, if $CFG_LIBEXECDIR in your build is /usr/local/lib, that's
probably a problem. In general, the string /usr/local should not appear
anywhere in your build for Debian packages.
It doesn't, and apxs2's reply is the same on both systems:
$
Tyler MacDonald [EMAIL PROTECTED] writes:
Russ Allbery [EMAIL PROTECTED] wrote:
However, if $CFG_LIBEXECDIR in your build is /usr/local/lib, that's
probably a problem. In general, the string /usr/local should not
appear anywhere in your build for Debian packages.
It doesn't, and apxs2's
On Tue, 2006-04-25 at 16:14 -0400, Justin Pryzby wrote:
I'm using dpatch right now, pretty nice, thanks :-)
FYI many people are now starting to use quilt.
For good reason, it rocks!
* debian/watch: please add one (read uscan(1) for more info)
Added. Looks great but is it usefull
Paul Wise [EMAIL PROTECTED] writes:
That was actually from linda, not lintian. ldd and objdump -x would
indeed be helpful to find the problem.
The linda warning about linking against a binary that you don't use
symbols from is very prone to false positives and often has to just be
ignored.
On Tue, Apr 25, 2006 at 08:06:05PM -0700, Russ Allbery wrote:
Tyler MacDonald [EMAIL PROTECTED] writes:
Russ Allbery [EMAIL PROTECTED] wrote:
W: libapache2-mod-bt: binary-or-shlib-defines-rpath
./usr/lib/apache2/modules/mod_bt.so /usr/local/lib
It's not clear where this is coming
Justin Pryzby [EMAIL PROTECTED] writes:
I have often wondered if it would be useful to have a check (say, in
lintian ...) grepping the binary package contents for the build
directory ... assuming that the build directory is a sufficiently long
string, perhaps larger binary packages will need
indeed -- proper full building from source is simply necessary in such
cases
for my case -- upstream provided me with SVN information, I wrote a
nasty but nice ( :) ) wrapper script which is called by uscan if there
is a fresh .xpi available. That wrapper exports upstream SVN, wrapps
exported
On Tue, Apr 25, 2006 at 09:15:15PM -0700, Russ Allbery wrote:
Justin Pryzby [EMAIL PROTECTED] writes:
I have often wondered if it would be useful to have a check (say, in
lintian ...) grepping the binary package contents for the build
directory ... assuming that the build directory is a
On 2006-04-26, Steve Langasek [EMAIL PROTECTED] wrote:
what does update-alternatives --list x-cursor-theme list in this case?
It shows nothing.
[EMAIL PROTECTED]:/# update-alternatives --list x-cursor-theme
[EMAIL PROTECTED]:/#
It really looks to me like a u-a bug, not a bug in the calling
35 matches
Mail list logo
