On Fri, Jan 21, 2022 at 10:31:38AM +0100, Markus Blatt wrote:
> > When I look at the package tracker https://tracker.debian.org/pkg/opm-common
> > I see "unsatisfied dependency on libfmt7 (>= 7.1.3+ds1)" that is blocking
> > migration to testing. Current version of libfmt in unstable is 8.1.1+ds1-2
Hi
Am Fri, Jan 21, 2022 at 10:06:22AM +0100 schrieb Markus Blatt:
When I look at the package tracker https://tracker.debian.org/pkg/opm-common
I see "unsatisfied dependency on libfmt7 (>= 7.1.3+ds1)" that is blocking
migration to testing. Current version of libfmt in unstable is 8.1.1+ds1-2.
A
I have revised the previous iteration of Debian patch for libshairplay,
specifically fixed
the source package name to match upstream repository name.
Now Lintian throws an error "Package closes bugs in wrong way" despite of
retitle.
I am closing this bug and opening a new RFS w
Hi,
I am in the process to rename one of my packages (source and binary
packages), from "sextractor" to "source-extractor" (see #941466 for
rationale).
For this, I followed the Wiki; in d/control:
Package: source-extractor
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}
Breaks: sex
I don't know anything about anything about Python, but if packaging
policy says that the package name should be named after the module name,
and it turns out that the package name is too generic or misleading or
otherwise inadequate, then that's only because the module name had
exac
hi,
i'm in the process of packaging protobuf3:
https://github.com/Pr0Ger/protobuf3
this is an implementation of protocol buffers 2 for python 3.
according to debian policy, this should be named python3-protobuf3, but
i think this name isn't ideal, because it could be mistaken for:
a) an imp
Hi!
lumin writes:
> A package-name-conflicting RFP [4] was found.
>
> Description : Free software alternative for xv image viewer
>
> I have no idea about how to handle this name conflict.
> Any advice or guide?
As this is a 3 years old *Request* withou
Hi mentors,
Initially I intend to package cv ITP : [1]
* Description : cv - Coreutils (progress) Viewer
Then I checked the packages.d.o avoiding package name conflict [2],
there is indeed no package named "cv" for any suites.
However immediate after I filed the RFS
Hi,
I am trying to sponsor ocrodjvu but if I build it in a recent
sid/chroot here is what I see:
$ lintian -I
/tmp/d/d/ocrodjvu-0.7.16/../build-area/ocrodjvu_0.7.16-1_amd64.changes
E: ocrodjvu: bad-provided-package-name python:any
I: ocrodjvu: spelling-error-in-manpage
usr/share/man/man1
T o n g writes:
> On Tue, 25 Jun 2013 20:45:15 -0700, Russ Allbery wrote:
>> The typical thing to do in this sort of situation is to document the
>> required modification in README.Debian; it's not entirely satisfactory,
>> but sometimes there isn't another good option.
> Understand & will do. S
On Tue, 25 Jun 2013 20:45:15 -0700, Russ Allbery wrote:
> If you need to customize *only* /etc/pam.d/sudo, I'm afraid that Debian
> Policy says you're not allowed to do that. Basically, configuration
> files are owned by a single package, and only that package may modify
> it. That package *can*
* Tomasz Muras [100824 19:34]:
> So to summarize:
> dfsg is a conventional way of naming a package, when the original
> source has been changed. It usually happens when upstream software
> contains some non-free elements.
I do not think using "dfsg" makes sense if it was not repacked to
remove no
in
README.Debian-source.
The recommended way of naming a package with the 'dfsg' bit is:
+dfsg-
For example:
I have packaged foobar application which has just released version
1.2.3. Normally the package name would be: abc_1.2.3-1 - and it was
packaged as such.
I have then discovered that th
On Fri, Aug 20, 2010 at 1:00 AM, Ludovico Cavedon wrote:
> On Thu, Aug 19, 2010 at 1:39 AM, Paul Wise wrote:
>> I personally can't think of any situation where ~dfsg is useful.
>
> If I want to rebuild a package including the non-free bits, I could
> just remove the "~dfsg" from the version and h
On Thu, Aug 19, 2010 at 1:39 AM, Paul Wise wrote:
> I personally can't think of any situation where ~dfsg is useful.
If I want to rebuild a package including the non-free bits, I could
just remove the "~dfsg" from the version and have it win over the one
the official repository.
Still, it is not
On Thu, Aug 19, 2010 at 7:08 AM, Felipe Sateler wrote:
> And if there are any prospects of upstream cleaning up their tree, the ~
> symbol makes it possible to re-release the same tarball without the
> offending files.
It would be better if upstream just incremented their version than
re-release
Felipe Sateler writes:
> And if there are any prospects of upstream cleaning up their tree, the ~
> symbol makes it possible to re-release the same tarball without the
> offending files.
Yes, either ~ or + will work provided that you haven't just realized that
upstream has files that have to be
On 18/08/10 18:23, gregor herrmann wrote:
> On Wed, 18 Aug 2010 22:42:09 +0100, Tomasz Muras wrote:
>
>> Is there any preference/reasoning for using any particular symbol that
>> joins "dfsg" bit with the package name? I can see that different
>> packages use
On Wed, 18 Aug 2010 22:42:09 +0100, Tomasz Muras wrote:
> Is there any preference/reasoning for using any particular symbol that
> joins "dfsg" bit with the package name? I can see that different
> packages use a different format, here are some quick stats from packages
>
Hi Mentors,
Is there any preference/reasoning for using any particular symbol that
joins "dfsg" bit with the package name? I can see that different
packages use a different format, here are some quick stats from packages
in unstable (with the counts):
1179 +dfsg
1119 .dfsg
lly hard not to change your source
package name. So hopefully whatever name you're switching to is one
that you'll keep and won't have to switch again.
[The reason why you don't want to change your source package name
gratuitously is because it makes tracking bug versioning more
OoO En cette soirée bien amorcée du mercredi 23 juillet 2008, vers
22:04, SZÉKELYI Szabolcs <[EMAIL PROTECTED]> disait :
> I would like to change the name of a source package; is there anything
> non-package-specific thing to do apart from simply using the new name in
> debian/changelog? I m
.
Also need to change the source package name in debian/control
--
bye,
pabs
http://wiki.debian.org/PaulWise
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I would like to change the name of a source package; is there anything
non-package-specific thing to do apart from simply using the new name in
debian/changelog? I mean adding new header fields, etc.
Thanks,
- --
cc
-BEGIN PGP SIGNATURE-
a dev package for each) - libopenvas and libopenvas_hg. However I'm now
> > getting complaints that the package name of libopenvas_hg is illegal.
> Multiple library packages are only useful if the libraries are going to
> change independently (and probably only useful if applicatio
braries, libopenvas and libopenvas_hg and I was getting
> complaints that libopenvas didn't match the SONAME (for
> libopenvas_hg.so), so I broke it down into one package per library (and
> a dev package for each) - libopenvas and libopenvas_hg. However I'm now
> getting complai
1]).
1. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=27;bug=459851
> so I broke it down into one package per library (and a dev package for
> each) - libopenvas and libopenvas_hg. However I'm now getting
> complaints that the package name of libopenvas_hg is illegal.
It'
aints that
libopenvas didn't match the SONAME (for libopenvas_hg.so), so I broke it down
into one package per library (and a dev package for each) - libopenvas and
libopenvas_hg. However I'm now getting complaints that the package name of
libopenvas_hg is illegal.
I am involved in the u
ble-rpath flag, though (testing right now).
>
> prefixes in the Makefile.am.
>
> GnuCash is a great one for private libraries, it has dozens and dozens.
> Take a look at that source. All these use an rpath and none need to be
> concerned about /usr/lib, only /usr/lib/gnucash/foo/
be
concerned about /usr/lib, only /usr/lib/gnucash/foo/
Then compare with libqof1 which has public libraries with SONAME
and a package name that matches the SONAME etc.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpQiYtXIqAPk.pgp
Description: PGP signature
Neil Williams wrote:
> On Sun, 14 Oct 2007 23:10:52 -0200
> Eriberto <[EMAIL PROTECTED]> wrote:
>
>> Hi mentors!
>>
>> I am packaging a tool to translate words (KTranslator). I fixed some
>
> Your most important comment is right at the end:
>
>> The libs are specifics to this program.
>
> In
I understand now. It worked fine. Thanks.
Regards,
Eriberto - Brazil
Neil Williams escreveu:
> In which case, the libs MUST NOT be in /usr/lib/ but in /usr/lib/foo -
> in your case probably /usr/lib/ktranslator/. Then lintian won't bother
> you. You aren't building a library package, you are bui
On Sun, 14 Oct 2007 23:10:52 -0200
Eriberto <[EMAIL PROTECTED]> wrote:
> Hi mentors!
>
> I am packaging a tool to translate words (KTranslator). I fixed some
Your most important comment is right at the end:
> The libs are specifics to this program.
In which case, the libs MUST NOT be in /usr/l
Hi mentors!
I am packaging a tool to translate words (KTranslator). I fixed some
warnings and erros showed by lintian. But I don't understood very well
this warning:
W: ktranslator: package-name-doesnt-match-sonames
libktranslatordictionaryinterfaces0 libktranslatoruiinterfaces0
The linti
ve/build standpoint, I agree. It would, however,
possibly result in users of oldstable getting the former replaced
with the latter if it (and its dependencies) stuck around during an
upgrade, so I understand the need to, at a minimum, have one release
between removal and reuse of the same binary pac
s not to confuse people who assume package name == what
> you run). The only reason I packaged it as "weather-util" is that
> there's already a completely unrelated "weather" package in
> sarge/non-free (interactive fiction data in the games section).
The difference
rchived?
[...]
I'm in a similar situation with the weather-util package. Upstream
(also me) releases it as just "weather" and the package installs a
command line utility /usr/bin/weather (though a weather-util symlink
is added so as not to confuse people who assume package name ==
maintain).
>> This new script is backward-compatible with the old one, and has some
>> new features too.
>>
>> If I want to package the new script, is it better to choose a
>> different name (something like mrename-ng) or keep the same?
>
> Keep same package
>
> If I want to package the new script, is it better to choose a
> different name (something like mrename-ng) or keep the same?
Keep same package name and add the new script. Rename the old
script to "mrename-old" or similar if you want to keep it around, but
there is no ne
Hi!
A Debian user some time ago sent me a script very similar to mrename (which I
maintain).
This new script is backward-compatible with the old one, and has some new
features too.
If I want to package the new script, is it better to choose a different name
(something like mrename-ng) or kee
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 22 Jan 2006 00:18:57 +0100
Rakotomandimby Mihamina <[EMAIL PROTECTED]>
wrote:
> I want to Debian package the little "shout-python" software:
> http://icecast.org/download.php
> (in the midle of the page)
>
> The upstream tarball is:
> http://
Hi,
I want to Debian package the little "shout-python" software:
http://icecast.org/download.php
(in the midle of the page)
The upstream tarball is:
http://downloads.us.xiph.org/releases/libshout/shout-python-0.2.tar.gz
What name should I give to it?
- libhsout-python ?
- python-shout ?
- shout-
Hello thomas,
Thomas Viehmann wrote:
-p, --packagename
Thank you for that tip.
I have updated the packages [1]. Have anyone other suggestions that I
can make better?
Greets,
Jonas
[1] http://jonas.capi2name.de/mod-cband/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a sub
On Wed, Oct 12, 2005 at 05:01:22PM +0200, Thomas Viehmann wrote:
> Hi.
>
> Jonas Genannt wrote:
> > So than I run dh_make to make a initial debianize:
> > dh_make -e [EMAIL PROTECTED] -f ../mod-cband-0.9.5.tgz
> > Package name "mod_cband" is not in a valid
Hi.
Jonas Genannt wrote:
> So than I run dh_make to make a initial debianize:
> dh_make -e [EMAIL PROTECTED] -f ../mod-cband-0.9.5.tgz
> Package name "mod_cband" is not in a valid format.
>
> So that should I do?
You could skip dh_make or try dh_make(8)'s recom
nd messing with the upstream source tarball unless you have
problematically licensed material in it.
the upstream tarball:
mod_cband-0.9.5.tgz
after extracted: mod_cband-0.9.5
So than I run dh_make to make a initial debianize:
dh_make -e [EMAIL PROTECTED] -f ../mod-cband-0.9.5.tgz
Package name
Jonas Genannt wrote:
> The problem is, that the source package has the following name:
> mod_cband-0.9.5.tgz
If I understand correctly, it is not the source package but the upstream
tarball worring you?
> So I have done:
> extract the original package.
> renamed the folder to: mod-cband-0.9.5/
> cr
tualhost's
transfer limit is exceeded, mod_cband will redirect all further requests
to a location specified in the configuration file.
The problem is, that the source package has the following name:
mod_cband-0.9.5.tgz
But Debian Policy forbids a _ in the source package name.
So I have do
On Mon, May 23, 2005 at 12:44:47PM +0300, Shachar Shemesh wrote:
> Steve Langasek wrote:
> >The risk is that you can't install the new -dev package on a system that
> >has
> >the old lib installed, because they conflict. One normally wants to be
> >able
> >to build and test binaries for a new l
Steve Langasek wrote:
The risk is that you can't install the new -dev package on a system that has
the old lib installed, because they conflict. One normally wants to be able
to build and test binaries for a new library *before* purging the old
version of the library...
But the -dev package
On Sun, May 22, 2005 at 01:07:38PM +0300, Shachar Shemesh wrote:
> >>Another thing that comes up is an incompatibility between the deb
> >>currently provided by the site (as well as binaries compiled with
> >>libargtable compiled from source) and the deb we would provide. Binaries
> >>compiled w
Steve Langasek wrote:
But if I do introduce SONAME to the Debian version, what version should
it have? The only sensible answer that I can think of is "0", as any
other answer is sure to conflict with the upstream choice, should they
come to their senses in the future. I don't see the major di
On Sat, May 21, 2005 at 01:16:57PM +0300, Shachar Shemesh wrote:
> Steve Langasek wrote:
> >>I have still not totally given up on convincing him, though, so I'll be
> >>in touch :-)
> >It's not acceptable to install a shared library without an SONAME for two
> >reasons:
> >- if the library'
Steve Langasek wrote:
I have still not totally given up on convincing him, though, so I'll be
in touch :-)
It's not acceptable to install a shared library without an SONAME for two
reasons:
- if the library's ABI changes and the filename doesn't change, the new
library package will
an.
> >So your options for this one are limited - you need to retain binary
> >compatibility and can't go changing the SONAME or package name without
> >breaking things. You CAN implement a SONAME where one is missing, but I
> >don't see that skipping 1 is going
can't go changing the SONAME or package name without
breaking things. You CAN implement a SONAME where one is missing, but I don't
see that skipping 1 is going to be any good.
I think a more interesting question is whether I can NOT implement
SONAME where one is missing? It seems tha
ng the SONAME or package name without
breaking things. You CAN implement a SONAME where one is missing, but I don't
see that skipping 1 is going to be any good.
> I'm not sure binary incompatible is strictly defined with argtable.
It's down to the exported functions - you won'
l problems - leave a place if anyone decides to package version 1, and
yet be compatible.
See the archive:
http://lists.debian.org/debian-mentors/2005/05/msg00057.html
That's what triggered the question to begin with.
Obviously, I will need to ad a "lib" at the beginning.
I was won
argtable2-4, then. I used that script to decide on the name to begin
with.
For the devel package I would take the binary package name without
the SONAME like libargtable2-dev.
Probably a good idea, yes.
I'm having doubts about all choices, however:
Should the source be named "argta
this:
source package: argtable2
shared object: libargtable2-4
devel: libargtable2-4-dev
(Donated by Steve Langasek)
$ objdump -p /path/to/libfoo-bar.so.1.2.3 | sed -n -e's/^[[:space:]]
*SONAME[[:space:]]*//p' | sed -e's/\([0-9]\)\.so\./\1-/; s/\.so\.//'
For the devel package I wo
ering about that - IS it actually mandatory?
I've got:
qof-0.5.2.tar.gz
I can have a package name:
qof1
leading to a library of
qof1.so
It'll be installed as a library, determined by debian/control, but does the
file actually have to be prefixed lib to make libqof1.so?
> At the
Hi list,
I'm trying to package argtable (http://argtable.sf.net). I'm wondering
about the names to give the package.
The package itself had two major life cycles. As such, the source
library is called "argtable2". As far as so version goes, it has version
4. Obviously, I will need to ad a "lib"
Tilman Koschnick <[EMAIL PROTECTED]> wrote:
> One question though: Is there any problem if my
> c3-tool-suite_4.0.1.orig.tar.gz unpacks into c3-4.0.1/? dpkg-source and
> dpkg-buildpackage don't seem to have a problem with it, but are there
> any other pitfalls with differing upstream-tarball names
Am 2004-12-28 15:03:33, schrieb Tilman Koschnick:
> One question though: Is there any problem if my
> c3-tool-suite_4.0.1.orig.tar.gz unpacks into c3-4.0.1/? dpkg-source and
> dpkg-buildpackage don't seem to have a problem with it, but are there
> any other pitfalls with differing upstream-tarball
Am 2004-12-22 00:25:59, schrieb Tilman Koschnick:
> Hi,
>
> I'm intending to package the Cluster Command & Control tool suite [0],
> commonly refered to as C3. My package name of choice would be c3, but I
> was wondering if such short names are acceptable. Is there any
&g
On Thu, 2004-12-23 at 11:16 +0100, Frank Küster wrote:
> Tilman Koschnick <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > I'm intending to package the Cluster Command & Control tool suite [0],
> > commonly refered to as C3. My package name of choice would
Tilman Koschnick <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm intending to package the Cluster Command & Control tool suite [0],
> commonly refered to as C3. My package name of choice would be c3, but I
> was wondering if such short names are acceptable. Is there
On Wed, 2004-12-22 at 00:51, Stephan Beyer wrote:
> Hi,
>
> > When looking at the existing names, I noticed that there are no package
> > names with only two characters, and not that many with three.
>
> apt-cache show mc dc bc
> to name a few ;)
>
> best regards,
> sbeyer
D'oh! I was counting
On Wed, Dec 22, 2004 at 12:25:59AM +0100, Tilman Koschnick wrote:
> When looking at the existing names, I noticed that there are no package
> names with only two characters, and not that many with three.
except for : af an at bb bc bl cu cw dc di dx ed ee es fv gb gq gs gv hf
ht hx im kq le lv m4
Hi,
> When looking at the existing names, I noticed that there are no package
> names with only two characters, and not that many with three.
apt-cache show mc dc bc
to name a few ;)
best regards,
sbeyer
--
Stephan Beyer 0xFCC5040F
IANADD http://www.noxa.de/~sbeyer/debian/
signature.asc
Desc
Hi,
I'm intending to package the Cluster Command & Control tool suite [0],
commonly refered to as C3. My package name of choice would be c3, but I
was wondering if such short names are acceptable. Is there any
documentation or general consent?
When looking at the existing names, I not
On 20041118T094050+1100, Matthew Palmer wrote:
> From what I can see, the package wouldn't provide anything useful at
> runtime, which is the intent of lib* package (IMO), and a lib*-dev package
> is for providing build-time stuff for a lib* package, so straight up
> pstreams seems like a winner to
On 20041118T094050+1100, Matthew Palmer wrote:
> From what I can see, the package wouldn't provide anything useful at
> runtime, which is the intent of lib* package (IMO), and a lib*-dev package
> is for providing build-time stuff for a lib* package, so straight up
> pstreams seems like a winner to
On Wed, Nov 17, 2004 at 11:37:16PM +0100, martin f krafft wrote:
> also sprach Antonio S. de A. Terceiro <[EMAIL PROTECTED]> [2004.11.17.2330
> +0100]:
> > libfactory++-dev - C++ template factory framework
>
> ... that this is my software, which I named libfactory because I did
> not know better.
also sprach Antonio S. de A. Terceiro <[EMAIL PROTECTED]> [2004.11.17.2330
+0100]:
> I'm finishing a package for PStreams (pstreams.sf.net), and the
> name I gave at first for the package was "pstreams". But maybe the
> correct name should be "libpstreams".
I should note that I asked the question
Hello all,
I'm finishing a package for PStreams (pstreams.sf.net), and the name I
gave at first for the package was "pstreams". But maybe the correct name
should be "libpstreams".
Well, PStreams is in fact a library, in the sense it's a set of reusable
code. But since it's implemented as C++ temp
On Wed, Nov 17, 2004 at 11:37:16PM +0100, martin f krafft wrote:
> also sprach Antonio S. de A. Terceiro <[EMAIL PROTECTED]> [2004.11.17.2330
> +0100]:
> > libfactory++-dev - C++ template factory framework
>
> ... that this is my software, which I named libfactory because I did
> not know better.
also sprach Antonio S. de A. Terceiro <[EMAIL PROTECTED]> [2004.11.17.2330
+0100]:
> I'm finishing a package for PStreams (pstreams.sf.net), and the
> name I gave at first for the package was "pstreams". But maybe the
> correct name should be "libpstreams".
I should note that I asked the question
Hello all,
I'm finishing a package for PStreams (pstreams.sf.net), and the name I
gave at first for the package was "pstreams". But maybe the correct name
should be "libpstreams".
Well, PStreams is in fact a library, in the sense it's a set of reusable
code. But since it's implemented as C++ temp
hello frank..
sorry that it took so long, but i had my head full of other stuff
lately.
* Frank Küster <[EMAIL PROTECTED]> [2004-08-23 11:20 +0200]:
> Sebastian Henschel <[EMAIL PROTECTED]> schrieb:
>
> > i am the maintainer of irda-utils which recently got this bug filed
> > against it:
> > htt
hello frank..
sorry that it took so long, but i had my head full of other stuff
lately.
* Frank Küster <[EMAIL PROTECTED]> [2004-08-23 11:20 +0200]:
> Sebastian Henschel <[EMAIL PROTECTED]> schrieb:
>
> > i am the maintainer of irda-utils which recently got this bug filed
> > against it:
> > htt
On 2004-08-23 Sebastian Henschel <[EMAIL PROTECTED]> wrote:
[...]
> the problem is that the package(s) in stable are called irda-tools and
> irda-common and the current version is called irda-utils. when doing a
> dist-ugprade from stable to unstable, irda-tools and irda-common are
> not replaced a
Sebastian Henschel <[EMAIL PROTECTED]> schrieb:
> hello list...
>
> i am the maintainer of irda-utils which recently got this bug filed
> against it:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267278
>
> the fix suggested there does not work.
> the problem is that the package(s) in stable
hello list...
i am the maintainer of irda-utils which recently got this bug filed
against it:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267278
the fix suggested there does not work.
the problem is that the package(s) in stable are called irda-tools and
irda-common and the current version i
On 2004-08-23 Sebastian Henschel <[EMAIL PROTECTED]> wrote:
[...]
> the problem is that the package(s) in stable are called irda-tools and
> irda-common and the current version is called irda-utils. when doing a
> dist-ugprade from stable to unstable, irda-tools and irda-common are
> not replaced a
Sebastian Henschel <[EMAIL PROTECTED]> schrieb:
> hello list...
>
> i am the maintainer of irda-utils which recently got this bug filed
> against it:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267278
>
> the fix suggested there does not work.
> the problem is that the package(s) in stable
hello list...
i am the maintainer of irda-utils which recently got this bug filed
against it:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267278
the fix suggested there does not work.
the problem is that the package(s) in stable are called irda-tools and
irda-common and the current version i
On Friday 06 August 2004 05:32 pm, Christoffer Sawicki wrote:
> Do you think the package name should be gtk-qt-engine or
> gtk2-engines-gtk-qt?
IMHO, you should keep the name you are using. It is nice to be able to do
"apt-cache search ^gtk2-engines" and see all the GT
On Friday 06 August 2004 05:32 pm, Christoffer Sawicki wrote:
> Do you think the package name should be gtk-qt-engine or
> gtk2-engines-gtk-qt?
IMHO, you should keep the name you are using. It is nice to be able to do
"apt-cache search ^gtk2-engines" and see all the GT
> I would *never* blindly trust upstream to choose a name that is sane for
> Debian. The upstream name (gtk-qt) is particularly poor in this case.
The upstream name is actually gtk-qt-engine.
*/ Christoffer Sawicki <[EMAIL PROTECTED]>
> I would *never* blindly trust upstream to choose a name that is sane for
> Debian. The upstream name (gtk-qt) is particularly poor in this case.
The upstream name is actually gtk-qt-engine.
*/ Christoffer Sawicki <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subje
The name is currently gtk2-engines-gtk-qt which is sort
> > of right since the package contains a GTK2 theme engine. However, it's not
> > a
> > standard theme engine since it depends on Qt for its drawing and is
> > configured through KControl.
> >
> >
is currently gtk2-engines-gtk-qt which is sort
> > of right since the package contains a GTK2 theme engine. However, it's not a
> > standard theme engine since it depends on Qt for its drawing and is
> > configured through KControl.
> >
> > Do you th
ontains a GTK2 theme engine. However, it's not a
> standard theme engine since it depends on Qt for its drawing and is
> configured through KControl.
>
> Do you think the package name should be gtk-qt-engine or gtk2-engines-gtk-qt?
>
> Please CC me, I'm not on the list.
>
rawing and is
configured through KControl.
Do you think the package name should be gtk-qt-engine or gtk2-engines-gtk-qt?
Please CC me, I'm not on the list.
[0] http://www.freedesktop.org/Software/gtk-qt
*/ Christoffer Sawicki <[EMAIL PROTECTED]>
ontains a GTK2 theme engine. However, it's not a
> standard theme engine since it depends on Qt for its drawing and is
> configured through KControl.
>
> Do you think the package name should be gtk-qt-engine or gtk2-engines-gtk-qt?
>
> Please CC me, I'm not on the list.
>
rawing and is
configured through KControl.
Do you think the package name should be gtk-qt-engine or gtk2-engines-gtk-qt?
Please CC me, I'm not on the list.
[0] http://www.freedesktop.org/Software/gtk-qt
*/ Christoffer Sawicki <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EM
I'm packaging polipo, the web proxy.
To help with starting, stopping etc. I wrote a helper script
"polipo-control" that I put in /usr/lib/polipo/. It is called by
/etc/init.d/polipo.
How can I make this script executable? Can I get dh_install or another
debhelper script to do it somehow or shal
I'm packaging polipo, the web proxy.
To help with starting, stopping etc. I wrote a helper script
"polipo-control" that I put in /usr/lib/polipo/. It is called by
/etc/init.d/polipo.
How can I make this script executable? Can I get dh_install or another
debhelper script to do it somehow or shal
I firmly believe the ancient pagan, hebrew, and Christian tradition that
To Know Something's Name Is To Control It.
My package is named pim. It might be aleithia (gr. "truth", literally
"unhidden; to shine light on") or it might be tbpim or it might be tdb
(Tom Ballard Database) or it might be
1 - 100 of 199 matches
Mail list logo
