Nabble - debian-mentors

Re: Urgent: Query on dhclient in handling IP conflict

2009-12-21T21:36:19Z

Please take it to the debian-user list, and don't post the question
repeatedly.

sathya sai wrote:

> Hi,
>
> Can someone please help me out on this.
>
> Thanks and regards,
> Sathya
>
> On Mon, Dec 21, 2009 at 8:09 PM, sathya sai
> <sathyasai.eshwar@...>wrote:
>
>> Hi Matt,
>>
>> Thanks for your mail.
>>
>> I had already thought on these possiblities. But the problem here is, we
>> dont have control over neither our DHCP server (it can be either Windows
>> or Linux based servers) nor the client PC which configures static IP
>> (anybody in the subnet can configure the IPs on their wish). I hope, this
>> is true with the real time deployment scenario.
>>
>> Considering all these scenario, I felt that it would be better for our
>> dhclient to do a ARP broadcast as per RFC 2131 to detect the IP conflict
>> and send DHCPDECLINE in case of it. So that the DHCP server can
>> understand the existance of duplicate address and respond with the newer
>> address accordingly.
>>
>> Could please let me know your thoughts on this, so that we can make your
>> dhclient much more better on this.
>>
>> Thanks and regards,
>> Sathya
>>
>>
>>
>> On Mon, Dec 21, 2009 at 7:22 PM, Mathieu Trudel-Lapierre <mathieu.tl@
>> gmail.com> wrote:
>>
>>> On Mon, Dec 21, 2009 at 8:22 AM, sathya sai
>>> <sathyasai.eshwar@...>
>>> wrote:
>>> > Hi Paul,
>>> >
>>> > I hope, this is a common problem with the dhclient which would occur
>>> even
>>> > on debian lenny.
>>> >
>>> > Thanks and regards,
>>> > Sathya
>>> >
>>> > On Mon, Dec 21, 2009 at 6:47 PM, Paul Wise <pabs@...> wrote:
>>> >>
>>> >> On Mon, Dec 21, 2009 at 9:03 PM, sathya sai <
>>> sathyasai.eshwar@...>
>>> >> wrote:
>>> >>
>>> >> > Could you please help me out by directing this query to the
>>> appropriate
>>> >> > forum.
>>> >>
>>> >> debian-user would be the appropriate forum.
>>> >>
>>> >> Please note that Debian etch is very old and will soon lose security
>>> >> support. You should really upgrade to Debian lenny at your earliest
>>> >> convenience. I'd suggest testing for the bug on both lenny and the
>>> >> in-development release, squeeze.
>>> >>
>>>
>>> Without wanting to diminish what you've done (which certainly aims at
>>> resolving a particular issue you might have been seeing), I think
>>> there would be more elegant solutions to your problem than IP conflict
>>> detection (although it could be nice to have, it would probably be
>>> more effectively reported upstream).
>>>
>>> TL;DR: There is another way to avoid conflicts without requiring *any*
>>> development on dhcp3-server or dhcp3-client. You can use reservations
>>> or change the IP pool range to resolve this issue.
>>>
>>> Longer version:
>>>
>>> What I'd do in this case is either of two solutions:
>>>
>>> 1- Rather simply, and to retain most of what has been done already;
>>> change the DHCP range of IP addresses given out to "dynamic" clients
>>> to something that doesn't contain the IP of the machines that are
>>> statically assigned.
>>>
>>> For example, set aside 2-31 for statically assigned systems, then
>>> 32-254 for dynamic assignment.
>>>
>>> 2- Slightly change the setup: have all the systems get an IP from
>>> DHCP, but make sure that the IPs given out to the machines that should
>>> be statically assigned are always the same. You can do this easily
>>> using reservations, which is a matter of matching an IP to a
>>> particular MAC address. In dnsmasq, that's done with /etc/ethers. In
>>> dhcpd, it's done in dhcpd.conf in a special stanza.
>>>
>>> Both these options address the same issue: systems will no longer be
>>> assigned conflicting IP addresses. Additionally, there are some pretty
>>> nifty things you could do with option 2 from then on, such as
>>> dynamically building DNS information from the DHCP leases. Your
>>> "servers" which as assigned the same IP all the time are always there,
>>> and names of the "clients" (which could be new systems added from
>>> visitors or whatever), could "publish" their desired name through DHCP
>>> and have this information visible in DNS requests (just as you could
>>> also do reverse DNS).
>>>
>>> Sorry if this is rather verbose, just expressing a different way of
>>> solving the situation.
>>>
>>> With kind regards,
>>>
>>> / Matt
>>>
>>
>>

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Urgent: Query on dhclient in handling IP conflict

2009-12-21T20:00:35Z

Hi,

Can someone please help me out on this.

Thanks and regards,
Sathya

On Mon, Dec 21, 2009 at 8:09 PM, sathya sai <sathyasai.eshwar@...> wrote:

Hi Matt,

Thanks for your mail.

I had already thought on these possiblities. But the problem here is, we dont have control over neither our DHCP server (it can be either Windows or Linux based servers) nor the client PC which configures static IP (anybody in the subnet can configure the IPs on their wish). I hope, this is true with the real time deployment scenario.

Considering all these scenario, I felt that it would be better for our dhclient to do a ARP broadcast as per RFC 2131 to detect the IP conflict and send DHCPDECLINE in case of it. So that the DHCP server can understand the existance of duplicate address and respond with the newer address accordingly.

Could please let me know your thoughts on this, so that we can make your dhclient much more better on this.

Thanks and regards,
Sathya

On Mon, Dec 21, 2009 at 7:22 PM, Mathieu Trudel-Lapierre <mathieu.tl@gmail.com> wrote:

On Mon, Dec 21, 2009 at 8:22 AM, sathya sai <sathyasai.eshwar@...> wrote:
> Hi Paul,
>
> I hope, this is a common problem with the dhclient which would occur even
> on debian lenny.
>
> Thanks and regards,
> Sathya
>
> On Mon, Dec 21, 2009 at 6:47 PM, Paul Wise <pabs@...> wrote:
>>
>> On Mon, Dec 21, 2009 at 9:03 PM, sathya sai <sathyasai.eshwar@...>
>> wrote:
>>
>> > Could you please help me out by directing this query to the appropriate
>> > forum.
>>
>> debian-user would be the appropriate forum.
>>
>> Please note that Debian etch is very old and will soon lose security
>> support. You should really upgrade to Debian lenny at your earliest
>> convenience. I'd suggest testing for the bug on both lenny and the
>> in-development release, squeeze.
>>

Without wanting to diminish what you've done (which certainly aims at
resolving a particular issue you might have been seeing), I think
there would be more elegant solutions to your problem than IP conflict
detection (although it could be nice to have, it would probably be
more effectively reported upstream).

TL;DR: There is another way to avoid conflicts without requiring *any*
development on dhcp3-server or dhcp3-client. You can use reservations
or change the IP pool range to resolve this issue.

Longer version:

What I'd do in this case is either of two solutions:

