Re: make *.py +x

[Le Boulanger Yann]

Rakotomandimby Mihamina wrote:

Hello,

I made my yum debian package, and when passing it to 'lintian -i',
It finds that many *.py files are not executable.

I am not really sure where should I make the chmod into the rules file.
would you help me?

I join the rules file (but tell me if you need more to help me).

Thank you.

PS: The reply-to is alredy set to the list, please only reply, dont
reply to all ;-)



The problem can be with your py files that contain things like
#!/usr/bin/env python
but thoses files doesn't need to be executable.
In such a case I think you should remove the header and inform the upstream.

Yann


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please take a look over aspell-ro_0.50-2-1

[Brian Nelson]

Eddy Petrişor <[EMAIL PROTECTED]> writes:

> On 10/5/05, Brian Nelson <[EMAIL PROTECTED]> wrote:
>> Christoph Berg <[EMAIL PROTECTED]> writes:
>> >  you might want to use the new "Archticture: all" packaging variant,
>> >  see for example #319675, otherwise you need to Provides:
>> >  aspell6-dictionary
>> aspell6a-dictionary, actually (dictionary file locations moved after the
>> sarge release).
>
> so I need either "Architecture: all" or Provides: aspell6a-dictionary ?

You need either:

Architecture: all
Provides: aspell-dictionary

or:

Architecture: any
Provides: aspell6a-dictionary

The former is strongly preferred, provided you use the
aspell-autobuildhash system properly.

> I looked over the bug specified, but there are some unclear things to
> me. How should I provide a gzipped version or the word list? If I gzip
> it before packaging then the diff.gz will be huge, right? (As the
> original package does not have a compressed word list.)

Include them just in the .deb at build time, and not in the source
package (.diff.gz).  See aspell-en, for example.

-- 
Captain Logic is not steering this tugboat.

Re: make *.py +x

[Ben Finney]

On 19-Oct-2005, Rakotomandimby Mihamina wrote:
> I made my yum debian package, and when passing it to 'lintian -i',
> It finds that many *.py files are not executable.

This seems backwards.

