[Please CC me on replies; I'm not subscribed to -mentors anymore.]
I'm currently reorganizing the epydoc source package. For various
reasons, I want to get rid of the set of pythonX.Y-epydoc packages and
just provide everything in the main python-epydoc package instead. What
I can't figure out i
[Please CC me on replies; I'm not subscribed to -mentors anymore.]
I'm currently reorganizing the epydoc source package. For various
reasons, I want to get rid of the set of pythonX.Y-epydoc packages and
just provide everything in the main python-epydoc package instead. What
I can't figure out i
> Eek!
>
> http://www.debian.org/doc/developers-reference/ch-developer-duties.en.html#s-key-maint
Double-eek! I'm rather embarrassed, now. :(
Anyway, my build-related gaffes aside, ncompress has now made it into
testing. Thanks to all of you for your advice and help.
KEN
--
Kenneth J. Prono
> Eek!
>
> http://www.debian.org/doc/developers-reference/ch-developer-duties.en.html#s-key-maint
Double-eek! I'm rather embarrassed, now. :(
Anyway, my build-related gaffes aside, ncompress has now made it into
testing. Thanks to all of you for your advice and help.
KEN
--
Kenneth J. Prono
> Dunno about fakeroot, but why do you want gpg on escher? You really
> don't want to be storing your private GPG key on machines you don't
> control; copy the built files back to a secure machine and sign there
> instead.
In retrospect, that's much more sensible than temporarily copying my
.gnu
> > I had no problems getting into debussy, raptor or crest, but casals and
> > escher denied my login.
>
> pdksh wasn't installed; try again.
That was it. Thanks!
Only problem now is that fakeroot isn't installed on casals and gpg
isn't installed on escher. Should I just write debian-admin?
> Dunno about fakeroot, but why do you want gpg on escher? You really
> don't want to be storing your private GPG key on machines you don't
> control; copy the built files back to a secure machine and sign there
> instead.
In retrospect, that's much more sensible than temporarily copying my
.gnu
> > I had no problems getting into debussy, raptor or crest, but casals and
> > escher denied my login.
>
> pdksh wasn't installed; try again.
That was it. Thanks!
Only problem now is that fakeroot isn't installed on casals and gpg
isn't installed on escher. Should I just write debian-admin?
> > > You login and do "dchroot sid". This solves alpha (escher), arm
> > > (debussy), s390 (raptor), m68k (crest) and mips (casals). - You are
> > > only missing ia64.
I had no problems getting into debussy, raptor or crest, but casals and
escher denied my login. I had assumed the machines page
> > > You login and do "dchroot sid". This solves alpha (escher), arm
> > > (debussy), s390 (raptor), m68k (crest) and mips (casals). - You are
> > > only missing ia64.
I had no problems getting into debussy, raptor or crest, but casals and
escher denied my login. I had assumed the machines page
> If I were you I'd maybe build it on some of these architectures if I
> felt motivated to do so, and then file a bug on ftp.debian.org to get
> the old builds removed for the other architectures that are no longer
> autobuilding non-free software. If they don't want to autobuild it, why
> waste th
> Chroots are usually accessible with 'dchroot ' when and where
> they are available.
Got it. I was able to do that on debussy for arm, and m68k on crest
(although it turns out m6k autobuilds at least some non-free already).
> This is one of the reasons why non-free sucks.
I understand now. :-)
> > I've think that patent is about to expire. (June 20? I think I saw
> > it slashdotted within the past month.) If you can confirm this, just
> > wait till then and move it to main.
> Unfortunately it seems that that's only true for very us-centric
> people, not Debian.
Yes - when I dug into
> If I were you I'd maybe build it on some of these architectures if I
> felt motivated to do so, and then file a bug on ftp.debian.org to get
> the old builds removed for the other architectures that are no longer
> autobuilding non-free software. If they don't want to autobuild it, why
> waste th
> Chroots are usually accessible with 'dchroot ' when and where
> they are available.
Got it. I was able to do that on debussy for arm, and m68k on crest
(although it turns out m6k autobuilds at least some non-free already).
> This is one of the reasons why non-free sucks.
I understand now. :-)
> > I've think that patent is about to expire. (June 20? I think I saw
> > it slashdotted within the past month.) If you can confirm this, just
> > wait till then and move it to main.
> Unfortunately it seems that that's only true for very us-centric
> people, not Debian.
Yes - when I dug into
> > Because I still use it[...]
>
> I have to ask...why? :-)
Well, I think you're poking fun at me, but I'm going to pretend that I
didn't notice and give you an answer anyway. :)
The main reason I took it is that my Cedar Backup package (not
officially in Debian) supports tar.Z backups and henc
> > Because I still use it[...]
>
> I have to ask...why? :-)
Well, I think you're poking fun at me, but I'm going to pretend that I
didn't notice and give you an answer anyway. :)
The main reason I took it is that my Cedar Backup package (not
officially in Debian) supports tar.Z backups and henc
I know this question (or a similar one) comes up periodically both here
and on -devel. Unfortunately, I have to ask it again, because I can't
find a complete solution to my problem.
Because I still use it, I adopted ncompress a few months ago when it was
orphaned. I spent a night or two and clos
I know this question (or a similar one) comes up periodically both here
and on -devel. Unfortunately, I have to ask it again, because I can't
find a complete solution to my problem.
Because I still use it, I adopted ncompress a few months ago when it was
orphaned. I spent a night or two and clos
> I may be speaking out of turn here (just a lurker), but recently I saw
> on the RC bugs list a large number of RC bugs that were put against
> several packages that were relying on files that came from
> /usr/share/doc/ directories.
>
> Here is the URL to the bug in question
> http://bugs.debia
> License: GPL2
> Homepage: http://sourceforge.net/projects/ol2mbox/
Sounds like a cool app. However, what are the "legal issues" that have
caused upstream development to stop? I think those probably need to be
clarified before your package can be uploaded to Debian (at least, I'd
personally wan
> No, I think you want /usr/share/doc//examples:
>
> greenwood$ find /usr/share/doc -name "examples" -type d -print | wc --lines
> 190
> greenwood$
Yeah, you're right - typo on my part, sorry. My fingers are faster than
my brain on Fridays. :-)
KEN
pgp4L7HShhgtk.pgp
Description: PGP signa
> I am packaging the Net::NBName module from CPAN. This module contains
> some example scripts which are installed using the 'EXE_FILES' option
> to MakeMaker. Should I install these in /usr/bin,
> /usr/share/doc/examples or not at all? (And if not /usr/bin, how
> should I change their installat
> > I don't know if there is a policy on this. I'd recommend switching to
> > your @d.o address as you're doing regular uploads. If by the time of the
> > freeze there are still packages left with your old address, an upload
> > just to fix that is alright. That's just MHO, YMMV.
> >
>
> this is p
> > I don't know if there is a policy on this. I'd recommend switching to
> > your @d.o address as you're doing regular uploads. If by the time of the
> > freeze there are still packages left with your old address, an upload
> > just to fix that is alright. That's just MHO, YMMV.
> >
>
> this is p
Now that my new maintainer application has been approved, I want to
start the process of changing the maintainer field in my packages to use
my @d.o address rather than my personal address.
What is the recommended practice on uploading new versions of packages
just for "minor" changes like this?
Now that my new maintainer application has been approved, I want to
start the process of changing the maintainer field in my packages to use
my @d.o address rather than my personal address.
What is the recommended practice on uploading new versions of packages
just for "minor" changes like this?
> I'm getting this Lintain error for my package called "gav":
>
> E: gav: changelog-file-not-compressed CHANGELOG
Hmm. I think that if you use:
dh_installchangelogs CHANGELOG
rather than listing it in debian/docs, that will take care of your
problem.
KEN
--
Kenneth J. Pronovici <[EMAIL
> I'm getting this Lintain error for my package called "gav":
>
> E: gav: changelog-file-not-compressed CHANGELOG
Hmm. I think that if you use:
dh_installchangelogs CHANGELOG
rather than listing it in debian/docs, that will take care of your
problem.
KEN
--
Kenneth J. Pronovici <[EMAIL
> In general, you have a single source package (e.g. python-pythoncard) which
> builds/installs for each available Python version (and Build-Depends on the
> -dev version for each of those, obviously) into a python-pythoncard
> package, and an empty python-pythoncard package that Depends on the
> c
> > > This is getting a bit more complicated than I expected it to be. I'd
> > > appreciate any advice you can give me.
> > I don't know why you split docs and samples, I'd put them in one package,
> > the samples go into /usr/share/doc//examples/. The doc package
> > depending on either of the li
> In general, you have a single source package (e.g. python-pythoncard) which
> builds/installs for each available Python version (and Build-Depends on the
> -dev version for each of those, obviously) into a python-pythoncard
> package, and an empty python-pythoncard package that Depends on the
> c
> > > This is getting a bit more complicated than I expected it to be. I'd
> > > appreciate any advice you can give me.
> > I don't know why you split docs and samples, I'd put them in one package,
> > the samples go into /usr/share/doc//examples/. The doc package
> > depending on either of the li
> > I've now noticed that this doesn't conform to policy and I'm a little
> > confused about what packages I should provide.
> Only the name of the module package is against policy - it should be
> python-pythoncard.
I'm going to take this to mean python2.2-pythoncard/python2.3-pythoncard
based o
> > I've now noticed that this doesn't conform to policy and I'm a little
> > confused about what packages I should provide.
> Only the name of the module package is against policy - it should be
> python-pythoncard.
I'm going to take this to mean python2.2-pythoncard/python2.3-pythoncard
based o
Hi,
I filed an ITP for PythonCard (http://pythoncard.sourceforge.net), and
I've made a first pass at packaging it. I built the following binary
packages:
libpythoncard-python
pythoncard-samples
pythoncard-doc
Each depends on python (>=2.2), python (<<2.3). The
libpythoncard-python pa
Hi,
I filed an ITP for PythonCard (http://pythoncard.sourceforge.net), and
I've made a first pass at packaging it. I built the following binary
packages:
libpythoncard-python
pythoncard-samples
pythoncard-doc
Each depends on python (>=2.2), python (<<2.3). The
libpythoncard-python pa
> This is exactly why I asked - the real key word here is 'should'. It's
> not a must, but on the other hand, it's not unreasonable, either. I've
> written to upstream to begin talking with them about this and other
> issues, and who knows, maybe they'll want to go to a reasonable version
> numbe
> This is exactly why I asked - the real key word here is 'should'. It's
> not a must, but on the other hand, it's not unreasonable, either. I've
> written to upstream to begin talking with them about this and other
> issues, and who knows, maybe they'll want to go to a reasonable version
> numbe
> I have a question about how to proceed. I am considering packaging a
> program, and it uses a nonstandard versioning scheme. It ends up
> looking like -DR7.10. dh_make doesn't parse this - this in
> itself trivial to work around, but it made me stop and wonder if this
> is because the versioni
> I have a question about how to proceed. I am considering packaging a
> program, and it uses a nonstandard versioning scheme. It ends up
> looking like -DR7.10. dh_make doesn't parse this - this in
> itself trivial to work around, but it made me stop and wonder if this
> is because the versioni
> From policy:
> "Java libraries must depend on the needed runtime environment (java1-runtime
> and/or java2-runtime) but should not depend (only suggest)
> java-virtual-machine."
Right. I will use this:
Depends: kaffe | java1-runtime, java-common
Suggests: java-virtual-machine
I think
> From policy:
> "Java libraries must depend on the needed runtime environment (java1-runtime and/or
>java2-runtime) but should not depend (only suggest) java-virtual-machine."
Right. I will use this:
Depends: kaffe | java1-runtime, java-common
Suggests: java-virtual-machine
I think tha
Ok... I've gotten a lot of answers on this thread, which I REALLY
appreciate. This is what I love about Debian. :-) I just want to take
one last pass at my question, to make sure everyone's in agreement.
Parts of this thread (which is now a week+ long) have gotten lost along
the way :), so to su
Ok... I've gotten a lot of answers on this thread, which I REALLY
appreciate. This is what I love about Debian. :-) I just want to take
one last pass at my question, to make sure everyone's in agreement.
Parts of this thread (which is now a week+ long) have gotten lost along
the way :), so to su
> If you want to specify which of a set of real packages should be the
> default to satisfy a particular dependency on a virtual package, you
> should list the real package as an alternative before the virtual one.
>
> If kaffe works for Kenneth, I guess his Depends line is fine. By
> If you want to specify which of a set of real packages should be the
> default to satisfy a particular dependency on a virtual package, you
> should list the real package as an alternative before the virtual one.
>
> If kaffe works for Kenneth, I guess his Depends line is fine. By
> $ apt-cache show kaffe
> ..snip..
> Provides: java-virtual-machine, java-runtime, java1-runtime
>
> So, kaffe provides java-virtual-machine. You don't need to write dependency
> for kaffe.
Ok, that makes sense.
KEN
--
Kenneth J. Pronovici <[EMAIL PROTECTED]>
Personal Homepage: http://www.sk
> $ apt-cache show kaffe
> ..snip..
> Provides: java-virtual-machine, java-runtime, java1-runtime
>
> So, kaffe provides java-virtual-machine. You don't need to write dependency
> for kaffe.
Ok, that makes sense.
KEN
--
Kenneth J. Pronovici <[EMAIL PROTECTED]>
Personal Homepage: http://www.sk
> > You should list the working package first :
> >
> > working-java | java-common
>
> And it should look like this instead.
>
> working-jvm | java-virtual-machine.
Ok. I will change it to:
Depends: kaffe | java-virtual-machine, java-common
Is this correct?
KEN
--
Kenneth J. Pronovic
> > You should list the working package first :
> >
> > working-java | java-common
>
> And it should look like this instead.
>
> working-jvm | java-virtual-machine.
Ok. I will change it to:
Depends: kaffe | java-virtual-machine, java-common
Is this correct?
KEN
--
Kenneth J. Pronovic
> OTOH, the BTS can serve as a todo list, which is why I regularly file
> bugs against my own packages. This is especially useful when you hand
> over the package later and haven't done everything you wanted to do
> (for lack of time or sth.), the new maintainer will then have an idea
> of what you
> OTOH, the BTS can serve as a todo list, which is why I regularly file
> bugs against my own packages. This is especially useful when you hand
> over the package later and haven't done everything you wanted to do
> (for lack of time or sth.), the new maintainer will then have an idea
> of what you
While testing a patch from upstream to fix a bug in my libxmltv-perl
package, I discovered another bug related to the package version
for libhtml-tableextract-perl (one XMLTV script requires 1.08, the
Debian version of the package is 1.06-2). I've filed a bug against
libhtml-tableextract-perl requ
While testing a patch from upstream to fix a bug in my libxmltv-perl
package, I discovered another bug related to the package version
for libhtml-tableextract-perl (one XMLTV script requires 1.08, the
Debian version of the package is 1.06-2). I've filed a bug against
libhtml-tableextract-perl requ
[I think this is still topical to both debian-mentors and debian-java.
Someone tell me if they want it moved to one or the other...]
> gcj is supposed to come with a working jni implementation and comes with
> gij (GNU Interpreter for Java) for interpreting bytecode. What exactly
> doesn't work wi
[I think this is still topical to both debian-mentors and debian-java.
Someone tell me if they want it moved to one or the other...]
> gcj is supposed to come with a working jni implementation and comes with
> gij (GNU Interpreter for Java) for interpreting bytecode. What exactly
> doesn't work wi
> gcj is supposed to come with a working jni implementation and comes with
> gij (GNU Interpreter for Java) for interpreting bytecode. What exactly
> doesn't work with gcj? Could you please file a bug report?
> http://gcc.gnu.org/bugs.html
> That way we at least know about the issue.
>
> Also Kaff
> gcj is supposed to come with a working jni implementation and comes with
> gij (GNU Interpreter for Java) for interpreting bytecode. What exactly
> doesn't work with gcj? Could you please file a bug report?
> http://gcc.gnu.org/bugs.html
> That way we at least know about the issue.
>
> Also Kaff
> Erm, i think it is even worse, i think that the users would need to
> install the j2sdk1.3 package or else it will be unusable. This also
> means that your package will never enter testing, i think, or maybe
> there is some kind of override for contrib/non-free packages. Also, the
> j2sdk1.3 is a
> Last i knew, j2sdk1.3 is not part of debian, be it in main, contrib or
> non-free, because it is not possible for us to distribute it because of
> the licencing issues.
>
> Because of that, this particular dependency will never be really
> satisfied, the auto builders will not be able to build
> Erm, i think it is even worse, i think that the users would need to
> install the j2sdk1.3 package or else it will be unusable. This also
> means that your package will never enter testing, i think, or maybe
> there is some kind of override for contrib/non-free packages. Also, the
> j2sdk1.3 is a
[I'm cross-posting to debian-java and debian-mentors, because I'm not
sure whether this is a Java question or a packaging question. Please
CC me on replies, if possible.]
Can anyone suggest why libnbio2-java's build dependency on j2sdk1.3
cannot be satisfied on all 13 platforms?
http://qa.deb
> Last i knew, j2sdk1.3 is not part of debian, be it in main, contrib or
> non-free, because it is not possible for us to distribute it because of
> the licencing issues.
>
> Because of that, this particular dependency will never be really
> satisfied, the auto builders will not be able to build
[I'm cross-posting to debian-java and debian-mentors, because I'm not
sure whether this is a Java question or a packaging question. Please
CC me on replies, if possible.]
Can anyone suggest why libnbio2-java's build dependency on j2sdk1.3
cannot be satisfied on all 13 platforms?
http://qa.deb
Hello -
I'm working through the new maintainer process. My application manager,
Andrew Suffield, has reviewed several new packages of mine as a part of
the process. He says:
> The next step is to get some or all of these uploaded to the archive.
> .
> .
> .
> Once you're happy with them, find a
Hello -
I'm working through the new maintainer process. My application manager,
Andrew Suffield, has reviewed several new packages of mine as a part of
the process. He says:
> The next step is to get some or all of these uploaded to the archive.
> .
> .
> .
> Once you're happy with them, find a
68 matches
Mail list logo
