Mark Roach:
> These are native packages i.e. The debian packaging info is part of
> the upstream tarball (I am the author). It is my understanding that
> since there is no difference between upstream and packaged versions
> no diff is necessary... isn't this right?
When I've released upstream sof
[EMAIL PROTECTED]:
If a package creates a user when it is installed, should it remove this user
when it is removed, on only when it is purged?
IMHO, when it is purged. At least if it may own the configuration files that
removing the package may leave behind. For the package I have that create
[EMAIL PROTECTED]:
If a package creates a user when it is installed, should it remove this user
when it is removed, on only when it is purged?
IMHO, when it is purged. At least if it may own the configuration files that
removing the package may leave behind. For the package I have that creates a
Matthew Palmer:
I just had another thought -- make a -1 revision with an empty diff.
Weird, but I can't think of any reason why it wouldn't work...
That usually works just fine, and it what I do when I release jwhois, since
I have also been doing the upstream releases. The debian subdirectory
Matthew Palmer:
I just had another thought -- make a -1 revision with an empty diff.
Weird, but I can't think of any reason why it wouldn't work...
That usually works just fine, and it what I do when I release jwhois, since
I have also been doing the upstream releases. The debian subdirectory is
Andreas Metzler:
> You could conditionally move the existing configuration file in the
> preinst to the new location.
Thanks. I'm doing something similar with a non-conffile for another of
my packages, so I'll just copy the working code from that. I was just
unsure whether I was allowed to do it
Andreas Metzler:
> You could conditionally move the existing configuration file in the
> preinst to the new location.
Thanks. I'm doing something similar with a non-conffile for another of
my packages, so I'll just copy the working code from that. I was just
unsure whether I was allowed to do it
Hi!
A new version of a package that I maintain has changed the name of the
default configuration file. I want to propagate this name change, but
how do I handle it properly? AFAICT, I'm not allowed to touch conffiles
in the maintainer scripts, but this would mean that the old
configuration would j
Hi!
A new version of a package that I maintain has changed the name of the
default configuration file. I want to propagate this name change, but
how do I handle it properly? AFAICT, I'm not allowed to touch conffiles
in the maintainer scripts, but this would mean that the old
configuration would j
Mattia Dongili:
> any suggestion?
For jwhois, where I act as upstream "release manager" and Debian
developer, I usually put the debian directory in the upstream tarball,
and then build it for Debian. I call the version -1, though, but the
diff is empty for the -1 version (it is nonempty -2). It i
Mattia Dongili:
> any suggestion?
For jwhois, where I act as upstream "release manager" and Debian
developer, I usually put the debian directory in the upstream tarball,
and then build it for Debian. I call the version -1, though, but the
diff is empty for the -1 version (it is nonempty -2). It i
Jordi S. Bunster:
> Maybe someone else can help this guy with this one, maybe someone
> that knows more about how CD vendors can contribute back to debian,
> and make the difference between "Official CD" and the other stuff
> clear.
http://www.debian.org/CD/vendors/info contains all the informati
Jordi S. Bunster:
> Maybe someone else can help this guy with this one, maybe someone
> that knows more about how CD vendors can contribute back to debian,
> and make the difference between "Official CD" and the other stuff
> clear.
http://www.debian.org/CD/vendors/info contains all the informati
Matt Zimmerman:
> If the program cannot be compiled using free tools, then it is not very
> free.
Well, that's a matter of definition.
I'll have a look at using another cross-assembler. Fortunately, there
seems to be a GPL'ed 6502 cross-assembler, so I'll have a look into
using that one instead.
Hi!
I have a question about a program that I am thinking about packaging:
It is a transfer program¹ licened according to GPL, but comes with some
program code that you download to the remote computer. That code is
also GPL, but the program used to compile those sources is not DFSG
free. The remote
Matt Zimmerman:
> If the program cannot be compiled using free tools, then it is not very
> free.
Well, that's a matter of definition.
I'll have a look at using another cross-assembler. Fortunately, there
seems to be a GPL'ed 6502 cross-assembler, so I'll have a look into
using that one instead
Hi!
I have a question about a program that I am thinking about packaging:
It is a transfer program¹ licened according to GPL, but comes with some
program code that you download to the remote computer. That code is
also GPL, but the program used to compile those sources is not DFSG
free. The remot
Magnus Ekdahl:
> "...Note, however, that the postrm cannot rely on any non-essential packages
> to be present during the purge phase" (deluser isn't essential).
> If there aren't any way, is this script safe enough?
Why not just run the regular account deletion, and post an error
message if i
Magnus Ekdahl:
> "...Note, however, that the postrm cannot rely on any non-essential packages
> to be present during the purge phase" (deluser isn't essential).
> If there aren't any way, is this script safe enough?
Why not just run the regular account deletion, and post an error
message if
Hi!
I just got serious bugs filed against two of my packages about
dependencies on packages with lower priorities. In one case it is
correct (a package with "optional" depending on one with "extra"), but
in one case all the packages are set to "extra" in my control files, so
I can't really underst
Hi!
I just got serious bugs filed against two of my packages about
dependencies on packages with lower priorities. In one case it is
correct (a package with "optional" depending on one with "extra"), but
in one case all the packages are set to "extra" in my control files, so
I can't really unders
Me:
> Did I misunderstand something, or is the keyring server down?
D'uh! GnuPG doesn't like my proxy. If I disable the proxy, it works just
fine.
--
\\//
peter - http://www.softwolves.pp.se/
Statement concerning unsolicited e-mail according to Swedish law:
http://www.softwolves.pp.se/peter
Hi!
According to the docs I an update my key on the Debian keyring by giving the
command
gpg --keyserver keyring.debian.org --send-keys 0x6394265E
but I cannot get it to work. Everytime I try (from different machines) I get
the error message
gpg: error sending to `keyring.debian.org': eof
Me:
> Did I misunderstand something, or is the keyring server down?
D'uh! GnuPG doesn't like my proxy. If I disable the proxy, it works just
fine.
--
\\//
peter - http://www.softwolves.pp.se/
Statement concerning unsolicited e-mail according to Swedish law:
http://www.softwolves.pp.se/pete
Hi!
According to the docs I an update my key on the Debian keyring by giving the
command
gpg --keyserver keyring.debian.org --send-keys 0x6394265E
but I cannot get it to work. Everytime I try (from different machines) I get
the error message
gpg: error sending to `keyring.debian.org': eof
Junichi Uekawa:
> That doesn't tell much.
> objdump -p /usr/lib/libMowitz.so | grep SONAME
er$ objdump -p /usr/lib/libMowitz.so | grep SONAME
SONAME libMowitz.so.0
> That sounds like a bad news, a potential sign of upstream changing
> binary interface between 0.1.0 and 0.2.0
I don't know
Junichi Uekawa:
> That doesn't tell much.
> objdump -p /usr/lib/libMowitz.so | grep SONAME
er$ objdump -p /usr/lib/libMowitz.so | grep SONAME
SONAME libMowitz.so.0
> That sounds like a bad news, a potential sign of upstream changing
> binary interface between 0.1.0 and 0.2.0
I don't kno
Junichi Uekawa:
> Are you sure of the soname version number?
It is at least the version used in the files:
$ ls -l /usr/lib/libMowitz.*
-rw-r--r--1 root root 400490 13 mar 18.42 /usr/lib/libMowitz.a
-rw-r--r--1 root root 717 13 mar 18.41 /usr/lib/libMowitz.la
lrwxr
Junichi Uekawa:
> Are you sure of the soname version number?
It is at least the version used in the files:
$ ls -l /usr/lib/libMowitz.*
-rw-r--r--1 root root 400490 13 mar 18.42 /usr/lib/libMowitz.a
-rw-r--r--1 root root 717 13 mar 18.41 /usr/lib/libMowitz.la
lrwx
Junichi Uekawa:
> Without too much looking at, my first question is: why do you have
> mowitz-config in diff.gz?
It seems that it is not removed properly when doing a make distclean.
I'll fix that.
> Binary package names are incorrect, name them "lib"mowitz0 and
> "lib"mowitz-dev
Okay. I was a
Junichi Uekawa:
> Without too much looking at, my first question is: why do you have
> mowitz-config in diff.gz?
It seems that it is not removed properly when doing a make distclean.
I'll fix that.
> Binary package names are incorrect, name them "lib"mowitz0 and
> "lib"mowitz-dev
Okay. I was a
Hi!
When upgrading Siag Office to its latest version I found that parts of
the code had been broken out into a library. Since I have never before
packaged a library I would appreciate some help to check whether I am
doing things correctly or not.
Could someone please have a look at the files that
Hi!
When upgrading Siag Office to its latest version I found that parts of
the code had been broken out into a library. Since I have never before
packaged a library I would appreciate some help to check whether I am
doing things correctly or not.
Could someone please have a look at the files tha
David Given:
> E: vbcc: FSSTND-dir-in-usr usr/man/
> - --- what's this?
E: vbcc: FSSTND-dir-in-usr usr/man/
N:
N: As of policy version 3.0.0.0, Debian no longer follows the FSSTND.
N:
N: Instead, the Filesystem Hierarchy Standard (FHS), version 2.1, is
N: used. You can find it in /usr/share
David Given:
> E: vbcc: FSSTND-dir-in-usr usr/man/
> - --- what's this?
E: vbcc: FSSTND-dir-in-usr usr/man/
N:
N: As of policy version 3.0.0.0, Debian no longer follows the FSSTND.
N:
N: Instead, the Filesystem Hierarchy Standard (FHS), version 2.1, is
N: used. You can find it in /usr/shar
Sean 'Shaleh' Perry:
> looks like every other icon entry:
Exactly. That is why I am confused.
--
\\//
peter - http://www.softwolves.pp.se/
Statement concerning unsolicited e-mail according to Swedish law:
http://www.softwolves.pp.se/peter/reklampost.html
Sean 'Shaleh' Perry:
> looks like every other icon entry:
Exactly. That is why I am confused.
--
\\//
peter - http://www.softwolves.pp.se/
Statement concerning unsolicited e-mail according to Swedish law:
http://www.softwolves.pp.se/peter/reklampost.html
--
To UNSUBSCRIBE, email to [EM
Hi!
I am trying to add icons to the menu entries for the Siag suite, but I
am having problems getting the icons to be recognized. I have this in
the menu file:
?package(xsiag): needs="X11" section="Apps/Math" \
title="Siag" longtitle="Siag Office Scheme-in-a-Grid" \
command="/usr/bin/siag" ic
Hi!
I am trying to add icons to the menu entries for the Siag suite, but I
am having problems getting the icons to be recognized. I have this in
the menu file:
?package(xsiag): needs="X11" section="Apps/Math" \
title="Siag" longtitle="Siag Office Scheme-in-a-Grid" \
command="/usr/bin/siag" i
Sean 'Shaleh' Perry:
> Gregor just posted his draft of the python packaging policy. Give it a peak.
And... where do I find that?
--
\\//
peter - http://www.softwolves.pp.se/
Statement concerning unsolicited e-mail according to Swedish law:
http://www.softwolves.pp.se/peter/reklampost.html
Sean 'Shaleh' Perry:
> Gregor just posted his draft of the python packaging policy. Give it a peak.
And... where do I find that?
--
\\//
peter - http://www.softwolves.pp.se/
Statement concerning unsolicited e-mail according to Swedish law:
http://www.softwolves.pp.se/peter/reklampost.htm
Hi!
I am planning to package a Python script that will aid another package
I already have in Debian. Since I don't really know much about Python I
wonder what packages I need to depend on. Is it enough to depend on
python-base?
The script starts with these lines:
import sys
import nntplib
import
Hi!
I am planning to package a Python script that will aid another package
I already have in Debian. Since I don't really know much about Python I
wonder what packages I need to depend on. Is it enough to depend on
python-base?
The script starts with these lines:
import sys
import nntplib
impor
Peter S Galbraith:
> Sure, install the package 'g++-3.0'.
Hmm, interesting. It doesn't show up when I do dpkg -l, but obviously
apt knows about it.
--
\\//
peter - http://www.softwolves.pp.se/
Statement concerning unsolicited e-mail according to Swedish law:
http://www.softwolves.pp.se/pet
Peter S Galbraith:
> The problem is not really with hppa, but with g++-3.0.
> Here's what I do to test build (another package) using g++-3.0 :
Is it possible to get g++ 3 for i386 somewhere? That would make it a
lot easier to test if things work... :)
--
\\//
peter - http://www.softwolves.pp.se
Peter S Galbraith:
> Sure, install the package 'g++-3.0'.
Hmm, interesting. It doesn't show up when I do dpkg -l, but obviously
apt knows about it.
--
\\//
peter - http://www.softwolves.pp.se/
Statement concerning unsolicited e-mail according to Swedish law:
http://www.softwolves.pp.se/pe
Peter S Galbraith:
> The problem is not really with hppa, but with g++-3.0.
> Here's what I do to test build (another package) using g++-3.0 :
Is it possible to get g++ 3 for i386 somewhere? That would make it a
lot easier to test if things work... :)
--
\\//
peter - http://www.softwolves.pp.s
Hi!
I have created a package of the LysKOM server (ITP bug #114231). Since this
is the first server I have packaged, I would appreciate if someone would
test and see that it works well on other systems than my own... :)
The package can be found at http://www.softwolves.pp.se/deb/
It only has one
Hi!
I have created a package of the LysKOM server (ITP bug #114231). Since this
is the first server I have packaged, I would appreciate if someone would
test and see that it works well on other systems than my own... :)
The package can be found at http://www.softwolves.pp.se/deb/
It only has on
While sifting through the policy upgrade checklist for one of my
packages, I came to the information about changing mail access from
/var/spool/mail to /var/mail. That's not hard. Also, the
upgrade-checklist states that I should "[...] include a suitable
Depends field; details in [12.6]". What Depe
While sifting through the policy upgrade checklist for one of my
packages, I came to the information about changing mail access from
/var/spool/mail to /var/mail. That's not hard. Also, the
upgrade-checklist states that I should "[...] include a suitable
Depends field; details in [12.6]". What Dep
Robert Bihlmeyer:
> I'd guess English, at least the templates I look at use English in
> 'Default' even if 'Choices' was translated.
Okay. I'll try again.
> Shouldn't purging the package (i.e. debconf's PURGE command) remove
> all settings?
I ran the config script manually, so debconf said that
Robert Bihlmeyer:
> I'd guess English, at least the templates I look at use English in
> 'Default' even if 'Choices' was translated.
Okay. I'll try again.
> Shouldn't purging the package (i.e. debconf's PURGE command) remove
> all settings?
I ran the config script manually, so debconf said tha
Joey Hess:
> Yes, you can localize the Default field. Default-se or whatever.
Should I write the translated default choice in the translated language
or in English? I can't get it to work, but that's probably because I've
already saved a setting to the debconf database and can't get rid of
it.
-
Joey Hess:
> Yes, you can localize the Default field. Default-se or whatever.
Should I write the translated default choice in the translated language
or in English? I can't get it to work, but that's probably because I've
already saved a setting to the debconf database and can't get rid of
it.
Hi!
Where's the best place to put a conferencing system's database files?
I have currently put them in /var/spool/packagename/, but I'm not sure
if that's a good idea, as FHS states that spool should be for more
temporary data (this database file will be kept all time when the
conferencing system
Hi!
Where's the best place to put a conferencing system's database files?
I have currently put them in /var/spool/packagename/, but I'm not sure
if that's a good idea, as FHS states that spool should be for more
temporary data (this database file will be kept all time when the
conferencing syste
Hi!
Is it possible to have different default values to a question in
different language setups?
I am trying to package a piece of software that can be installed with
two different sets of initial data, one in English and one in Swedish,
and I wish to have the English version default when asking i
Hi!
Is it possible to have different default values to a question in
different language setups?
I am trying to package a piece of software that can be installed with
two different sets of initial data, one in English and one in Swedish,
and I wish to have the English version default when asking
Francesco P. Lovergine:
Hmmm, doesn't
> here is a blessing:
> **May you do good and not evil.
break the "No Discrimination Against Fields of Endeavor" part of DFSG?
> **May you share freely, never taking more than you give.
Not to speak of "License Must Not Contaminate Other Software".
Francesco P. Lovergine:
Hmmm, doesn't
> here is a blessing:
> **May you do good and not evil.
break the "No Discrimination Against Fields of Endeavor" part of DFSG?
> **May you share freely, never taking more than you give.
Not to speak of "License Must Not Contaminate Other Software"
Sean 'Shaleh' Perry:
> without seeing the files, why is changelog not "human readable"?
Well, because it has a lot of noise, with minor changes to files that
are not interesting for those that do not download the source package.
The NEWS file, on the other hand, just lists the actual compound
cha
Sean 'Shaleh' Perry:
> without seeing the files, why is changelog not "human readable"?
Well, because it has a lot of noise, with minor changes to files that
are not interesting for those that do not download the source package.
The NEWS file, on the other hand, just lists the actual compound
ch
Hi!
I am thinking of removing the upstream source level changelog from the
binary package for jwhois, and instead use its NEWS file, which
contains a history in human readable format. Is this wise? Is there any
policy on what should be considered the upstream changelog? Must the
source level chang
Hi!
I am thinking of removing the upstream source level changelog from the
binary package for jwhois, and instead use its NEWS file, which
contains a history in human readable format. Is this wise? Is there any
policy on what should be considered the upstream changelog? Must the
source level chan
Hi!
An NMU upload for a package that I am adopting was uplodad as if it was
a Debian native package, with a name-x.y-1.1.tar.gz with the sources,
with no diffs or orig.tar.gz. I wish to upload a new version, correct
with a diff against the orig.tar.gz. Can I somehow re-upload the
orig.tar.gz for x
Hi!
An NMU upload for a package that I am adopting was uplodad as if it was
a Debian native package, with a name-x.y-1.1.tar.gz with the sources,
with no diffs or orig.tar.gz. I wish to upload a new version, correct
with a diff against the orig.tar.gz. Can I somehow re-upload the
orig.tar.gz for
Santiago Vila:
> If you insist that the tarball must be created first, follow Julian's
> suggestion and make your package non-native by creating an .orig.tar.gz
> tarball (in this case the .diff.gz is typically the debian/* files).
I don't want to make it non-native, since that means I would have
Julian Gilbey:
> For what reason was it rejected?
Wrong syntax or wrong checksum. I couldn't manage to get the files 100%
correct, so in the end I gave up...
--
\\//
peter - http://www.softwolves.pp.se/
Statement concerning unsolicited e-mail according to Swedish law:
http://www.softwolves
Santiago Vila:
> If you insist that the tarball must be created first, follow Julian's
> suggestion and make your package non-native by creating an .orig.tar.gz
> tarball (in this case the .diff.gz is typically the debian/* files).
I don't want to make it non-native, since that means I would hav
Julian Gilbey:
> For what reason was it rejected?
Wrong syntax or wrong checksum. I couldn't manage to get the files 100%
correct, so in the end I gave up...
--
\\//
peter - http://www.softwolves.pp.se/
Statement concerning unsolicited e-mail according to Swedish law:
http://www.softwolve
Colin Watson:
> If you can't build the Debian package as part of the process of
> generating the tarball from CVS, I suppose you could use -b and hack the
> .changes by hand to include the source, although that's rather ugly.
I tried hacking the changes file by hand, but my upload got rejected th
Santiago Vila:
> Including MSWIN and OS/2 specific stuff in a Debian source tarball
> should not be a problem.
Well, the packages structure are different on the different platforms, and
also my MSWIN/OS2 source packages also contain binaries, plus that the
source is CRLF formatted there, and that
Santiago Vila:
> Oops! I understand. My suggestion is that you arrange things so that
> dpkg-buildpackage creates the one and only source tarball, instead of
> creating it in advance by hand.
I *could* do that, but that would still not solve the problem of the files
in the tarball being owned by
Colin Watson:
> If you can't build the Debian package as part of the process of
> generating the tarball from CVS, I suppose you could use -b and hack the
> .changes by hand to include the source, although that's rather ugly.
I tried hacking the changes file by hand, but my upload got rejected t
Santiago Vila:
> I would first create the Debian source and binary packages for upload,
> and then distribute the resulting tar.gz elsewhere, in that order.
The problem is that I am generating the tar from my CVS (not all of the CVS
is exported, there are some MSWIN and OS/2 specific stuff there
Mike Markley:
> You probably don't want to do this... since a native package has no
> .diff.gz, the source tarball must contain everything used to generate the
> set of binary packages you're uploading.
It does, I just untarred it to a directory and ran dpkg-buildpackage there.
I don't wnat dpkg-
Santiago Vila:
> Including MSWIN and OS/2 specific stuff in a Debian source tarball
> should not be a problem.
Well, the packages structure are different on the different platforms, and
also my MSWIN/OS2 source packages also contain binaries, plus that the
source is CRLF formatted there, and tha
Santiago Vila:
> Oops! I understand. My suggestion is that you arrange things so that
> dpkg-buildpackage creates the one and only source tarball, instead of
> creating it in advance by hand.
I *could* do that, but that would still not solve the problem of the files
in the tarball being owned by
Santiago Vila:
> I would first create the Debian source and binary packages for upload,
> and then distribute the resulting tar.gz elsewhere, in that order.
The problem is that I am generating the tar from my CVS (not all of the CVS
is exported, there are some MSWIN and OS/2 specific stuff there
Mike Markley:
> You probably don't want to do this... since a native package has no
> .diff.gz, the source tarball must contain everything used to generate the
> set of binary packages you're uploading.
It does, I just untarred it to a directory and ran dpkg-buildpackage there.
I don't wnat dpkg
Hi!
How do I get dpkg-buildpackage not to re-build the source tarball when
building a native package? No matter what I do, it rebuilds it, which
prevents me from keeping the tarball I created from my CVS tree, which
also is what I distribute elsewhere.
--
\\//
peter - http://www.softwolves.pp.se
Hi!
How do I get dpkg-buildpackage not to re-build the source tarball when
building a native package? No matter what I do, it rebuilds it, which
prevents me from keeping the tarball I created from my CVS tree, which
also is what I distribute elsewhere.
--
\\//
peter - http://www.softwolves.pp.s
Steve Langasek:
> I regularly do my own builds on two architectures before uploading, just
> to get that extra bit of testing into it.
Is there a way to upload two architectures at once, and include them in the
same .changes file?
--
\\//
peter - http://www.softwolves.pp.se/
Statement concer
Steve Langasek:
> I regularly do my own builds on two architectures before uploading, just
> to get that extra bit of testing into it.
Is there a way to upload two architectures at once, and include them in the
same .changes file?
--
\\//
peter - http://www.softwolves.pp.se/
Statement conce
Steve Langasek:
> Do you ever intend to release this software as a tarball for use outside
> of Debian?
Yes, the tarball that I create for Debian is also distributed from my
homepage (together with Debian packages compiled for potato, for those that
do not use unstable), along with a RAR package
Steve Langasek:
> Do you ever intend to release this software as a tarball for use outside
> of Debian?
Yes, the tarball that I create for Debian is also distributed from my
homepage (together with Debian packages compiled for potato, for those that
do not use unstable), along with a RAR package
Steve Langasek:
> Since this is the Debian changelog rather than an upstream changelog, the
> majority of changes noted are specific to the shared debian directory, of
> which there is precisely one for any set of binary packages that are built
> from a single source package.
Well, first of all,
Steve Langasek:
> Since this is the Debian changelog rather than an upstream changelog, the
> majority of changes noted are specific to the shared debian directory, of
> which there is precisely one for any set of binary packages that are built
> from a single source package.
Well, first of all,
Wichert Akkerman:
> You can't do that, changelogs have to be shared.
Why? The changelog lists what was changed between the versions, and that
differens between the two binary packages I created (there was a feature
only added to the command line version, not the GUI version), and I want
that refl
Wichert Akkerman:
> You can't do that, changelogs have to be shared.
Why? The changelog lists what was changed between the versions, and that
differens between the two binary packages I created (there was a feature
only added to the command line version, not the GUI version), and I want
that ref
Hi!
What does this mean?
dpkg-gencontrol: error: source package has two conflicting values - turqstat
and xturqstat
My source package "turqstat" generates two binary packages, "turqstat"
and "xturqstat". They each have their own changelogs (debian/changelog
and debian/xturqstat.changelog), and
peter karlsson:
> I'm getting a weird error from debhelper; it says that it cannot
> parse the changelog:
D'uh! I forgot I split the changelog into one per each binary package
generated from the sources. The error message was for the *other*
changelog file...
--
\
Hi!
What does this mean?
dpkg-gencontrol: error: source package has two conflicting values - turqstat and
xturqstat
My source package "turqstat" generates two binary packages, "turqstat"
and "xturqstat". They each have their own changelogs (debian/changelog
and debian/xturqstat.changelog), and
peter karlsson:
> I'm getting a weird error from debhelper; it says that it cannot
> parse the changelog:
D'uh! I forgot I split the changelog into one per each binary package
generated from the sources. The error message was for the *other*
changelog file...
--
\
Eric Van Buggenhaut:
> > .
> ^^^
> You sure about that period ?
It's just in the parsed output, not in the original, and I think is
supposed to look like that.
--
\\//
peter - http://www.softwolves.pp.se/
Statement concerning unsolicited e-mail according to Swedish law:
http://www.sof
Eric Van Buggenhaut:
> > .
> ^^^
> You sure about that period ?
It's just in the parsed output, not in the original, and I think is
supposed to look like that.
--
\\//
peter - http://www.softwolves.pp.se/
Statement concerning unsolicited e-mail according to Swedish law:
http://www.so
file
dh_gencontrol: command returned error code
make: *** [binary-arch] Error 1
===[ cut ]===
The weird thing with it is that dpkg-parsechangelog does not give any
errors:
===[ cut ]===
$ dpkg-parsechangelog ; echo $?
Source: turqstat
Version: 2.1
Distribution: unstable
Urgency: low
Maintainer: peter kar
e character sets used in
Fidonet and Usenet today.
-- peter karlsson <[EMAIL PROTECTED]> Tue, 17 Jul 2001 22:45:00 +0200
===[ cut ]===
It complains about line 6, which is part of the comment. This is really
weird, does anyone have any ideas?
--
\\//
peter - http://www.softwolves.pp
Hi!
Can a single binary package have a different name than the source package it
comes from?
I am packaging the LysKOM tty-client, which has the upstream name
tty-client, but I have received requests for renaming the Debian package to
lyskom-tty-client. Can I do that without changing the name of
1 - 100 of 224 matches
Mail list logo