If a file is meant to be executable, the convention is to name it
*without* a suffix (so that it can be executed as a command without
needing to be aware of what language it's written in). This also means
that it can be re-implemented in another language without changing the
command interface.

If it's to be included in other programs (primarily), the convention
is to name it with a language-specific suffix and make it *not*
executable. That's how I'd interpret *.py files.

Why does lintian want to go against this convention?

-- 
 \  "'Did you sleep well?' 'No, I made a couple of mistakes.'"  -- |
  `\ Steven Wright |
_o__)  |
Ben Finney <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: make *.py +x

[Justin Pryzby]

On Wed, Oct 19, 2005 at 03:07:38AM +0200, Rakotomandimby Mihamina wrote:
> Hello,
> 
> I made my yum debian package, and when passing it to 'lintian -i',
> It finds that many *.py files are not executable.
> 
> I am not really sure where should I make the chmod into the rules
> file.  would you help me?
You could run it after the install command, with something like

  -find -name '*.py' |xargs chmod 755

where the - is necessary in case there are no files, and then chmod
will error with "too few arguments" and $?=1.  Maybe there is a better
way, that errors in cases where, for example, find fails, or chmod
fails for other reasons.

You could also run it in the "configure" target or the "build" target,
assuming that all the relevent .py files existed and didn't get
overwritten at that point.

> build-stamp: configure-stamp 
This is unnecessary; the configure and configure-stamp rules are not
required, and here they are just making the build rules needlessly
more complicated, since dh_testdir also happens in build-stamp anyway.

-- 
Clear skies,
Justin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

make *.py +x

[Rakotomandimby Mihamina]

Hello,

I made my yum debian package, and when passing it to 'lintian -i',
It finds that many *.py files are not executable.

I am not really sure where should I make the chmod into the rules file.
would you help me?

I join the rules file (but tell me if you need more to help me).

Thank you.

PS: The reply-to is alredy set to the list, please only reply, dont
reply to all ;-)

-- 
Administration & Formation à l'administration
de serveurs dédiés:
http://www.google.fr/search?q=aspo+infogerance+serveur
#!/usr/bin/make -f
# -*- makefile -*-
# Sample debian/rules that uses debhelper.
# This file was originally written by Joey Hess and Craig Small.
# As a special exception, when this file is copied by dh-make into a
# dh-make output file, you may use that output file without restriction.
# This special exception was added by Craig Small in version 0.37 of dh-make.

# Uncomment this to turn on verbose mode.
export DH_VERBOSE=1




CFLAGS = -Wall -g

ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0
else
CFLAGS += -O2
endif

# configure: configure-stamp
# This package does not need ./configure
# Directly make; make install

configure-stamp:
dh_testdir
# Add here commands to configure the package.

touch configure-stamp


build: build-stamp

build-stamp: configure-stamp 
dh_testdir

# Add here commands to compile the package.
$(MAKE)
#docbook-to-man debian/yum.sgml > yum.1

touch build-stamp

clean:
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp

# Add here commands to clean up after the build process.
-$(MAKE) clean

dh_clean 

install: build
dh_testdir
dh_testroot
dh_clean -k 
dh_installdirs

# Add here commands to install the package into debian/yum.
$(MAKE) install DESTDIR=$(CURDIR)/debian/yum


# Build architecture-independent files here.
binary-indep: build install
# We have nothing to do by default.

# Build architecture-dependent files here.
binary-arch: build install
dh_testdir
dh_testroot
dh_installchangelogs ChangeLog
dh_installdocs
dh_installexamples
#   dh_install
#   dh_installmenu
#   dh_installdebconf   
#   dh_installlogrotate
#   dh_installemacsen
#   dh_installpam
#   dh_installmime
#   dh_installinit
#   dh_installcron
#   dh_installinfo
dh_installman
dh_link
dh_strip
dh_compress
dh_fixperms
#   dh_perl
#   dh_python
#   dh_makeshlibs
dh_installdeb
dh_shlibdeps
dh_gencontrol
dh_md5sums
dh_builddeb

binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install configure

Re: Packaging snapshots

[Justin Pryzby]

On Wed, Oct 19, 2005 at 09:37:14AM +1000, Kai Hendry wrote:
> Just wondering about packaging snapshots of a package.
> 
> Ok, snapshots could be known as "backups". Here I am talking about
> pulling from say a Subversion repository and building a package.
> 
> For now I want to do this just to keep tabs on what upstream has
> planned. Not so much for unstable...
> 
> 
> 
> I remember being a little bewildered by the version string in Debian. Is
> this OK?
> 
> frodo$ apt-cache show irssi-snapshot | grep Version:
> Version: 0.8.6+cvs.20031114-1
> 
> And how does that compare to:
> 
> frodo$ apt-cache show gcc-snapshot | grep Version:
> Version: 20051008-1
> 
> 
> Is this documented somewhere?
You can use

  dpkg --compare-versions 1 '>' 2; echo $?

Of course, 20051008 > 0.8.6... but I don't think thats what you mean
:)

-- 
Clear skies,
Justin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Packaging snapshots

[Kai Hendry]

Just wondering about packaging snapshots of a package.

Ok, snapshots could be known as "backups". Here I am talking about
pulling from say a Subversion repository and building a package.

For now I want to do this just to keep tabs on what upstream has
planned. Not so much for unstable...



I remember being a little bewildered by the version string in Debian. Is
this OK?

frodo$ apt-cache show irssi-snapshot | grep Version:
Version: 0.8.6+cvs.20031114-1

And how does that compare to:

frodo$ apt-cache show gcc-snapshot | grep Version:
Version: 20051008-1


Is this documented somewhere?

http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

Could be elaborated on with examples. Be good if the dates were iso8601
style:
date --iso-8601=hours

2005-10-18T16+1000

But then they would be twice as long...

Best wishes,


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [RFS] kde-icons-nuvola and kde-icons-crystalclear

[Christoph Haas]

On Tuesday 18 October 2005 10:24, Bastian Venthur wrote:
> I'm searching for sponsorship of my packages:
>
> kde-icons-crystalclear
>  + http://venthur.de/debian/crystalclear/
> closes: #322161
>  + http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322161
> * Package name: kde-icons-crystalclear
>   Version : 0.0.20050623
>   Upstream Author : Everaldo Coelho <[EMAIL PROTECTED]>
> * URL :

- Similar thoughts here about dh_install and dh_fixperms.
- debian/control contains an empty "Depends:" line.

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [RFS] kde-icons-nuvola and kde-icons-crystalclear

[Christoph Haas]

On Tuesday 18 October 2005 10:24, Bastian Venthur wrote:
> I'm searching for sponsorship of my packages:
>dh_install 128x128 16x16 22x22 32x32 48x48
> kde-icons-nuvola
>  + http://packages.qa.debian.org/k/kde-icons-nuvola.html
>  + http://venthur.de/debian/nuvola/

As usual I have found something to grumble about. :)

dh_install 128x128 16x16 22x22 32x32 48x48...
=> Consider putting these directories into debian/kde-icons-nuvola.install
   (See "man dh_install")

find ... -type f -exec chmod 644 {}
=> Isn't dh_fixperms doing that already?

find ... -name laptop_charge -exec rm \{\} \;
=> You are doing that after dh_builddeb? Advanced magic? :)

 Christoph
-- 
~
~
".signature" [Modified] 1 line --100%--1,48 All


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Help with dbconfig-common

[Marcus Better]

Hello,

I am packaging tikiwiki, and want to use dbconfig-common for the
database configuration. I followed the instructions in the documentation
and looked at the examples, but it still yelling rude things at me.

First I installed my package and said NO to the first question, about
whether dbconfig-common should configure the databases at all. The
result was that dpkg failed to configure the package, giving the message:

  sanity check failed for dbc_dbtype

This makes sense since the dbtype (a debconf variable) was empty - as it
should be since I never got a chance to select a database type, having
answered that I would configure the database manually.

Every subsequent attempt to remove the package failed with the same
error. Finally I managed to get rid of the package by removing the
sanity check from one of the dbconfig-common scripts.

Then I installed the package again, and now told debconf to configure a
MySQL database for me. Now I get the following result:

$ sudo dpkg -P tikiwiki
(Reading database ... 201307 files and directories currently installed.)
Removing tikiwiki ...
dpkg: error processing tikiwiki (--purge):
 subprocess pre-removal script returned error exit status 10
dbconfig-common: writing config to /etc/dbconfig-common/tikiwiki.conf
dbconfig-common: flushing administrative password
dpkg: error while cleaning up:
 subprocess post-installation script returned error exit status 10
Errors were encountered while processing:
 tikiwiki

$ dpkg -l tikiwiki
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
pF  tikiwiki   1.9.1-1groupware and content management system


So it looks like I'm doing something wrong with dbconfig-common. Can
someone point me in the right direction here?

Thanks,

Marcus B.


signature.asc
Description: OpenPGP digital signature

Re: ifupdown-bonding package

[Loïc Minier]

[ I suggest me move the discussion off-list, as it's now quite OT :) ]

On Tue, Oct 18, 2005, Jerome Martin wrote:
> >That's useful indeed.  That would be another round of fixes for the
> >bonding if-up scripts.
> Mmmhh ... are there already any bonding if-up scripts ? If so, I don't 
> know in which package ...

 I think only the one I cited, from ifenslave-2.6.

> When not using miimon, you can configure bonding to send arp requests to 
> specified IPs in order to check link connectivity. One of the problem I 
> have with that mode is that whenever you change the IP of those 
> reference machines or those individual hosts go down, your link is 
> declared as down. If the ifup scripts for bonding could automatically 
> select reasonable IPs to send ARPs to (after checking ARP requests are 
> honored), it could allow sysadmins to transparently use arp monitoring 
> without worrying too much about whether the bonding configuration is 
> up-to-date. Good candidates for such reference hosts could be the 
> declared default gateway for the interface and DNS servers (specified in 
> network/interfaces through resolvconf package hooks). This is very 
> specific to bonding, so I can't see how it can be usefull to other 
> inteface type.

 Ok, thanks for the clarification.

> A common problem with bonding + SNMP is that when you get the interface 
> list of an SNMP-enabled host, the SNMP agent only returns the first 
> interface to which a specific IP/mac address is attached (and this is 
> normal behavior, not a bug). Say you have eth1 and eth2 slaves of bond0. 
> If eth1 is brought up before bond0, its physicall interface definition 
> will appear first in the SNMP interface table, thus it will be used 
> instead of bond0 as "primary" interface for the corresponding IP 
> address. This is wrong because it works only when eth1 is primary in a 
> primary-backup scheme, but reports wrong stats in any other case (stats 
> like traffic, dropped packets, etc.).

 Ok, thanks for the explanation.

> The only way to make sure the SNMP agent will report the correct 
> interfaces indexes is to load the bonding module first, then load each 
> slave driver (of course this works only with modules, not with 
> monolithically compiled-in drivers).

 I think that the solution is wrong in this case, but I prefer we
 continue this discussion privately, as it's getting OT for this list.

 I suppose the final discussion and decision will be taken by the
 package maintainer of the files you want to change.  :)

> Is it clearer now ?

 Yes, thanks.

> Well, for one, there is a major flaw when reconfiguring interfaces : in 
> order for the if state to be properly handled, you are supposed to 
> ifdown the interface before any change to the config. Otherwise, you 
> loose the ability to properly ifdown it at a later time.

 Ok, that's a general problem with ifupdown IMO, non-vlan or bonding
 specific.

> Good, I was not sure that bash was in base and allowed for such scripts 
> by policy. #!/bin/sh is bash anyway on a default installation :-).

 You need to use #!/bin/bash, not sh, even if sh points to bash by
 default.  bash is "Essential", meaning it's always there.

> I hope this clears up why I think specific precautions should be taken 
> when playing with VLANs + bonding.

 Indeed.

> I agree this is ugly, but I disagree with your suggestion, witch is even 
> more error-prone IMHO. The problem in your example is redundancy of 
> information, without automatic cross-checking. I do prefer the 
> vlan_raw_device stanza style, where all VLAN definition is grouped into 
> the VLAN interface (a la RedHat) :
> iface eth0 inet manual
> iface eth0.16 inet static
> vlan_raw_device eth0
> vlan_id 16
> # this could be host / interface
> bind-type PER_KERNEL
> address x.x.x.x

 It has its defaults too, since one can do inconsistent things such as
 having eth0.16 using vlan_raw_device eth1, or iface eth0.16 with
 vlan_raw_device eth0 and iface eth0 with an address, etc.

> One simple reason I prefer the latest is because a VLAN may have 
> multiple specific options besides it VLAN number

 One doesn't forbid the other IMO.  I don't frankly care that the VLANs
 are declared in the resulting interfaces or in the physical interface
 carying them, but I do care about the information encoded in the name.

 Concerning your point about checking for names, well you know that when
 you boot your machine you start with eth0, eth1 etc.  So you also know
 that when you add VLANs to eth0, you end up with eth0.16 etc., it's
 implied.

 This is way off-topic, but I would happily continue discussing this
 stuff either privately, or via IRC/IRL.

   Cheers,
-- 
Loïc Minier <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Overriding over Linda/Lintian

[Daniel Leidert]

Am Dienstag, den 18.10.2005, 14:13 -0400 schrieb -.JavaManiac.-:

> Im packaging urlgfe,an some others,when i run Linda over the package
> it gives me 2 warnings about shared libraries,here is the output
> 
> 
> linda -Di *.changes
> W: urlgfe; Shared object /usr/bin/urlgfe is linked with version 0.9.8
> and 0.9.7 of libcrypto.
[..]

> how can i override the warnings,and/or add the override to the package??

Why do you want to override this warning? Is it a wanted feature or a
false positive?

To override a warning, you need to add a special file. Have a look at
the files in /usr/share/linda/overrides/
and /usr/share/lintian/overrides/. You need to create such files and
copy them to you build-path, so they become part of the package.

Regards, Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Overriding over Linda/Lintian

[Justin Pryzby]

On Tue, Oct 18, 2005 at 02:13:16PM -0400, -.JavaManiac.- wrote:
> Hello.
> 
> Im packaging urlgfe,an some others,when i run Linda over the package
> it gives me 2 warnings about shared libraries,here is the output
> 
> 
> linda -Di *.changes
> W: urlgfe; Shared object /usr/bin/urlgfe is linked with version 0.9.8
> and 0.9.7 of libcrypto.
>  The binary object shown above links against 2 versions of the same
>  shared library. This means your package may require conflicting
>  packages to be installed at the same time, and is therefore
>  uninstallable, or the binary may not work. This may also be ignored if
>  versioned symbols are being used in both libraries.
> W: urlgfe; Shared object /usr/bin/urlgfe is linked with version 0.9.8
> and 0.9.7 of libssl.
> 
> how can i override the warnings,and/or add the override to the package??
Are you sure thats what you want to do?  Of course lintian is trying
to avoid you making a mistake (one which, in this case, I think would
likely cause segfaults).

If overriding lintian is really correct in this situation, then you
should also try to determine why lintian is giving you a warning which
it should apparently not be giving you, and detail the situation in
bugs to the appropriate packages.

You can include a lintian override (I don't know about linda) by
including a file in the package called /usr/share/lintian/overrides/
in the format of the lintian (linda?) warnings .. and also in the
format of the files from other packages which you probably already
have in that location.  You probably want to keep the override in
./debian/ somewhere, and use ./debian/urlgfe.install + dh_install in
./debian/rules to install it to that location (though /usr/bin/cp and
/usr/bin/install are also fine).

-- 
Clear skies,
Justin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How can I change the package's name

[Justin Pryzby]

On Tue, Oct 18, 2005 at 03:55:38PM -0200, Jose Carlos do Nascimento wrote:
> Hi, Justin
> 
> I did it.
> now my php-imagick source generates php4-imagick and php5-imagick debs.
> I uploaded and source is NEW.
> What I need to do now ?  
Just wait until it is approved.  The NEW faq indicates that the
changelog should detail why the package name was changed; if you
didn't do so, I would recommened uploading a new revision with that
information (assuming that the NEW queue will deal appropriately with
a new revision).

-- 
Clear skies,
Justin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Overriding over Linda/Lintian

[-.JavaManiac.-]

Hello.

Im packaging urlgfe,an some others,when i run Linda over the package
it gives me 2 warnings about shared libraries,here is the output


linda -Di *.changes
W: urlgfe; Shared object /usr/bin/urlgfe is linked with version 0.9.8
and 0.9.7 of libcrypto.
 The binary object shown above links against 2 versions of the same
 shared library. This means your package may require conflicting
 packages to be installed at the same time, and is therefore
 uninstallable, or the binary may not work. This may also be ignored if
 versioned symbols are being used in both libraries.
W: urlgfe; Shared object /usr/bin/urlgfe is linked with version 0.9.8
and 0.9.7 of libssl.

how can i override the warnings,and/or add the override to the package??

Regards.

--
Gerardo Curiel
Linux User # 374459
Geek By NaTure,LiNuX By ChOiCe,DebiAn of CoUrsE
<___-!!Java RuLeS!!-___>

Re: How can I change the package's name

[Jose Carlos do Nascimento]

Hi, Justin

I did it.
now my php-imagick source generates php4-imagick and php5-imagick debs.
I uploaded and source is NEW.
What I need to do now ?  


Thanks
Jose Carlos


Renaming the source package will force you to go through the new queue
again, afaik.  You can just change the package name in the first
stanza of ./debian/control (the source stanza).

 




--
José Carlos do Nascimento <[EMAIL PROTECTED]>
Analista de Sistemas
VARIG Brazilian Airlines - SAODT
GGTI - Gerencia Geral de Tecnologia da Informação
Tel.: + 55-0XX-11-5091-2632


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: ifupdown-bonding package

[Jerome Martin]

Loïc Minier wrote:


On Tue, Oct 18, 2005, Jerome Martin wrote:
 

Well, I am a bit surprised by the way you see it. Could you be more 
specific ?
   



Of course: what I meant is that the issues you might have encountered
require fixing, and not documentation.  I can't tell how much of what
you describe is currently supported by the current ifenslave and vlan
packages, but it's where things should be implemented or fixed.

I know that I'm currently using things such as:

auto bond0
iface bond0 inet manual
   up insmod bonding -o bond0 mode=0 miimon=100
   up ifconfig bond0 hw ether 00:04:23:B1:C7:24
   up ifconfig $IFACE up
   down ifconfig $IFACE down
   down rmmod bond0

or even:

auto bond1
iface bond1 inet manual
   pre-up ifconfig eth1 up
   pre-up ifconfig eth3 up
   up insmod bonding -o $IFACE mode=0 miimon=100
   up ifconfig $IFACE hw ether 00:04:23:B1:C7:25
   up ifconfig $IFACE 127.0.0.2 up
   up ifenslave -X $IFACE eth1 eth3
   up ifconfig $IFACE 0.0.0.0
   up ifconfig eth1 0.0.0.0
   up ifconfig eth3 0.0.0.0
   up echo success
   down ifconfig $IFACE 127.0.0.2
   down ifenslave -d $IFACE eth1 eth3
   down ifconfig $IFACE down
   down rmmod $IFACE
   post-down ifconfig eth3 down
   post-down ifconfig eth1 down

on a server running sarge, but it seems that the current ifenslave-2.6
packages already offer to switch to:

iface bond0 inet static
   address 192.168.48.157
   netmask 255.255.252.0
   broadcast 192.168.48.255
   gateway 192.168.48.1
   slaves eth0 eth1

since this change:

ifenslave-2.6 (1.1.0-5) unstable; urgency=low

 * Add if-pre-up and if-post-down scripts to enslave and detach interfaces.
   Closes: #306993.

-- Guus Sliepen <[EMAIL PROTECTED]>  Fri, 30 Sep 2005 14:33:46 +0200
 


Well, then my code is useless, it does the same thing ! :-)
I'll check the new ifenslave package to see if there's anything to add 
to it, but given what you say, it does pretty much the same thing I just 
implemented :-) In any case, I'll send my eventual patches to the 
maintainer.




 

- provide a way to simplify the process by setting defaults enabling 
fast testing/setting up. Of course I realise that these defaults cannot 
be universal, that is the reason why I suggested the possibility to 
override them in network/options. You tell that this file is deprecated, 
so I should find some other way to do it, but the spirit remains the 
same : centralise some defaults, render the interface definition less 
verbose, lighter.
   



I suggest using /etc/default/.
 


OK, I'll do that.

 

- allow one to configure easily the bonding module from inside the 
interface definition
   



That's good, and is not covered by the current ifenslave-2.6 scripts.
I suggest you file a request against ifenslave-2.6 with your proposalto
address this.
 


Will do.


I feel that those 3 goals are fixes to problems I have encountered myself.
As for my future goals (to be implemented, but I'm working on it and 
have something soon) :
- Add logic to check VLANs are up only AFTER the main bond interface is 
up and attached to at least one slave (in order to ensure no mac address 
issues will occur)
- Add logic to check that slave interfaces do not have IPs configured 
nor routes (in order to prevent conflicts) befor the bond is started
- Add logic to check there is no IP attached to an underlying bond 
interface before bringing up VLANs.
   



That's useful indeed.  That would be another round of fixes for the
bonding if-up scripts.
 

Mmmhh ... are there already any bonding if-up scripts ? If so, I don't 
know in which package ...


- Add logic to configure arp monitoring using the default gw / 
resolvconf hooks / whaterver makes sense (suggestions welcome)
   



I don't see what you mean, but it certainly makes sense to add such a
support in the ifupdown package so that all interface types can benefit
from the change.
 

When not using miimon, you can configure bonding to send arp requests to 
specified IPs in order to check link connectivity. One of the problem I 
have with that mode is that whenever you change the IP of those 
reference machines or those individual hosts go down, your link is 
declared as down. If the ifup scripts for bonding could automatically 
select reasonable IPs to send ARPs to (after checking ARP requests are 
honored), it could allow sysadmins to transparently use arp monitoring 
without worrying too much about whether the bonding configuration is 
up-to-date. Good candidates for such reference hosts could be the 
declared default gateway for the interface and DNS servers (specified in 
network/interfaces through resolvconf package hooks). This is very 
specific to bonding, so I can't see how it can be usefull to other 
inteface type.


 

- Add logic to detect which modules are used by the slave interfaces and 
eventually unload themfirst and reload them after the bonding module (so 
that SNMP if queries will report the bond as the "owner" of its IP 
address). I realise

Re: ifupdown-bonding package

[Loïc Minier]

On Tue, Oct 18, 2005, Jerome Martin wrote:
> Well, I am a bit surprised by the way you see it. Could you be more 
> specific ?

 Of course: what I meant is that the issues you might have encountered
 require fixing, and not documentation.  I can't tell how much of what
 you describe is currently supported by the current ifenslave and vlan
 packages, but it's where things should be implemented or fixed.

 I know that I'm currently using things such as:

auto bond0
iface bond0 inet manual
up insmod bonding -o bond0 mode=0 miimon=100
up ifconfig bond0 hw ether 00:04:23:B1:C7:24
up ifconfig $IFACE up
down ifconfig $IFACE down
down rmmod bond0

 or even:

auto bond1
iface bond1 inet manual
pre-up ifconfig eth1 up
pre-up ifconfig eth3 up
up insmod bonding -o $IFACE mode=0 miimon=100
up ifconfig $IFACE hw ether 00:04:23:B1:C7:25
up ifconfig $IFACE 127.0.0.2 up
up ifenslave -X $IFACE eth1 eth3
up ifconfig $IFACE 0.0.0.0
up ifconfig eth1 0.0.0.0
up ifconfig eth3 0.0.0.0
up echo success
down ifconfig $IFACE 127.0.0.2
down ifenslave -d $IFACE eth1 eth3
down ifconfig $IFACE down
down rmmod $IFACE
post-down ifconfig eth3 down
post-down ifconfig eth1 down

 on a server running sarge, but it seems that the current ifenslave-2.6
 packages already offer to switch to:

iface bond0 inet static
address 192.168.48.157
netmask 255.255.252.0
broadcast 192.168.48.255
gateway 192.168.48.1
slaves eth0 eth1

 since this change:

ifenslave-2.6 (1.1.0-5) unstable; urgency=low

  * Add if-pre-up and if-post-down scripts to enslave and detach interfaces.
Closes: #306993.

 -- Guus Sliepen <[EMAIL PROTECTED]>  Fri, 30 Sep 2005 14:33:46 +0200

> - provide a way to describe bonding interfaces in network/interfaces 
> without the burden of repeating the same ifup/ifdown definitions.

 That's nice, it offers a bit more control than the current scripts, but
 it's as short as it can already be.

> - provide a way to simplify the process by setting defaults enabling 
> fast testing/setting up. Of course I realise that these defaults cannot 
> be universal, that is the reason why I suggested the possibility to 
> override them in network/options. You tell that this file is deprecated, 
> so I should find some other way to do it, but the spirit remains the 
> same : centralise some defaults, render the interface definition less 
> verbose, lighter.

 I suggest using /etc/default/.

> - allow one to configure easily the bonding module from inside the 
> interface definition

 That's good, and is not covered by the current ifenslave-2.6 scripts.
 I suggest you file a request against ifenslave-2.6 with your proposalto
 address this.

> I feel that those 3 goals are fixes to problems I have encountered myself.
> As for my future goals (to be implemented, but I'm working on it and 
> have something soon) :
> - Add logic to check VLANs are up only AFTER the main bond interface is 
> up and attached to at least one slave (in order to ensure no mac address 
> issues will occur)
> - Add logic to check that slave interfaces do not have IPs configured 
> nor routes (in order to prevent conflicts) befor the bond is started
> - Add logic to check there is no IP attached to an underlying bond 
> interface before bringing up VLANs.

 That's useful indeed.  That would be another round of fixes for the
 bonding if-up scripts.

> - Add logic to configure arp monitoring using the default gw / 
> resolvconf hooks / whaterver makes sense (suggestions welcome)

 I don't see what you mean, but it certainly makes sense to add such a
 support in the ifupdown package so that all interface types can benefit
 from the change.

> - Add logic to detect which modules are used by the slave interfaces and 
> eventually unload themfirst and reload them after the bonding module (so 
> that SNMP if queries will report the bond as the "owner" of its IP 
> address). I realise that this impacts heavily the logic dictated by 
> configuring modules in modprobe.conf / modprobe.d, maybe there is 
> something that could be done with an external tool handling this (and 
> storing configuration via debconf ?) ? What would be the "debian way" ?

 I don't understand the above, but I'm sure you'll find your way in
 Debian.  :)

> All that to say that my goal is to provide code to solve issues, not 
> only document them. However, at some point, I hacked down the README as 
> much as a reminder of items to investigate than documentation for people 
> willing to use the embryo of features already coded.

 Ok, so it's more of a TODO.  :)

> However, I'm a lost, because in order to acheive all those "automatic 
> handling of all VLANs+bonding issues" it seems that a lot more changes 
> would be required to the network modules handling + ifupdown 
> architecture than just a few hooks.

 I don't see why, the current approach of if-up scripts seems ok to me.

> While I am at i

Re: ifupdown-bonding package

[Jerome Martin]

Hello,

First of all, I'd like to thank you for taking the time to read my email 
an answer it.


Loïc Minier wrote:


Documentation on joining the project or helping the project is
available at:
   
   
   

I think it should answer your technical questions, and clear up
anything regarding current procedures.
 

Yes, as I stated in my original post I already started reading newmaint 
and policy, and I joined my ml so I can get real-world examples of how 
things are done and and general feeling about the right attitude (which 
I may not have yet :-).



Please find below the short README I wrote (no manpage yet ... will make
one if this is of interest).
   



Since I use vlan over bonding and had some trouble myself, I read the
README as a whole and added comments below.  In general, I think your
approach is oriented in "let's document how to workaround bugs and make
it work", while a better approach might be "let's understand and fix
each bug to let that work flawlessly".
 

Well, I am a bit surprised by the way you see it. Could you be more 
specific ?

The main goals of these scripts were :
- provide a way to describe bonding interfaces in network/interfaces 
without the burden of repeating the same ifup/ifdown definitions.
- provide a way to simplify the process by setting defaults enabling 
fast testing/setting up. Of course I realise that these defaults cannot 
be universal, that is the reason why I suggested the possibility to 
override them in network/options. You tell that this file is deprecated, 
so I should find some other way to do it, but the spirit remains the 
same : centralise some defaults, render the interface definition less 
verbose, lighter.
- allow one to configure easily the bonding module from inside the 
interface definition


I feel that those 3 goals are fixes to problems I have encountered myself.
As for my future goals (to be implemented, but I'm working on it and 
have something soon) :


- Add logic to check VLANs are up only AFTER the main bond interface is 
up and attached to at least one slave (in order to ensure no mac address 
issues will occur)
- Add logic to configure arp monitoring using the default gw / 
resolvconf hooks / whaterver makes sense (suggestions welcome)
- Add logic to check that slave interfaces do not have IPs configured 
nor routes (in order to prevent conflicts) befor the bond is started
- Add logic to detect which modules are used by the slave interfaces and 
eventually unload themfirst and reload them after the bonding module (so 
that SNMP if queries will report the bond as the "owner" of its IP 
address). I realise that this impacts heavily the logic dictated by 
configuring modules in modprobe.conf / modprobe.d, maybe there is 
something that could be done with an external tool handling this (and 
storing configuration via debconf ?) ? What would be the "debian way" ?
- Add logic to check there is no IP attached to an underlying bond 
interface before bringing up VLANs.


All that to say that my goal is to provide code to solve issues, not 
only document them. However, at some point, I hacked down the README as 
much as a reminder of items to investigate than documentation for people 
willing to use the embryo of features already coded.


However, I'm a lost, because in order to acheive all those "automatic 
handling of all VLANs+bonding issues" it seems that a lot more changes 
would be required to the network modules handling + ifupdown 
architecture than just a few hooks.


Again, some insight on the "debian way" would be greatly appreciated. 
One one side, I like the DIY approach of the interfaces file, with 
manually configuring ifup/preup/etc. stanzas. On the other hand, the 
network/*.d system DOES exists, but seems underused ... so far I found 
resolvconf, vlan and the not-yet-fully-understood-by-me 
ifupdown-scripts-zg2 package (if someone could elaborate on this one, 
its goals, how "debianish" it is, I am willing to offer a full round of 
beer to anyone willing to come to Paris to drink with me ! ;-).



ifupdown-bonding README
This is version 0.1 of the package, as of 10/17/2005.
This package contains hooks for ifupdown in order to add bonding and
VLAN for bonding syntax to /etc/network/interfaces.
   



In general, packages don't hold very small things, especially they
don't hold a couple of scripts and documentation to enhance another
package;  instead, you can file a request against the package you
 


Agreed ! :-)
As stated (or implied ? I should be more clear ... ) in my previous 
post, at least the part on "automagic"  VLANs should belong to the VLAN 
package. But this is a quick hack, not even a real package yet, intended 
to be able to "patch"sarge in production with minimum fuss.



enhance (in this case it could be "ifupdown" or "vlan") to include your
documentation and scripts.  Also, package version and latest date is
alrea

Re: ifupdown-bonding package

[Loïc Minier]

Hi,

On Tue, Oct 18, 2005, Jerome Martin wrote:
> However, I am seeking advice on how to do it / which list to post on /
> which people to contact in order not to mess up with somebody's else's
> work (i.e. vlan package also contain ifupdown hooks, however not
> directly supporting bondX.Y notation in interfaces).

 Documentation on joining the project or helping the project is
 available at:




 I think it should answer your technical questions, and clear up
 anything regarding current procedures.

> Please find below the short README I wrote (no manpage yet ... will make
> one if this is of interest).

 Since I use vlan over bonding and had some trouble myself, I read the
 README as a whole and added comments below.  In general, I think your
 approach is oriented in "let's document how to workaround bugs and make
 it work", while a better approach might be "let's understand and fix
 each bug to let that work flawlessly".

> ifupdown-bonding README
> This is version 0.1 of the package, as of 10/17/2005.
> This package contains hooks for ifupdown in order to add bonding and
> VLAN for bonding syntax to /etc/network/interfaces.

 In general, packages don't hold very small things, especially they
 don't hold a couple of scripts and documentation to enhance another
 package;  instead, you can file a request against the package you
 enhance (in this case it could be "ifupdown" or "vlan") to include your
 documentation and scripts.  Also, package version and latest date is
 already encoded in the changelog of the package, and duplicating it
 means more work.  :)

> [ long list of should and shouldn't ]

 => IMO, it's too heavy to list everything you should and shouldn't do.
 Just give a working example people should follow, if they don't, it
 won't work.

> - If you want to override default values passed to the bonding modules
> without specifying those
>  values in all your interface definitions, use the /etc/network/options
> file.

 That file is deprecated in recent netbase packages.

> [ snip long example of a sample bond device ]
> iface bond0 inet manual
>slaves eth1 eth2

 Good.  Would be nice to include in the interfaces manual page, or along
 the ifenslave packages.

> auto bond0.50
> iface bond0.50 inet static
> 
> auto bond0.60
> iface bond0.60 inet static

 Completely natural examples, that are specific to using bonding + vlan,
 I'd ship these in the same documentation.

 I'd add to this that currently one needs to "configure" the
 /etc/network/if-pre-up.d/vlan script to accept setting vlans on bonding
 interfaces by changing "eth*.*" in "eth*.*|bond*.*".

 I'm personally using my vlaned-bonding-interfaces in bridges, and use
 the following stanza to bring the interface up:

auto bond1.40
iface bond1.40 inet manual
up ifconfig $IFACE up
down ifconfig $IFACE down

 My feeling is that the current ifenslave packages "feel" like Debian
 already, but do not offer advanced options, and the vlan packages
 doesn't feel like Debian and tried encoding information in the
 interface name instead of defining it's keywords as other packages do.

 Thanks for your documentation effort, I hope you'll try to fix the vlan
 package to be more usable on top of bonding.
-- 
Loïc Minier <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please take a look over aspell-ro_0.50-2-1

[Eddy Petrişor]

On 10/18/05, Nicolai Ehemann <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> >>> get an ITP and insert it here
> >
> >
> > not done yet, as I want to have the package fully prepared, then I
> > want to upload it.
>
> I think you missed the sense of an ITP bug: it is intended to be filed
> when packaging *begins* to prevent others from packaging the same thing
> in parallel.

I don't trust myself too much to be sure I will be able to package it
in a reasonable time (my free time comes and goes, so I would not want
to keep somebody else from doing this, if they had more time).

I know is kind of strange, but I made this mistake once and I don't
want to repeat it.

--
Regards,
EddyP
=
"Imagination is more important than knowledge" A.Einstein

Re: [RFS] crystalcursors and kde-icons-nuovext

[Bastian Venthur]

Christoph Haas wrote:

> On Monday 17 October 2005 23:15, Bastian Venthur wrote:
>> Hehe, I guess my package is relatively perfect (and uploaded) now ;)
> 
> The $(CURDIR) is redundant in dh_installchangelogs. But I won't harass
> you with that any more. :)
> 
>> But one last question. What if upstream provides a README, which want to
>> keep. Would it be ok to do my "mv README readme" trick, or is there a
>> dh_* I've overseen?
> 
> I would just dh_install it. Why is it a problem if it's in uppercase?
> 
> Otherwise... the "dh_install" does not allow renaming which has bugged me
> a few times already. So if you really wanted to rename it you would rather
> need to use "install". Moving it away would mean you cannot build the
> package twice (which must be working according to the policy) since the
> second time the source file is no longer there. Or am I wrong?
> 
> Your package is now uploaded. Glad you made it.

Glad you helped me (again) -- thanks very much.

> I'll stick to the nuvola icons on my system though. Less ugly... :)

Uhm' strange you mention nuvola
crystalclear-is-far-better-and-nuvola-needs-a-QA-upload-too
sorry must be something in my throat.

;)


Kind regards

Bastian


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[RFS] kde-icons-nuvola and kde-icons-crystalclear

[Bastian Venthur]

Hi Mentors,

I'm searching for sponsorship of my packages:

kde-icons-nuvola
 + http://packages.qa.debian.org/k/kde-icons-nuvola.html
 + http://venthur.de/debian/nuvola/

This upload is mainly for QA. If you've followed my last RFS for 
kde-icons-nuvoext you might know my rules file was *very* messy and
my .orig.tar.gz was not as it should be. The same problem and solution
applies to this package, wich I released in the same time as nuovext. The
package if of course l/l clean.


kde-icons-crystalclear
 + http://venthur.de/debian/crystalclear/
closes: #322161
 + http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322161
* Package name: kde-icons-crystalclear
  Version : 0.0.20050623 
  Upstream Author : Everaldo Coelho <[EMAIL PROTECTED]>
* URL :
http://www.kde-look.org/content/show.php?content=25668&vote=good&tan=85499329
* License : LGPL
  Description : Everaldo's "Crystal Clear" icon theme for KDE
 Unlike kde-icons-crystal -- which is in fact Everaldos "Crystal SVG" icon 
 theme from 2003, -- this package does not contain graphics in SVG-format.
But
 the "Crystal Clear" icons are newer and seem to be becoming more popular
than
 the "Crystal SVG" icons. 
 .
 On Aug-2005 "Crystal Clear" was the most popular icon theme on
kde-look.org. If
 you like the old "Crystal SVG" you should probably give "Crystal Clear" a
try!

This package is l/l-clean too and if you ask me the best icon theme so far
(my other sets included). It has much more icons than the other ones and
seems to fit very well in the KDE look-n-feel (No wonder, since its the
sucessor of the current default icon theme of KDE3). Please consider
sponsoring this package, I believe this package really contributes some
eyecandy to KDE3.


Kind regards

Bastian


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please take a look over aspell-ro_0.50-2-1

[Nicolai Ehemann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

>>> get an ITP and insert it here
> 
> 
> not done yet, as I want to have the package fully prepared, then I
> want to upload it.

I think you missed the sense of an ITP bug: it is intended to be filed
when packaging *begins* to prevent others from packaging the same thing
in parallel.

Nico
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFDVKTKYm+MkvsfJ58RAp9aAJ4yFPNJXNFVjSvISylcJg0/baH4/wCffLlt
7ZG0MKzONso/CO2naJGEq6Q=
=zhTr
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please take a look over aspell-ro_0.50-2-1

[Eddy Petrişor]

On 10/5/05, Brian Nelson <[EMAIL PROTECTED]> wrote:
> Christoph Berg <[EMAIL PROTECTED]> writes:
>
> > Re: Eddy Petrişor in <[EMAIL PROTECTED]>
> >> Could somebody take a look over it and tell me if I need to make any
> >> changes before I list it on sponsors.d.n ?
> >
> > changelog:
> >  remove the [ ] part

done

> >  get an ITP and insert it here

not done yet, as I want to have the package fully prepared, then I
want to upload it.

> > control:
> >  old Standards-Version

bumped, no change needed

> >  you might want to use the new "Archticture: all" packaging variant,
> >  see for example #319675, otherwise you need to Provides:
> >  aspell6-dictionary
> aspell6a-dictionary, actually (dictionary file locations moved after the
> sarge release).

so I need either "Architecture: all" or Provides: aspell6a-dictionary ?

I looked over the bug specified, but there are some unclear things to
me. How should I provide a gzipped version or the word list? If I gzip
it before packaging then the diff.gz will be huge, right? (As the
original package does not have a compressed word list.)

(Will get to the next ones when I arrive at home.)

--
Regards,
EddyP
=
"Imagination is more important than knowledge" A.Einstein