1- Rather simply, and to retain most of what has been done already;
change the DHCP range of IP addresses given out to "dynamic" clients
to something that doesn't contain the IP of the machines that are
statically assigned.

For example, set aside 2-31 for statically assigned systems, then
32-254 for dynamic assignment.

2- Slightly change the setup: have all the systems get an IP from
DHCP, but make sure that the IPs given out to the machines that should
be statically assigned are always the same. You can do this easily
using reservations, which is a matter of matching an IP to a
particular MAC address. In dnsmasq, that's done with /etc/ethers. In
dhcpd, it's done in dhcpd.conf in a special stanza.

Both these options address the same issue: systems will no longer be
assigned conflicting IP addresses. Additionally, there are some pretty
nifty things you could do with option 2 from then on, such as
dynamically building DNS information from the DHCP leases. Your
"servers" which as assigned the same IP all the time are always there,
and names of the "clients" (which could be new systems added from
visitors or whatever), could "publish" their desired name through DHCP
and have this information visible in DNS requests (just as you could
also do reverse DNS).

Sorry if this is rather verbose, just expressing a different way of
solving the situation.

With kind regards,

/ Matt

Re: RFS: piwigo

2009-12-21T14:21:23Z

Hi,

thanks Sylvain, I'll apprciate.

Regards,
Nicolas

2009/12/21 Sylvain Le Gall <gildor@...>

Hello,

I'll help you upload it...

Regards,
Sylvain Le Gall

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

signature.asc (576 bytes) Download Attachment

Re: RFS: piwigo

2009-12-21T14:16:36Z

Hello,

I'll help you upload it...

Regards,
Sylvain Le Gall

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

RFS: piwigo

2009-12-21T14:01:30Z

Dear mentors,

I am looking for a sponsor for my package "piwigo".

* Package name    : piwigo
Version         : 2.0.7-1
Upstream Author : Pierrick LE-GALL    plg@...
* URL             : http://piwigo.org/
* License         : GPL
Section         : web

Piwigo is photo gallery software for the web.
Piwigo is a photo gallery software for the web, built by an active community
of users and developers. Extensions make Piwigo easily customizable.
Some greats features :
- localization in English, French, German, Spanish, Italian, Portuguese, ...
- tags
- permissions on photos and categories
- virtual category allowing picture to be in multiple categories
- meaningful URLs
- user comments and rating
- use of iptc and exif metadatas
- notification of news by email or RSS feed
- best rated, most view pictures
- web API allowing requests or administration from other applications.

The package appears to be lintian clean.

The upload would fix these bugs: 561868

My motivation for maintaining this package is:
I like this software and I'm involved in his development. I can follow easier features.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/p/piwigo
- Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/p/piwigo/piwigo_2.0.7-1.dsc

I would be glad if someone uploaded this package for me.

Regards,
Nicolas Roudaire

signature.asc (576 bytes) Download Attachment

Re: Urgent: Query on dhclient in handling IP conflict

2009-12-21T06:39:52Z

Hi Matt,

Thanks for your mail.

I had already thought on these possiblities. But the problem here is, we dont have control over neither our DHCP server (it can be either Windows or Linux based servers) nor the client PC which configures static IP (anybody in the subnet can configure the IPs on their wish). I hope, this is true with the real time deployment scenario.

Considering all these scenario, I felt that it would be better for our dhclient to do a ARP broadcast as per RFC 2131 to detect the IP conflict and send DHCPDECLINE in case of it. So that the DHCP server can understand the existance of duplicate address and respond with the newer address accordingly.

Could please let me know your thoughts on this, so that we can make your dhclient much more better on this.

Thanks and regards,
Sathya

On Mon, Dec 21, 2009 at 7:22 PM, Mathieu Trudel-Lapierre <mathieu.tl@gmail.com> wrote:

On Mon, Dec 21, 2009 at 8:22 AM, sathya sai <sathyasai.eshwar@...> wrote:
> Hi Paul,
>
> I hope, this is a common problem with the dhclient which would occur even
> on debian lenny.
>
> Thanks and regards,
> Sathya
>
> On Mon, Dec 21, 2009 at 6:47 PM, Paul Wise <pabs@...> wrote:
>>
>> On Mon, Dec 21, 2009 at 9:03 PM, sathya sai <sathyasai.eshwar@...>
>> wrote:
>>
>> > Could you please help me out by directing this query to the appropriate
>> > forum.
>>
>> debian-user would be the appropriate forum.
>>
>> Please note that Debian etch is very old and will soon lose security
>> support. You should really upgrade to Debian lenny at your earliest
>> convenience. I'd suggest testing for the bug on both lenny and the
>> in-development release, squeeze.
>>

Without wanting to diminish what you've done (which certainly aims at
resolving a particular issue you might have been seeing), I think
there would be more elegant solutions to your problem than IP conflict
detection (although it could be nice to have, it would probably be
more effectively reported upstream).

TL;DR: There is another way to avoid conflicts without requiring *any*
development on dhcp3-server or dhcp3-client. You can use reservations
or change the IP pool range to resolve this issue.

Longer version:

What I'd do in this case is either of two solutions:

1- Rather simply, and to retain most of what has been done already;
change the DHCP range of IP addresses given out to "dynamic" clients
to something that doesn't contain the IP of the machines that are
statically assigned.

For example, set aside 2-31 for statically assigned systems, then
32-254 for dynamic assignment.

2- Slightly change the setup: have all the systems get an IP from
DHCP, but make sure that the IPs given out to the machines that should
be statically assigned are always the same. You can do this easily
using reservations, which is a matter of matching an IP to a
particular MAC address. In dnsmasq, that's done with /etc/ethers. In
dhcpd, it's done in dhcpd.conf in a special stanza.

Both these options address the same issue: systems will no longer be
assigned conflicting IP addresses. Additionally, there are some pretty
nifty things you could do with option 2 from then on, such as
dynamically building DNS information from the DHCP leases. Your
"servers" which as assigned the same IP all the time are always there,
and names of the "clients" (which could be new systems added from
visitors or whatever), could "publish" their desired name through DHCP
and have this information visible in DNS requests (just as you could
also do reverse DNS).

Sorry if this is rather verbose, just expressing a different way of
solving the situation.

With kind regards,

/ Matt

RFS: calculix

2009-12-21T06:35:09Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear mentors,

I am looking for a sponsor for my packages for "calculix".

* Package names : calculix-ccx, calculix-cgx
Version : 2.0.0-1
Upstream Author : pierrot <idf.dresden@...>
* URL : http://www.calculix.de
* License : gpl
Section : science

It builds these binary packages:

ccx - calculix crunchix - finite element program (solver)
cgx - calculix graphix - finite element program (pre/postprocessor)

The upload would fix these bugs: #506518

My motivation for maintaining this package is:

calculix is a small but very powerful and well documented 3d fea
program, which is maintained by a crowd of enthusiasts, it runs
platform-independent, connects to many other fea tools (e.g. gmsh)
and would fit nicely into debian

The packages can be found on mentors.debian.net:

