Re: irda-utils: howto dist-upgrade when package name has changed?
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:
> > 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 is called irda-utils. when doing a
> > dist-ugprade from stable to unstable, irda-tools and irda-common are
> > not replaced automatically by irda-utils. how can i handle this?
> > irda-utils defines:
> >
> > Replaces: irda-common, irda-tools
> > Provides: irda-tools
> > Conflicts: irda-common, irda-tools
> >
> > but that does not seem to suffice. is a pseudo-package irda-tools
> > necessary which depends on irda-utils?
>
> I think it can be done with Replaces/Provides/Conflicts.
>
> - Did you try with "Provides: irda-common, irda-tools"
yes, if modifying
/var/lib/apt/lists/ftp.de.debian.org_debian_dists_unstable_main_binary-powerpc_Packages
is enough. i did not upload another version of irda-utils to the
Debian archives.
> - What does apt say if you do the dist-upgrade from woody to sid/sarge
> with /etc/apt/apt.conf.d/10debug containing
>
> Debug
> {
> pkgProblemResolver "true";
> pkgAcquire "false";
> pkgAcquire::Worker "false";
> pkgDPkgPM "false";
> pkgOrderList "false";
>
> pkgInitialize "false"; // This one will dump the configuration space
> NoLocking "false";
> Acquire::Ftp "false";// Show ftp command traffic
> Acquire::Http "false"; // Show http command traffic
> aptcdrom "false";// Show found package files
> }
does not seem to give any more hints:
fuchi:/# apt-get dist-upgrade
Reading Package Lists...
Building Dependency Tree...
Starting
Starting 2
Investigating libconsole
Package libconsole has broken dep on console-tools-libs
Considering console-tools-libs 4 as a solution to libconsole 10
Added console-tools-libs to the remove list
Fixing libconsole via remove of console-tools-libs
Done
The following packages will be REMOVED:
console-tools-libs
The following NEW packages will be installed:
aptitude coreutils debconf-i18n dselect e2fslibs gcc-3.3-base initscripts
libacl1 libattr1 libblkid1 libcomerr2 libconsole libdb1-compat libdb3-util
libdb4.2 libgcc1 libgcrypt11 libgdbm3 libgnutls11 libgpg-error0
liblocale-gettext-perl liblzo1 libopencdk8 libpcap0.7 libsasl2
libsigc++-1.2-5c102 libss2 libssl0.9.7 libstdc++5 libtasn1-2
libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libuuid1
slang1a-utf8 sysv-rc zlib1g
96 packages upgraded, 37 newly installed, 1 to remove and 0 not upgraded.
Need to get 23.3MB/33.8MB of archives. After unpacking 32.9MB will be used.
Do you want to continue? [Y/n] n
Abort.
the Woody distribution was debootstrapped two weeks ago, as well as the
update of the unstable apt-sources.
thanks,
sebastian
--
::: .O.
::: ..O
::: OOO
::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import
signature.asc
Description: Digital signature
Re: irda-utils: howto dist-upgrade when package name has changed?
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:
> > 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 is called irda-utils. when doing a
> > dist-ugprade from stable to unstable, irda-tools and irda-common are
> > not replaced automatically by irda-utils. how can i handle this?
> > irda-utils defines:
> >
> > Replaces: irda-common, irda-tools
> > Provides: irda-tools
> > Conflicts: irda-common, irda-tools
> >
> > but that does not seem to suffice. is a pseudo-package irda-tools
> > necessary which depends on irda-utils?
>
> I think it can be done with Replaces/Provides/Conflicts.
>
> - Did you try with "Provides: irda-common, irda-tools"
yes, if modifying
/var/lib/apt/lists/ftp.de.debian.org_debian_dists_unstable_main_binary-powerpc_Packages
is enough. i did not upload another version of irda-utils to the
Debian archives.
> - What does apt say if you do the dist-upgrade from woody to sid/sarge
> with /etc/apt/apt.conf.d/10debug containing
>
> Debug
> {
> pkgProblemResolver "true";
> pkgAcquire "false";
> pkgAcquire::Worker "false";
> pkgDPkgPM "false";
> pkgOrderList "false";
>
> pkgInitialize "false"; // This one will dump the configuration space
> NoLocking "false";
> Acquire::Ftp "false";// Show ftp command traffic
> Acquire::Http "false"; // Show http command traffic
> aptcdrom "false";// Show found package files
> }
does not seem to give any more hints:
fuchi:/# apt-get dist-upgrade
Reading Package Lists...
Building Dependency Tree...
Starting
Starting 2
Investigating libconsole
Package libconsole has broken dep on console-tools-libs
Considering console-tools-libs 4 as a solution to libconsole 10
Added console-tools-libs to the remove list
Fixing libconsole via remove of console-tools-libs
Done
The following packages will be REMOVED:
console-tools-libs
The following NEW packages will be installed:
aptitude coreutils debconf-i18n dselect e2fslibs gcc-3.3-base initscripts
libacl1 libattr1 libblkid1 libcomerr2 libconsole libdb1-compat libdb3-util
libdb4.2 libgcc1 libgcrypt11 libgdbm3 libgnutls11 libgpg-error0
liblocale-gettext-perl liblzo1 libopencdk8 libpcap0.7 libsasl2
libsigc++-1.2-5c102 libss2 libssl0.9.7 libstdc++5 libtasn1-2
libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libuuid1
slang1a-utf8 sysv-rc zlib1g
96 packages upgraded, 37 newly installed, 1 to remove and 0 not upgraded.
Need to get 23.3MB/33.8MB of archives. After unpacking 32.9MB will be used.
Do you want to continue? [Y/n] n
Abort.
the Woody distribution was debootstrapped two weeks ago, as well as the
update of the unstable apt-sources.
thanks,
sebastian
--
::: .O.
::: ..O
::: OOO
::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import
signature.asc
Description: Digital signature
irda-utils: howto dist-upgrade when package name has changed?
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 is called irda-utils. when doing a dist-ugprade from stable to unstable, irda-tools and irda-common are not replaced automatically by irda-utils. how can i handle this? irda-utils defines: Replaces: irda-common, irda-tools Provides: irda-tools Conflicts: irda-common, irda-tools but that does not seem to suffice. is a pseudo-package irda-tools necessary which depends on irda-utils? thanks for suggestions, sebastian -- ::: .O. ::: ..O ::: OOO ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import signature.asc Description: Digital signature
irda-utils: howto dist-upgrade when package name has changed?
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 is called irda-utils. when doing a dist-ugprade from stable to unstable, irda-tools and irda-common are not replaced automatically by irda-utils. how can i handle this? irda-utils defines: Replaces: irda-common, irda-tools Provides: irda-tools Conflicts: irda-common, irda-tools but that does not seem to suffice. is a pseudo-package irda-tools necessary which depends on irda-utils? thanks for suggestions, sebastian -- ::: .O. ::: ..O ::: OOO ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import signature.asc Description: Digital signature
Re: preinst, postinst, etc
hello ashraf... * Ashraf Emawi <[EMAIL PROTECTED]> [2004-08-16 15:33 +0200]: > hi all, > i try to build debian-package of a small programm, and i used dh_make to > get some help. under the directory DEBIAN/ i got files like rules, > copyright, preinst.ex, postinst.ex, etc... after building package and > when i try to install my package, preinstall and postinstall will not be > used, can you help me please, and say how can i use the both scripts in > my package. please point us to a location where we can download your source package. cheers, sebastian -- ::: .O. ::: ..O ::: OOO ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import signature.asc Description: Digital signature
Re: preinst, postinst, etc
hello ashraf... * Ashraf Emawi <[EMAIL PROTECTED]> [2004-08-16 15:33 +0200]: > hi all, > i try to build debian-package of a small programm, and i used dh_make to > get some help. under the directory DEBIAN/ i got files like rules, > copyright, preinst.ex, postinst.ex, etc... after building package and > when i try to install my package, preinstall and postinstall will not be > used, can you help me please, and say how can i use the both scripts in > my package. please point us to a location where we can download your source package. cheers, sebastian -- ::: .O. ::: ..O ::: OOO ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import signature.asc Description: Digital signature
Re: RFTS: irda-utils
hello.. 10 minutes after i sent this, i got my account @debian.org... so forget about the sponsor thing, but you might have a look at it, anyway. :) bye, sebastian * Sebastian Henschel <[EMAIL PROTECTED]> [2004-07-28 16:21 +0200]: > as my current sponsor has to renew his gpg-key and the freeze for sarge > is about to happen in the foreseeable future, i hereby put a request for > a temporary sponsor for the package irda-utils. some important things have > changed from -4 to -5, so i believe to need a couple of uploads to the > archive until irda-utils will be fit for sarge. > > Name: irda-utils > License: GPL > Short description: IrDA management and handling utilities > Long description: > This package contains userspace utilities to manage and handle infrared > devices. It includes irattach, findchip, irdadump, irdaping and > irpsion5. > OBEX tools are removed since 0.9.5. If you need to use IrOBEX, > use openobex-apps package. > . > Authors: Dag Brattli <[EMAIL PROTECTED]> and >Jean Tourrilhes <[EMAIL PROTECTED]> > Homepage: http://irda.sourceforge.net > Obtainable from: > deb http://mentors.debian.net/debian unstable main contrib non-free -- ::: .O. ::: ..O ::: OOO ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import signature.asc Description: Digital signature
RFTS: irda-utils
hi folks... as my current sponsor has to renew his gpg-key and the freeze for sarge is about to happen in the foreseeable future, i hereby put a request for a temporary sponsor for the package irda-utils. some important things have changed from -4 to -5, so i believe to need a couple of uploads to the archive until irda-utils will be fit for sarge. Name: irda-utils License: GPL Short description: IrDA management and handling utilities Long description: This package contains userspace utilities to manage and handle infrared devices. It includes irattach, findchip, irdadump, irdaping and irpsion5. OBEX tools are removed since 0.9.5. If you need to use IrOBEX, use openobex-apps package. . Authors: Dag Brattli <[EMAIL PROTECTED]> and Jean Tourrilhes <[EMAIL PROTECTED]> Homepage: http://irda.sourceforge.net Obtainable from: deb http://mentors.debian.net/debian unstable main contrib non-free thanks in advance, sebastian -- ::: .O. ::: ..O ::: OOO ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import signature.asc Description: Digital signature
Re: RFTS: irda-utils
hello.. 10 minutes after i sent this, i got my account @debian.org... so forget about the sponsor thing, but you might have a look at it, anyway. :) bye, sebastian * Sebastian Henschel <[EMAIL PROTECTED]> [2004-07-28 16:21 +0200]: > as my current sponsor has to renew his gpg-key and the freeze for sarge > is about to happen in the foreseeable future, i hereby put a request for > a temporary sponsor for the package irda-utils. some important things have > changed from -4 to -5, so i believe to need a couple of uploads to the > archive until irda-utils will be fit for sarge. > > Name: irda-utils > License: GPL > Short description: IrDA management and handling utilities > Long description: > This package contains userspace utilities to manage and handle infrared > devices. It includes irattach, findchip, irdadump, irdaping and > irpsion5. > OBEX tools are removed since 0.9.5. If you need to use IrOBEX, > use openobex-apps package. > . > Authors: Dag Brattli <[EMAIL PROTECTED]> and >Jean Tourrilhes <[EMAIL PROTECTED]> > Homepage: http://irda.sourceforge.net > Obtainable from: > deb http://mentors.debian.net/debian unstable main contrib non-free -- ::: .O. ::: ..O ::: OOO ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import signature.asc Description: Digital signature
RFTS: irda-utils
hi folks... as my current sponsor has to renew his gpg-key and the freeze for sarge is about to happen in the foreseeable future, i hereby put a request for a temporary sponsor for the package irda-utils. some important things have changed from -4 to -5, so i believe to need a couple of uploads to the archive until irda-utils will be fit for sarge. Name: irda-utils License: GPL Short description: IrDA management and handling utilities Long description: This package contains userspace utilities to manage and handle infrared devices. It includes irattach, findchip, irdadump, irdaping and irpsion5. OBEX tools are removed since 0.9.5. If you need to use IrOBEX, use openobex-apps package. . Authors: Dag Brattli <[EMAIL PROTECTED]> and Jean Tourrilhes <[EMAIL PROTECTED]> Homepage: http://irda.sourceforge.net Obtainable from: deb http://mentors.debian.net/debian unstable main contrib non-free thanks in advance, sebastian -- ::: .O. ::: ..O ::: OOO ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import signature.asc Description: Digital signature
Re: mysteries of /etc/default/*
hello...
thanks for all your answers. i think it is now clear to me.
* Joey Hess <[EMAIL PROTECTED]> [2004-07-19 09:20 +0200]:
> Adrian 'Dagurashibanipal' von Bidder wrote:
> > On Thursday 15 July 2004 15.15, Martin Dickopp wrote:
> > > Sebastian Henschel <[EMAIL PROTECTED]> writes:
> > [/etc/default]
> > > See Policy 9.3.2. (Disclaimer: IANADD.)
> >
> > Which does only say:
> > | To ensure that vital configurable values are always available, the
> > | init.d script should set default values for each of the shell
> > | variables it uses, either before sourcing the /etc/default/ file or
> > | afterwards using something like the : ${VAR:=default} syntax.
> > which isn't much.
>
> A few bits that you missed:
>
> Often there are some variables in the `init.d' scripts whose values
> control the behaviour of the scripts, and which a system administrator
> is likely to want to change. As the scripts themselves are frequently
> `conffile's, modifying them requires that the administrator merge in
> their changes each time the package is upgraded and the `conffile'
> changes. To ease the burden on the system administrator, such
> configurable values should not be placed directly in the script.
> Instead, they should be placed in a file in `/etc/default', which
> typically will have the same base name as the `init.d' script. This
> extra file should be sourced by the script when the script runs. It
> must contain only variable settings and comments in POSIX `sh' format.
> It may either be a `conffile' or a configuration file maintained by
> the package maintainer scripts. See Section 10.7, `Configuration
> files' for more details.
>
> 9.3.5. Example
> --
>
> The `bind' DNS (nameserver) package wants to make sure that the
> nameserver is running in multiuser runlevels, and is properly shut
> down with the system. It puts a script in `/etc/init.d', naming the
> script appropriately `bind'. As you can see, the script interprets
> the argument `reload' to send the nameserver a `HUP' signal (causing
> it to reload its configuration); this way the system administrator can
> say `/etc/init.d/bind reload' to reload the name server. The script
> has one configurable value, which can be used to pass parameters to
> the named program at startup; this value is read from
> `/etc/default/bind' (see below).
>
> ...
>
> Complementing the above init script is a configuration file
> `/etc/default/bind', which contains configurable parameters used by
> the script. This would be created by the `postinst' script if it was
> not already present, and removed on purge by the `postrm' script.
> # Specified parameters to pass to named. See named(8).
> # You may uncomment the following line, and edit to taste.
> #PARAMS="-u nobody"
>
> It's really not that hard to run less on policy and type /etc\/default
right, i forgot that possibility, sorry. at least now there is a thread
about this topic to be found in the mailing-list archives. :)
cheers,
sebastian
--
::: .O.
::: ..O
::: OOO
::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import
signature.asc
Description: Digital signature
Re: mysteries of /etc/default/*
hello...
thanks for all your answers. i think it is now clear to me.
* Joey Hess <[EMAIL PROTECTED]> [2004-07-19 09:20 +0200]:
> Adrian 'Dagurashibanipal' von Bidder wrote:
> > On Thursday 15 July 2004 15.15, Martin Dickopp wrote:
> > > Sebastian Henschel <[EMAIL PROTECTED]> writes:
> > [/etc/default]
> > > See Policy 9.3.2. (Disclaimer: IANADD.)
> >
> > Which does only say:
> > | To ensure that vital configurable values are always available, the
> > | init.d script should set default values for each of the shell
> > | variables it uses, either before sourcing the /etc/default/ file or
> > | afterwards using something like the : ${VAR:=default} syntax.
> > which isn't much.
>
> A few bits that you missed:
>
> Often there are some variables in the `init.d' scripts whose values
> control the behaviour of the scripts, and which a system administrator
> is likely to want to change. As the scripts themselves are frequently
> `conffile's, modifying them requires that the administrator merge in
> their changes each time the package is upgraded and the `conffile'
> changes. To ease the burden on the system administrator, such
> configurable values should not be placed directly in the script.
> Instead, they should be placed in a file in `/etc/default', which
> typically will have the same base name as the `init.d' script. This
> extra file should be sourced by the script when the script runs. It
> must contain only variable settings and comments in POSIX `sh' format.
> It may either be a `conffile' or a configuration file maintained by
> the package maintainer scripts. See Section 10.7, `Configuration
> files' for more details.
>
> 9.3.5. Example
> --
>
> The `bind' DNS (nameserver) package wants to make sure that the
> nameserver is running in multiuser runlevels, and is properly shut
> down with the system. It puts a script in `/etc/init.d', naming the
> script appropriately `bind'. As you can see, the script interprets
> the argument `reload' to send the nameserver a `HUP' signal (causing
> it to reload its configuration); this way the system administrator can
> say `/etc/init.d/bind reload' to reload the name server. The script
> has one configurable value, which can be used to pass parameters to
> the named program at startup; this value is read from
> `/etc/default/bind' (see below).
>
> ...
>
> Complementing the above init script is a configuration file
> `/etc/default/bind', which contains configurable parameters used by
> the script. This would be created by the `postinst' script if it was
> not already present, and removed on purge by the `postrm' script.
> # Specified parameters to pass to named. See named(8).
> # You may uncomment the following line, and edit to taste.
> #PARAMS="-u nobody"
>
> It's really not that hard to run less on policy and type /etc\/default
right, i forgot that possibility, sorry. at least now there is a thread
about this topic to be found in the mailing-list archives. :)
cheers,
sebastian
--
::: .O.
::: ..O
::: OOO
::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import
signature.asc
Description: Digital signature
mysteries of /etc/default/*
howdy folks... in the last couple of months, i realized that more and more packages are using a file in /etc/default/ for the configuration of their init-scripts. i searched in debian-devel and debian-mentors, looked into the policy 10.7 and asked a maintainer of such a package, but did not find any rationale, discussion or something which explains this. can any one of you please help me here? would it be smart to move my package's configuration into /etc/default as well? will it be part of the policy some day? why is it called default? thanks in advance, sebastian -- ::: .O. ::: ..O ::: OOO ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import signature.asc Description: Digital signature
mysteries of /etc/default/*
howdy folks... in the last couple of months, i realized that more and more packages are using a file in /etc/default/ for the configuration of their init-scripts. i searched in debian-devel and debian-mentors, looked into the policy 10.7 and asked a maintainer of such a package, but did not find any rationale, discussion or something which explains this. can any one of you please help me here? would it be smart to move my package's configuration into /etc/default as well? will it be part of the policy some day? why is it called default? thanks in advance, sebastian -- ::: .O. ::: ..O ::: OOO ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import signature.asc Description: Digital signature
direct mknod inevitable or drop old stuff in irda-utils?
hello folks... i am currently overhauling the package irda-utils and stumbled upon an error, where both lintian and linda complained that my postinst uses mknod. the reason for the usage of mknod is that MAKEDEV does not support the old IrDA major/minor devices anymore. as i was told, the nodes changed sometime after kernel 2.0.x. so my question is: shall i drop the support for the old nodes, too? personally, i am favoring that solution, but what do you think? cheers, sebastian -- ::: sebastian henschel ::: kodeaffe ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import pgp3uM4oBViuC.pgp Description: PGP signature
public access to crest.d.o
hello list, there is a bug reported (Bug#178971) against one of my packages which only seems to occur on m68k. since i want to test my package before the next release, i thought about doing test-runs on crest.d.o. the website at db.d.o/machines.cgi says that this machine is accessble by "all". so, which user and which password are supposed to used when connecting to crest.d.o being "all"? or does it work differently? do i have to apply somewhere? cheers, sebastian -- ::: sebastian henschel ::: kodeaffe ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import pgpv9Az4jTqoC.pgp Description: PGP signature
public access to crest.d.o
hello list, there is a bug reported (Bug#178971) against one of my packages which only seems to occur on m68k. since i want to test my package before the next release, i thought about doing test-runs on crest.d.o. the website at db.d.o/machines.cgi says that this machine is accessble by "all". so, which user and which password are supposed to used when connecting to crest.d.o being "all"? or does it work differently? do i have to apply somewhere? cheers, sebastian -- ::: sebastian henschel ::: kodeaffe ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import pgp0.pgp Description: PGP signature
Re: Adopting a package without being DD?
hello dariush... Received at 2003-01-14 / 22:24 by Dariush Pietrzak: > I'd like to adopt qiv (bug #176329), but I am not a DD yet. > I am using this package and don't want to see it removed. Should I file > ITA? > Or maybe - how long should I wait for some real DD to take care of this > package before filing ITA myself? perhaps you should look for a sponsor (someone who would upload the package for you), first. otherwise you should not wait an arbitrary time to ITA, just do it. :) cheers, sebastian -- ::: sebastian henschel ::: kodeaffe ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import pgpyGS9SdevRQ.pgp Description: PGP signature
Re: Adopting a package without being DD?
hello dariush... Received at 2003-01-14 / 22:24 by Dariush Pietrzak: > I'd like to adopt qiv (bug #176329), but I am not a DD yet. > I am using this package and don't want to see it removed. Should I file > ITA? > Or maybe - how long should I wait for some real DD to take care of this > package before filing ITA myself? perhaps you should look for a sponsor (someone who would upload the package for you), first. otherwise you should not wait an arbitrary time to ITA, just do it. :) cheers, sebastian -- ::: sebastian henschel ::: kodeaffe ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import msg08295/pgp0.pgp Description: PGP signature
Re: new package name for gtk-engines-mgicchikn
hello sven.. Received at 2002-11-27 / 09:01 by Sven Luther: > On Mon, Nov 25, 2002 at 04:17:54PM +0100, Sebastian Henschel wrote: > > > > i am currently adopting the package "gtk-engines-mgicchikn", > > whereas one task is to rename the package. > > There was a discution on naming gtk engines package on the > debian-gtk-gnome mailing list some time ago, maybe you should look into > that (if you did not already). ok, now i am subscribed to that list and won't miss the next discussion. do you mean this one: http://lists.debian.org/debian-gtk-gnome/2002/debian-gtk-gnome-200208/msg00327.html this was a discussion about the prefix which seems to be settled and decided upon gtk2-engines-. anyway, i will stick to "magicchicken" as long as no one screams about it. thanks sven and decklin, sebastian -- ::: sebastian henschel ::: kodeaffe ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import
Re: new package name for gtk-engines-mgicchikn
hello sven.. Received at 2002-11-27 / 09:01 by Sven Luther: > On Mon, Nov 25, 2002 at 04:17:54PM +0100, Sebastian Henschel wrote: > > > > i am currently adopting the package "gtk-engines-mgicchikn", > > whereas one task is to rename the package. > > There was a discution on naming gtk engines package on the > debian-gtk-gnome mailing list some time ago, maybe you should look into > that (if you did not already). ok, now i am subscribed to that list and won't miss the next discussion. do you mean this one: http://lists.debian.org/debian-gtk-gnome/2002/debian-gtk-gnome-200208/msg00327.html this was a discussion about the prefix which seems to be settled and decided upon gtk2-engines-. anyway, i will stick to "magicchicken" as long as no one screams about it. thanks sven and decklin, sebastian -- ::: sebastian henschel ::: kodeaffe ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
new package name for gtk-engines-mgicchikn
hello list.. i am currently adopting the package "gtk-engines-mgicchikn", whereas one task is to rename the package. so i think that "gtk2-engines-magicchicken" is a fine name for it. unfortunately, there are 25 characters necessary for this name. the developer's reference suggests to use no more than 20 characters. but the "mandatory" prefix "gtk2-engines-" alone needs 12 characters, so crippling the name of the theme itself to 8 characters would be necessary to comply with the aforementioned suggestion. how do tools like aptitute, deity, etc. cope with these long names? my sponsor and i agree on "gtk2-engines-magicchicken", despite its length. what do the others think about it? thanks, sebastian -- ::: sebastian henschel ::: kodeaffe ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import
new package name for gtk-engines-mgicchikn
hello list.. i am currently adopting the package "gtk-engines-mgicchikn", whereas one task is to rename the package. so i think that "gtk2-engines-magicchicken" is a fine name for it. unfortunately, there are 25 characters necessary for this name. the developer's reference suggests to use no more than 20 characters. but the "mandatory" prefix "gtk2-engines-" alone needs 12 characters, so crippling the name of the theme itself to 8 characters would be necessary to comply with the aforementioned suggestion. how do tools like aptitute, deity, etc. cope with these long names? my sponsor and i agree on "gtk2-engines-magicchicken", despite its length. what do the others think about it? thanks, sebastian -- ::: sebastian henschel ::: kodeaffe ::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
subscribe
subscribe [EMAIL PROTECTED]
subscribe
subscribe [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