- - URL: http://mentors.debian.net/debian/pool/main/c/calculix-ccx
- - Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- - dget
http://mentors.debian.net/debian/pool/main/c/calculix-ccx/calculix-ccx_2.0.0-1.dsc

- - URL: http://mentors.debian.net/debian/pool/main/c/calculix-cgx
- - Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- - dget
http://mentors.debian.net/debian/pool/main/c/calculix-cgx/calculix-cgx_2.0.0-1.dsc

I would be glad if someone uploaded these packages for me.

Kind regards

pierrot
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksvh50ACgkQNDe+3b60z64XkwCfalLGy9uyhz39eX6QipUIVsmx
5r8AoIS3kkv6olunu5+uttfSrg4AqUQF
=7qGr
-----END PGP SIGNATURE-----

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: RFS: gtkhash (2nd try)

2009-12-21T05:56:01Z

Alessio Treglia wrote:

> Dear mentors,
>
> I am looking for a sponsor for my package "gtkhash".

Uploaded :)

David

--
. ''`. Debian developer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 ----|---- http://snipr.com/qa_page
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: RFS: hexalate

2009-12-21T05:51:57Z

Il giorno lun, 21/12/2009 alle 21.13 +0800, Tang Ke ha scritto:
> Dear mentors,
>
> I am looking for a sponsor for my package "hexalate".
>
> * Package name : hexalate
> Version : 1.0.0-1
> [...]
> The upload would fix these bugs: 561801

As it was pointed out in this bug, hexalate is already in Debian (and
that same version is in Ubuntu too).

Moreover, just as a reference, there are some things that would need to
be tuned in your package. Luckily, you can just discover them by
comparing it with the already existing one:

mkdir 1
mkdir 2
cd 1
apt-get source hexalate
cd ../2
dget \
http://mentors.debian.net/debian/pool/main/h/hexalate/hexalate_1.0.0-1.dsc
dpkg -x dpkg-source -x hexalate_1.0.0-1.dsc
diff -r hexalate-1.0.0 ../1/hexalate-1.0.0 | less

You'll see some changes due to CDBS, but also some things that you would
have had to clean; for instance, the long description, the qt4-qmake
build-dependency, the "On Ubuntu systems" in debian/copyright.

Pietro

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Urgent: Query on dhclient in handling IP conflict

2009-12-21T05:22:52Z

Hi Paul,

I hope, this is a common problem with the dhclient which would occur even on debian lenny.

Thanks and regards,
Sathya

On Mon, Dec 21, 2009 at 6:47 PM, Paul Wise <pabs@...> wrote:

On Mon, Dec 21, 2009 at 9:03 PM, sathya sai <sathyasai.eshwar@...> wrote:

> Could you please help me out by directing this query to the appropriate
> forum.

debian-user would be the appropriate forum.

Please note that Debian etch is very old and will soon lose security
support. You should really upgrade to Debian lenny at your earliest
convenience. I'd suggest testing for the bug on both lenny and the
in-development release, squeeze.

--
bye,
pabs

http://wiki.debian.org/PaulWise

Re: Urgent: Query on dhclient in handling IP conflict

2009-12-21T05:17:02Z

On Mon, Dec 21, 2009 at 9:03 PM, sathya sai <sathyasai.eshwar@...> wrote:

> Could you please help me out by directing this query to the appropriate
> forum.

debian-user would be the appropriate forum.

Please note that Debian etch is very old and will soon lose security
support. You should really upgrade to Debian lenny at your earliest
convenience. I'd suggest testing for the bug on both lenny and the
in-development release, squeeze.

--
bye,
pabs

http://wiki.debian.org/PaulWise

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

RFS: hexalate

2009-12-21T05:13:33Z

Dear mentors,

I am looking for a sponsor for my package "hexalate".

* Package name : hexalate
Version : 1.0.0-1
Upstream Author : Graeme Gott<graeme@...>
* URL : http://gottcode.org/hexalate
* License : GPLV3
Section : games

It builds these binary packages:
hexalate - a color matching game

The package appears to be lintian clean.

The upload would fix these bugs: 561801

My motivation for maintaining this package is:

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/h/hexalate
- Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/h/hexalate/hexalate_1.0.0-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
Tang Ke

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Fwd: Urgent: Query on dhclient in handling IP conflict

2009-12-21T05:03:33Z

Hi,

Could you please help me out by directing this query to the appropriate forum.

Thanks and regards,

Sathya

---------- Forwarded message ----------
From: sathya sai <sathyasai.eshwar@...>
Date: Mon, Dec 21, 2009 at 5:51 PM
Subject: Urgent: Query on dhclient in handling IP conflict
To: peloy@..., mdz@..., apollock@...
Cc: sathya sai <sathyasai.eshwar@...>

Hi All,

This is Sathya, a debian etch user who uses dhclient package to configure the IP address.

Firstly, I would like to give my heartily thanks to you all for your great dedicated contribution towards this package. As I am newbie to this mailing list, I am not aware on where to post this query. So, thought of this mail directly sending it to you all.

My system has following dhclient packages,

ii dhcp3-client                     3.0.4-13+etch2                    DHCP Client
ii dhcp3-common                 3.0.4-13+etch2                   Common files used by all the dhcp3* packages
ii dhcp3-server                     3.0.4-13+etch2                   DHCP server for automatic IP address assignm

Following is the problem which I am facing now,

I have a subnet whose IP addressing is managed by DHCP server. But, one system in that is intentionally assigned a static IP address. In multiple occasions, I am now getting IP conflicts in my subnet.

On further analysing this problem, I could undertand that this probelm is happening because,

1. As DHCP server is un-aware of this statically configured system; upon receiving the DHCPREQUEST from a system (which is running dhclient) from this subnet, the DHCP server gets an unused IP from its IP pools offers it to that client. In somecases, dhcp server is giving the same IP address as that of statically configured system.

2. As on receiving the IP address, our dhclient is not performing a final check on the existence of IP conflict for prior received IP address using ARP broadcast, it goes ahead in configuring the system with this IP address. This results in an IP conflict to exist between these two systems (with this system and a system with statically configured IP).

I could also see that, our debian dhclient presently DOES NOT HAVE AN OPTION TO IMPLICITLY SUPPORT THIS.

But as per RFC 2131, the client should perform a final check to detect the IP conflict and send DHCPDECLINE message. Please find the RFC snippet as in below,

"5. The client receives the DHCPACK message with configuration
     parameters. The client SHOULD perform a final check on the
     parameters (e.g., ARP for allocated network address), and notes the
     duration of the lease specified in the DHCPACK message. At this
     point, the client is configured. If the client detects that the
     address is already in use (e.g., through the use of ARP), the
     client MUST send a DHCPDECLINE message to the server and restarts
     the configuration process."

And also I could find the following information on dhclient manpage regarding this,

"      Before actually configuring the address, dhclient-script should somehow
       ARP for it and exit with a nonzero status if it receives a reply.    In
       this case, the client will send a DHCPDECLINE message to the server and
       acquire a different address.   This may also be done in the RENEW,
       REBIND, or REBOOT states, but is not required, and indeed may not be
       desirable."

As changes to DHCP server is out of our control & we are not sure on what IP would be statically configured to the system, could you please let me know your thoughts on how do this we can fix this in dhclient code to automatically detect duplicate address using ARP broadcast ?

If this support this not there in present dhclient, could you please let me know by when this the community planning to give a patch for this.

As I am in need of urgent need for fix on this issue, it would be really helpful if I can get your thoughts on this by earliest.

Thanks a lot in advance for understanding.

Regards,

Sathya

Re: Writing manpages (was: Re: Man and UTF-8.)

2009-12-21T04:58:04Z

Hi Rogério,

Em Wed, Nov 18, 2009 at 07:33:22AM -0200, Rogério Brito escreveu:
| Date: Wed, 18 Nov 2009 07:33:22 -0200
| From: Rogério Brito <rbrito@...>
| To: debian-mentors@...
| Subject: Re: Writing manpages (was: Re: Man and UTF-8.)
|
| I guess that I only have two options left, as it seems: Perl's pod
| format or docbook. The only problem with docbook is that I don't know
| how to avoid the torrent of markups and typing some of them is long.
|
| Now, if there were some LaTeX -> man, that would be amazing.

Have you ever tried txt2tags ? http://txt2tags.sourceforge.net/
You can write almost anything using its wiki format and convert to
man, latex, wikiwiki, and so on ;-)

It's really simple to use it :D

Cheers,

LEslie

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

RFS: simple-scan

2009-12-20T22:54:29Z

Dear mentors,

I am looking for a sponsor for my package "simple-scan".

* Package name : simple-scan
Version : 0.7.6-1
Upstream Author : Robert Ancell <robert.ancell@...>
* URL : https://launchpad.net/simple-scan
* License : GPL
Section : gnome

It builds these binary packages:
simple-scan - Simple Scanning Utility

The package appears to be lintian clean.

The upload would fix these bugs: 561790

My motivation for maintaining this package is: I use this application
in Ubuntu and I would like to see it entering to Debian.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/s/simple-scan
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/s/simple-scan/simple-scan_0.7.6-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
Alessio Treglia

--
Alessio Treglia <quadrispro@...>
Ubuntu MOTU Developer | Homepage: http://www.alessiotreglia.com
0FEC 59A5 E18E E04F 6D40 593B 45D4 8C7C DCFC 3FD0

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

RFS: gtkhash (2nd try)

2009-12-20T22:50:50Z

Dear mentors,

I am looking for a sponsor for my package "gtkhash".

* Package name : gtkhash
Version : 0.3.0-1
Upstream Author : Tristan Heaven <tristanheaven@...>
* URL : http://gtkhash.sourceforge.net
* License : GPL-2
Section : utils

It builds these binary packages:
gtkhash - GTK+ utility for computing checksums and more

The package appears to be lintian clean.

The upload would fix these bugs: 560213

My motivation for maintaining this package is: I use that package in
Ubuntu and I would like to see it entering to Debian.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/g/gtkhash
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/g/gtkhash/gtkhash_0.3.0-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
Alessio Treglia

--
Alessio Treglia <quadrispro@...>
Ubuntu MOTU Developer | Homepage: http://www.alessiotreglia.com
0FEC 59A5 E18E E04F 6D40 593B 45D4 8C7C DCFC 3FD0

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: example vs contrib?

2009-12-20T15:50:31Z

On Mon, 2009-12-21 at 00:03 +0100, Ludovico Cavedon wrote:

> Hi all,
> Upstream for tortoisehg (interface for mercurial) distributes in their
> tarball a file:
> contrib/_hgtk
> which enables zsh completion script for tortoisehg.
>
> I am not a zsh user and I would not feel confident in installing that
> script in a location so it is automatically enabled for all zsh users,
> nevertheless I would like to distribute it. What do you think is the
> proper location?
>
> /usr/share/tortoise-hg/contrib/_hgtk
> /usr/share/tortoise-hg/examples/_hgtk
> other?
>
> Max (in CC) and I had a discussion about that and could not agree :)

Ask upstream to submit the zsh completion to zsh. And in the meanwhile,
install it globally for all zsh users. If there are problems, they will
be reported, and you can forward them to upstream.

--
Saludos,
Felipe Sateler

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

example vs contrib?

2009-12-20T15:03:55Z

Hi all,
Upstream for tortoisehg (interface for mercurial) distributes in their
tarball a file:
contrib/_hgtk
which enables zsh completion script for tortoisehg.

I am not a zsh user and I would not feel confident in installing that
script in a location so it is automatically enabled for all zsh users,
nevertheless I would like to distribute it. What do you think is the
proper location?

/usr/share/tortoise-hg/contrib/_hgtk
/usr/share/tortoise-hg/examples/_hgtk
other?

Max (in CC) and I had a discussion about that and could not agree :)

Thanks,
Ludovico

signature.asc (269 bytes) Download Attachment

RFS: symfony (NMU, fixes RC bug)

2009-12-20T04:10:30Z

Dear mentors,

I am looking for a sponsor for the new version 1.0.21-1.1
of the package "symfony".

I've contacted the maintainer and he agrees with the upload (all his packages are lowNMU). I've also forwarded the bug and patch upstream, [1] [2]

It builds these binary packages:
php5-symfony1.0 - Open-Source PHP Web Framework

The upload would fix this bug: 555249 (RC bug)

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/s/symfony
- Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/s/symfony/symfony_1.0.21-1.1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
Federico Gimenez Nieto

[1] http://forum.symfony-project.org/index.php/t/24367/
[2] http://trac.symfony-project.org/ticket/7922

signature.asc (204 bytes) Download Attachment

Re: RFS: poco (updated package)

2009-12-20T01:31:40Z

Patrick Roland Gansterer writes:
> Dear mentors,

Hi,

(I'm the usual sponsor of poco and poco-doc, and I'm looking for co-
sponsors;-)

Some preliminary comments follow:

> I am looking for a sponsor for the new version 1.3.6-1
> of package "poco" and "poco-doc".
>
> It builds these binary packages:
> libpoco-dev - Development files for POCO - The C++ Portable Components
> libpococrypto9 - The C++ Portable Components Crypto library
> libpococrypto9-dbg - The C++ Portable Components Crypto library, debug
> version libpocodata9 - The C++ Portable Components Data library
> libpocodata9-dbg - The C++ Portable Components Data library, debug version
> libpocofoundation9 - The C++ Portable Components Foundation library
> libpocofoundation9-dbg - The C++ Portable Components Foundation library,
> debug version
> libpocomysql9 - The C++ Portable Components MySQL library
> libpocomysql9-dbg - The C++ Portable Components MySQL library, debug
> version libpoconet9 - The C++ Portable Components Network library
> libpoconet9-dbg - The C++ Portable Components Network library, debug
> version libpoconetssl9 - The C++ Portable Components Network library with
> SSL libpoconetssl9-dbg - The C++ Portable Components Network library with
> SSL, dbg version
> libpocoodbc9 - The C++ Portable Components ODBC library
> libpocoodbc9-dbg - The C++ Portable Components ODBC library, debug version
> libpocosqlite9 - The C++ Portable Components SQLite library
> libpocosqlite9-dbg - The C++ Portable Components SQLite library, debug
> version libpocoutil9 - The C++ Portable Components Util library
> libpocoutil9-dbg - The C++ Portable Components Util library, debug version
> libpocoxml9 - The C++ Portable Components XML library
> libpocoxml9-dbg - The C++ Portable Components XML library, debug version
> libpocozip9 - The C++ Portable Components Zip library
> libpocozip9-dbg - The C++ Portable Components Zip library, debug version
>
> The upload would fix these bugs: 545854, 548113, 560936

I'll have a look at these these days. However, clamfs package would require a
rebuild, at least, so maintainer CC'ed (who is also a co-maintainer of poco).

As a side note: poco is still breaking the binary compatibility with each new
upstream release. I understand that while a library is still young and
evolving that could be really needed sometimes to properly fix improper design
decisions being made in the past. However, poco seems to be well established
already, and I imagine it would follow the 'good library management' practices
for instance as described in dpkg-gensymbols(1) under the section of 'Good
library management'. Otherwise, we lose one of the key features of libraries,
adherence to the interface contract it already published, which just makes the
thing harder to reuse. Yes, I know boost is in the same boat, but at least
they claim they are researching, and don't care too much for practical
consequences which arise with distributing the product. So, the main question
being: poco is going to perform good library management in the future, or they
are going to be like boost camp? With poco we are lucky that we don't have so
many packages to depends on it, however that might change in the future, and
we certainly face a trouble with it.

> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/p/poco
> - Source repository: deb-src http://mentors.debian.net/debian unstable main
> contrib non-free
> - dget http://mentors.debian.net/debian/pool/main/p/poco/poco_1.3.6-1.dsc
>
> I would be glad if someone uploaded this package for me.

I'll take care.

--
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: RFS: dma (bugfixes, debconf, 3.0 (quilt))

2009-12-19T11:45:27Z

Peter Pentchev writes:

> On Sat, Dec 12, 2009 at 04:56:45PM +0200, George Danchev wrote:
> > > Dear mentors,
> > >
> > > I am looking for a sponsor for the new version 0.0.2009.07.17-3
> > > of my package "dma", the DragonFly Mail Agent. This version
> > > fixes a couple of bugs, updates the debconf translations, and
> > > converts the package to the 3.0 (quilt) source format.
>
> [snip]
>
> I've uploaded a new package with the same version number,
> 0.0.2009.07.17-3; the mentors.d.n URL is the same,
> http://mentors.debian.net/debian/pool/main/d/dma/dma_0.0.2009.07.17-3.dsc
>
> The changes are:
> - the postinst script does an additional chown/chmod if necessary
> (see below)
> - the smarthost and dbounceprog are always taken from the debconf
> database, never from the (possibly modified by hand) dma.conf file;
> this fixes #544663, since there is no way to tell if the dma.conf
> contents are from a modification by hand or from an earlier debconf
> run with the default "mail.example.com" value!
> - the debian/config script mistakenly looked for "defer" instead of
> "dbounceprog"
>
> See below for more comments.
>
> > > * Really install the files in /etc/dma/ as root/mail/640.
> > > Closes: #544664
> >
> > That only works for a newly installed dma package, and won't work for
> > upgrading from older versions. My best bet on that would be a debconf
> > question asking the user to perform the above actions on files at
> > /etc/dma/.
>
> Well, actually, upon thinking about it a bit more, it turns out that
> a debconf question is never really needed. The dma executable binary
> is always installed setgid mail, so root/mail/640 for /etc/dma/*
> Should Be Enough For Everyone(tm) :)

That is also true, and actually preferred way to go in that case.

> I've added a snippet to the postinst script, checking whether we're
> upgrading from an earlier version and doing the chown/chmod if so.
> IMHO, this should cover all cases.
>
> > > * Install the /usr/bin/mailq and /usr/bin/newaliases symlinks.
> > > Closes: #558421
> > > * Switch to the 3.0 (quilt) source format.
> > > * Update the debconf translations:
> > > - add German. Closes: #552754
> > > - add Japanese. Closes: #554515
> > > - remove a double space and unfuzzy the translations. Closes:
> > > #552586 * Fix a crash when the SMTP server does not support STARTTLS.
> > > Closes: #547594
> >
> > I had a look at 25-unsupported-starttls.patch, which looks good to me,
> > however I was not able to test it, so I assume you have tested that
> > as well.
>
> Yes, it's really easy to test - just point dma to any mailserver that
> does not recognize the STARTTLS command on port 25 :) But, yes, I've
> tested it and it seems to work.

Yeah, time (check on the run;-) now upon upload, I tested with and without
STARTTLS.

> > By the way, IMO having so many patches in debian/patches (in fact much
> > more than source files;-) looks like you are trying to develop there,
> > nothing wrong with that, but it is not the most suitable place for that
> > purpose. For instance, 9K 20-parse-recipient.patch is suitable for a new
> > feature branch. IMO you either push that harder upstream [1], slow down
> > pushing such feature patches with the package or fork the whole thing
> > upstream and form a new project. Actually you have already diverged that
> > enough to do the latter. IMO, debian/patches should be only for patches
> > specific to Debian, feature explosions should be evolved upstream ;-)
> >
> > [1] though I don't see that rejected at (as written in the patch header):
> > http://bugs.dragonflybsd.org/issue1321
>
> Well, I wrote most of those patches because without them, dma either simply
> could not replace a local MTA (e.g. the "sendmail -t" mode tha many, many
> programs use to send e-mail messages in a really simple way), or did some
> really weird things (e.g. the "seen" patch that was later integrated and
> without which dma would list the same message several times when listing
> the queue with no indication whether it was needed or not). Most of
> the patches were accepted upstream, and some (like -t processing) were
> not explicitly rejected, but implemented in a different way in later
> versions. When I finish integrating a later snapshot of dma in my
> local repository, you'll see the next Debian upload with a lot less
> non-Debian-specific patches :)

Okay, I'd really like that.

> Yes, I know debian/patches is not intended as a development repository,
> especially on a project with a very active and responsive upstream, as
> dma happens to be. I don't do this with other packages, but this
> particular case was special - in order to be an easily-usable MTA, dma
> needed a couple of nudges in the right direction, but definitely not
> enough to warrant a full-scale fork on my part.

Good. My whole point was not to silently grow a thoroughly different/deviated
dma while packaging it for Debian ;-)

> Thanks for taking a look at it and for the comments; and thanks in advance
> should you decide to also take a look at the new version :)

Welcome.

--
pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu>

signature.asc (853 bytes) Download Attachment

Re: Fuppes: Package Names and the Separation of a Project into Packages

2009-12-19T09:06:15Z

On Sat, Dec 19, 2009 at 02:18:22PM +0100, Christoph Egger wrote:
> Hm I'd first consider the size of each of the plugin packages. If
> they're relatively small you could consider grouping them, seems
> like that it is already somewhat done in core, database, encoder,
> metadata, ... if these are not depending on each other it could be
> a sensible choice. If they're really small all in one is ok as
> well.

Equally important in this decision is the size and number of
dependencies for each package. While the packages themselves may be
small, the fine-grained split may have been intended more to avoid
the user installing a ton of dependencies for particular features
they didn't need anyway.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fungi@...); IRC(fungi@...#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fungi@...);
MUD(fungi@...:6669); WWW(http://fungi.yuggoth.org/); }

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

RFS: qodem

2009-12-19T07:15:44Z

Dear mentors,

I am looking for a sponsor for my package "qodem".

* Package name    : qodem
  Version         : 0.2.0-1
  Upstream Author : Kevin Lamonte <kevin.lamonte@...>

* URL             : http://qodem.sourceforge.net
* License         : GPLv2+
  Section         : comm

It builds these binary packages:
qodem      - friendly ncurses-based Unicode-aware communications package


The upload would fix these bugs: 560902

My motivation for maintaining this package is: I think Debian users will find it useful.
  - Qodem can do serial communications (like minicom), but it can also fork PTYs to

    support ssh, rsh, telnet, rlogin, or just spawn a locel shell.
  - It has its own internal Xmodem, Ymodem, Zmodem, and Kermit support, so it can
    transfer files over ssh, telnet, etc.
  - VT100/VT102 and VT220 emulations are decent (they pass vttest). LINUX and XTERM

    emulations support both 8-bit and UTF-8.  It also supports BBS-style ANSI.SYS
    and Avatar, VT52, and has a DEBUG emulation that displays a hexdump of incoming
    bytes.
  - It supports UTF-8 encoding and can display DEC Supplemental Graphics, VT220 National

    Replacement Character sets, and CP437 (VGA).
  - It has BBS-style scrollback, screen dump, capture, and phonebook features.
  - It can run directly off the raw Linux console (when the console is UTF-8).

The package can be found on mentors.debian.net:

- URL: http://mentors.debian.net/debian/pool/main/q/qodem
- Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free

- dget http://mentors.debian.net/debian/pool/main/q/qodem/qodem_0.2.0-1.dsc

I would be glad if someone uploaded this package for me.


Kind regards
 Kevin Lamonte

RFS: mbuffer (new upstream, fix FTBFS, prefer libmhash)

2009-12-19T05:54:09Z

Dear mentors,

I am looking for a sponsor for the new version 20091213-1
of my package "mbuffer". In addition to the new upstream
version, there's a FTBFS bug fixed, and the Debian package
now properly builds against libmhash, not GnuTLS, as
discussed with Mats Erik Andersson on this list and in
the ITP bug log.

There is a single binary package:
mbuffer - tool for buffering data streams

The package has been tested with lintian and pbuilder.

The upload would fix these bugs: 560750 (FTBFS on kFreeBSD)

The package can be found on mentors.debian.net:
http://mentors.debian.net/debian/pool/main/m/mbuffer/mbuffer_20091213-1.dsc

I would be glad if someone uploaded this package for me.

G'luck,
Peter

--
Peter Pentchev roam@... roam@... roam@...
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
No language can express every thought unambiguously, least of all this one.

attachment0 (851 bytes) Download Attachment

Re: RFS: dma (bugfixes, debconf, 3.0 (quilt))

2009-12-19T05:50:36Z

On Sat, Dec 12, 2009 at 04:56:45PM +0200, George Danchev wrote:
> > Dear mentors,
> >
> > I am looking for a sponsor for the new version 0.0.2009.07.17-3
> > of my package "dma", the DragonFly Mail Agent. This version
> > fixes a couple of bugs, updates the debconf translations, and
> > converts the package to the 3.0 (quilt) source format.
[snip]

I've uploaded a new package with the same version number,
0.0.2009.07.17-3; the mentors.d.n URL is the same,
http://mentors.debian.net/debian/pool/main/d/dma/dma_0.0.2009.07.17-3.dsc

The changes are:
- the postinst script does an additional chown/chmod if necessary
(see below)
- the smarthost and dbounceprog are always taken from the debconf
database, never from the (possibly modified by hand) dma.conf file;
this fixes #544663, since there is no way to tell if the dma.conf
contents are from a modification by hand or from an earlier debconf
run with the default "mail.example.com" value!
- the debian/config script mistakenly looked for "defer" instead of
"dbounceprog"

See below for more comments.

> > * Really install the files in /etc/dma/ as root/mail/640.
> > Closes: #544664
>
> That only works for a newly installed dma package, and won't work for
> upgrading from older versions. My best bet on that would be a debconf
> question asking the user to perform the above actions on files at
> /etc/dma/.

Well, actually, upon thinking about it a bit more, it turns out that
a debconf question is never really needed. The dma executable binary
is always installed setgid mail, so root/mail/640 for /etc/dma/*
Should Be Enough For Everyone(tm) :)

I've added a snippet to the postinst script, checking whether we're
upgrading from an earlier version and doing the chown/chmod if so.
IMHO, this should cover all cases.

> > * Install the /usr/bin/mailq and /usr/bin/newaliases symlinks.
> > Closes: #558421
> > * Switch to the 3.0 (quilt) source format.
> > * Update the debconf translations:
> > - add German. Closes: #552754
> > - add Japanese. Closes: #554515
> > - remove a double space and unfuzzy the translations. Closes: #552586
> > * Fix a crash when the SMTP server does not support STARTTLS.
> > Closes: #547594
>
> I had a look at 25-unsupported-starttls.patch, which looks good to me,
> however I was not able to test it, so I assume you have tested that
> as well.

Yes, it's really easy to test - just point dma to any mailserver that
does not recognize the STARTTLS command on port 25 :) But, yes, I've
tested it and it seems to work.

> By the way, IMO having so many patches in debian/patches (in fact much more
> than source files;-) looks like you are trying to develop there, nothing
> wrong with that, but it is not the most suitable place for that purpose. For
> instance, 9K 20-parse-recipient.patch is suitable for a new feature branch.
> IMO you either push that harder upstream [1], slow down pushing such feature
> patches with the package or fork the whole thing upstream and form a new
> project. Actually you have already diverged that enough to do the latter.
> IMO, debian/patches should be only for patches specific to Debian, feature
> explosions should be evolved upstream ;-)
>
> [1] though I don't see that rejected at (as written in the patch header):
> http://bugs.dragonflybsd.org/issue1321

Well, I wrote most of those patches because without them, dma either simply
could not replace a local MTA (e.g. the "sendmail -t" mode tha many, many
programs use to send e-mail messages in a really simple way), or did some
really weird things (e.g. the "seen" patch that was later integrated and
without which dma would list the same message several times when listing
the queue with no indication whether it was needed or not). Most of
the patches were accepted upstream, and some (like -t processing) were
not explicitly rejected, but implemented in a different way in later
versions. When I finish integrating a later snapshot of dma in my
local repository, you'll see the next Debian upload with a lot less
non-Debian-specific patches :)

Yes, I know debian/patches is not intended as a development repository,
especially on a project with a very active and responsive upstream, as
dma happens to be. I don't do this with other packages, but this
particular case was special - in order to be an easily-usable MTA, dma
needed a couple of nudges in the right direction, but definitely not
enough to warrant a full-scale fork on my part.

Thanks for taking a look at it and for the comments; and thanks in advance
should you decide to also take a look at the new version :)

G'luck,
Peter

--
Peter Pentchev roam@... roam@... roam@...
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
I am the meaning of this sentence.

attachment0 (851 bytes) Download Attachment

Re: Fuppes: Package Names and the Separation of a Project into Packages

2009-12-19T05:18:22Z

On Sat, Dec 19, 2009 at 11:31:50PM +1100, Robert Massaioli wrote:

> $ ls *.deb -1
> fuppes_0.654-1_i386.deb
> fuppes-core-plugin-presentation_0.654-1_i386.deb
> fuppes-database-plugin-mysql_0.654-1_i386.deb
> fuppes-database-plugin-sqlite3_0.654-1_i386.deb
> fuppes-decoder-plugin-flac_0.654-1_i386.deb
> fuppes-dev_0.654-1_all.deb
> fuppes-encoder-plugin-twolame_0.654-1_i386.deb
> fuppes-metadata-plugin-dlna_0.654-1_i386.deb
> fuppes-metadata-plugin-exiv2_0.654-1_i386.deb
> fuppes-metadata-plugin-libavformat_0.654-1_i386.deb
> fuppes-metadata-plugin-libmp4v2_0.654-1_i386.deb
> fuppes-metadata-plugin-magick_0.654-1_i386.deb
> fuppes-metadata-plugin-taglib_0.654-1_i386.deb
> fuppes-transcode-plugin-ffmpeg_0.654-1_i386.deb
> fuppes-transcode-plugin-magick_0.654-1_i386.deb
> libfuppes0_0.654-1_i386.deb
> $
>
> I look at the sheer number of packages there and think that, although it
> provides alot of freedom as to what you install on your machine, it might be
> too fine grained; maybe we need less packages and every package installs
> more (or even a single package with everything)? But I'm not sure and that
> is why I am asking here.
>
> What should we do in this case? Should I try and get all of those packages
> into debian or should I group them into larger but fewer packages?

Hm I'd first consider the size of each of the plugin packages. If
they're relatively small you could consider grouping them, seems like
that it is already somewhat done in core, database, encoder, metadata,
... if these are not depending on each other it could be a sensible
choice. If they're really small all in one is ok as well.

Regards

Christoph

--
/"\ ASCII Ribbon : GPG-Key ID: 0xD49AE731
\ / Campaign : CaCert Assurer
X against HTML : Debian Maintainer
/ \ in eMails : http://www.debian.org/

http://www.christoph-egger.org/

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Fuppes: Package Names and the Separation of a Project into Packages

2009-12-19T04:31:50Z

Hi mentors,

Recently I have been developing on fuppes and decided to start packaging it; there was an existing but rather dead ITP for fuppes here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=426048
(Before I go on I jsut want to say that I have read the entire debian policy (and a few sections more than once); so while still new I hope I will understand any references to the policy)

Ulrich designed fuppes so that support for extra components would come in the form of plugins; these plugins manifest as .so files that come with the project. As a result, when the original package was written for fuppes, there is a package called 'fuppes' which contains core functionality. And many extra packages which each install a single .so file as a plugin resulting in the following packages:

$ ls *.deb -1
fuppes_0.654-1_i386.deb
fuppes-core-plugin-presentation_0.654-1_i386.deb
fuppes-database-plugin-mysql_0.654-1_i386.deb
fuppes-database-plugin-sqlite3_0.654-1_i386.deb
fuppes-decoder-plugin-flac_0.654-1_i386.deb
fuppes-dev_0.654-1_all.deb
fuppes-encoder-plugin-twolame_0.654-1_i386.deb
fuppes-metadata-plugin-dlna_0.654-1_i386.deb
fuppes-metadata-plugin-exiv2_0.654-1_i386.deb
fuppes-metadata-plugin-libavformat_0.654-1_i386.deb
fuppes-metadata-plugin-libmp4v2_0.654-1_i386.deb
fuppes-metadata-plugin-magick_0.654-1_i386.deb
fuppes-metadata-plugin-taglib_0.654-1_i386.deb
fuppes-transcode-plugin-ffmpeg_0.654-1_i386.deb
fuppes-transcode-plugin-magick_0.654-1_i386.deb
libfuppes0_0.654-1_i386.deb
$

I look at the sheer number of packages there and think that, although it provides alot of freedom as to what you install on your machine, it might be too fine grained; maybe we need less packages and every package installs more (or even a single package with everything)? But I'm not sure and that is why I am asking here.

What should we do in this case? Should I try and get all of those packages into debian or should I group them into larger but fewer packages?

Thanks,
Robert

P.S. It is possible that there is a better way to provide this kind of thing. If so please let me know and I'll look into that instead.

Re: RFS: libqtintf4 (ping)

2009-12-19T04:25:14Z

Hello again!
After some work with upstream, all problems seem to be fixed now.
The project contains a qmake-file, moc-files are generated automatically
and buildscript fails on error.
If upstream publishes the qmake-version of libqt4intf in a tarball with
upstream-version in name I will fix the watch file too.
Sune, could you please check the project if there's something left to do?
The new package was pushed to Debian mentors.
Great thanks!
Matthias Klumpp

P.S: Now building the project takes over 12 minutes. You can fetch a coffee
while it compiles.

On Sat, 19 Dec 2009 11:09:40 +0000 (UTC), Sune Vuorela <nospam@...>
wrote:

> On 2009-12-18, Matthias Klumpp <matthias@...> wrote:
>> The package is lintian-clean. There were some concerns about the
>> build-script, but because it's a really small lib there should be no
>> problem in building this.
>
> The way it is built, it takes around 1G of memory to build. This *needs*
> to be fixed. it might be a small lib, but the way it is built is just
> plain wrong. Especially since this can be easily fixed.
>
>
> The moc output files *must* be regenerated on build, else you end up
> with issues like:
>
> In file included from qtpas.cpp:370:
> lib/hooks//qwebsettings.cpp_mk:14:2: error: #error "This file was
> generated using the moc from 4.5.2. It"
> lib/hooks//qwebsettings.cpp_mk:15:2: error: #error "cannot be used with
> the include files from this version of Qt."
> lib/hooks//qwebsettings.cpp_mk:16:2: error: #error "(The moc has changed
> too much.)"
>
> from next Qt upload.
>
>
> and the build script *needs* to be fixed so that it actually fails when
> build fails.
>
> dpatch apply-all
> applying patch 01_buildscript.patch to ./ ... ok.
> bash /tmp/libqtintf4-1.72Qt4.5.2/compile_lib.sh
> Please Modify location of Qt4 in this script
> touch build-stamp
> fakeroot debian/rules binary
> dh_testdir
> dh_testroot
> dh_clean -k
> dh_installdirs
> dh_install
> dh_install: libqt4intf5 missing files (libqt4intf.so.*), aborting
>
> /Sune

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: RFS: libqtintf4 (ping)

2009-12-19T04:24:22Z

Hello again!
After some work with upstream, all problems seem to be fixed now.
The project contains a qmake-file, moc-files are generated automatically
and buildscript fails on error.
If upstream publishes the qmake-version of libqt4intf in a tarball with
upstream-version in name I will fix the watch file too.
Sune, could you please check the project if there's something left to do?
Great thanks!
Matthias Klumpp

P.S: Now building the project takes over 12 minutes. You can fetch a coffee
while it compiles.

On Sat, 19 Dec 2009 11:09:40 +0000 (UTC), Sune Vuorela <nospam@...>
wrote:

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Fwd: RFS: qodem

2009-12-19T03:10:45Z

On Fri, Dec 18, 2009 at 07:32:07PM -0600, Kevin Lamonte wrote:
> I think this is fixed now. Should I resubmit the RFS again?

Yes, I suggest you include some details of what the package does and how it
would be useful in Debian, to increase your chances of attracting a
sponsor.

> I made that change and rebuilt, 'dpkg -I" shows the right short description,
> but dupload says the files are already there. Is there something else I
> need to do?

Run dupload with the force flag, -f. See the man page for further details.

--
Jonathan Wiltshire

1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: RFS: libqtintf4 (ping)

2009-12-19T03:09:40Z

On 2009-12-18, Matthias Klumpp <matthias@...> wrote:
> The package is lintian-clean. There were some concerns about the
> build-script, but because it's a really small lib there should be no
> problem in building this.

The way it is built, it takes around 1G of memory to build. This *needs*
to be fixed. it might be a small lib, but the way it is built is just
plain wrong. Especially since this can be easily fixed.

The moc output files *must* be regenerated on build, else you end up
with issues like:

In file included from qtpas.cpp:370:
lib/hooks//qwebsettings.cpp_mk:14:2: error: #error "This file was
generated using the moc from 4.5.2. It"
lib/hooks//qwebsettings.cpp_mk:15:2: error: #error "cannot be used with
the include files from this version of Qt."
lib/hooks//qwebsettings.cpp_mk:16:2: error: #error "(The moc has changed
too much.)"

from next Qt upload.

and the build script *needs* to be fixed so that it actually fails when
build fails.

dpatch apply-all
applying patch 01_buildscript.patch to ./ ... ok.
bash /tmp/libqtintf4-1.72Qt4.5.2/compile_lib.sh
Please Modify location of Qt4 in this script
touch build-stamp
fakeroot debian/rules binary
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs
dh_install
dh_install: libqt4intf5 missing files (libqt4intf.so.*), aborting

/Sune

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

automake and intermediate files generated by yacc, lex, valac

2009-12-18T19:11:33Z

Hi,

there are several tools that generate C source code that is later
complied in object code, e.g. yacc, lex or valac. automake defaults to
distribute these built intermediate files, so they are usually not
regenerated during a build.

This causes several problems:

1. The intermediate files might be generated by out-dated versions of
the tools, thus not benefiting from bug fixes in the tools. This seems
similar to the problem of including copies of libraries.

2. When patching the real source, it might be required to update
build-dependencies etc. to get the package to build again. This makes
stable updates more complicated.

3. The software is not build from the "real" source, but from
intermediate files. For me, this is similar to shipping pre-compiled
binaries (not the same, but similar at least).

So I would like to know

1. What is Debian's policy about this,

1. How to stop automake from including intermediate files,

2. How to make sure the intermediate files are regenerated during the
build.

Regards,
Ansgar

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Fwd: RFS: qodem

2009-12-18T17:32:07Z

(Sorry, I meant to send to the mailing list...)

On Fri, Dec 18, 2009 at 5:59 PM, Jonathan Wiltshire <debian@...> wrote:

On Fri, Dec 18, 2009 at 05:19:29PM -0600, Kevin Lamonte wrote:
> Dear mentors,
>
> I am looking for a sponsor for my package "qodem".
>
> * Package name : qodem
> Version : 0.2.0-1
> Upstream Author : Kevin Lamonte <kevin.lamonte@...>
> * URL : http://qodem.sourceforge.net
> * License : GPLv2+
> Section : comm

(IANADD)

I'm not sure how you've done it, but you have a package version of 0.2.0-1
with no upstream .orig.tar.{gz,bz2} so it's a native package, which is
incorrect [1]. Further feedback is pointless until it's fixed so please
re-submit your RFS then.

I think this is fixed now. Should I resubmit the RFS again?

(a minor niggle, but with my debian-l10n-english hat on, please make your
short description read in "is-a" form, i.e. without the leading capital.)

1: http://people.debian.org/~mpalmer/debian-mentors_FAQ.html#packaging

I made that change and rebuilt, 'dpkg -I" shows the right short description, but dupload says the files are already there. Is there something else I need to do?

Re: RFS: qodem

2009-12-18T15:59:02Z

On Fri, Dec 18, 2009 at 05:19:29PM -0600, Kevin Lamonte wrote:

> Dear mentors,
>
> I am looking for a sponsor for my package "qodem".
>
> * Package name : qodem
> Version : 0.2.0-1
> Upstream Author : Kevin Lamonte <kevin.lamonte@...>
> * URL : http://qodem.sourceforge.net
> * License : GPLv2+
> Section : comm

(IANADD)

I'm not sure how you've done it, but you have a package version of 0.2.0-1
with no upstream .orig.tar.{gz,bz2} so it's a native package, which is
incorrect [1]. Further feedback is pointless until it's fixed so please
re-submit your RFS then.

(a minor niggle, but with my debian-l10n-english hat on, please make your
short description read in "is-a" form, i.e. without the leading capital.)

1: http://people.debian.org/~mpalmer/debian-mentors_FAQ.html#packaging

--
Jonathan Wiltshire

1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

RFS: qodem

2009-12-18T15:19:29Z

Dear mentors,

I am looking for a sponsor for my package "qodem".

* Package name    : qodem
  Version         : 0.2.0-1
  Upstream Author : Kevin Lamonte <kevin.lamonte@...>

* URL             : http://qodem.sourceforge.net
* License         : GPLv2+
  Section         : comm

It builds these binary packages:
qodem      - Friendly ncurses-based Unicode-aware communications package


The upload would fix these bugs: 560902

My motivation for maintaining this package is: I am the author of qodem and hope Debian users will find it useful.

The package can be found on mentors.debian.net:

- URL: http://mentors.debian.net/debian/pool/main/q/qodem
- Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free

- dget http://mentors.debian.net/debian/pool/main/q/qodem/qodem_0.2.0-1.dsc

I would be glad if someone uploaded this package for me.