Re: RFS (resent): libdumbnet

[Jan C. Nordholz]

Hi Paul,

I've uploaded a new package which should address your packaging concerns.[1]
I find a symbols file a bit overkill for a library which is not going to
be developed any further in the forseeable future, but I've added one
anyway. - You've pointed out a few things I might discuss with upstream,
and I certainly will when I have the time.

A few direct responses to your remarks:

> You seem to have radically altered the install procedures, why not
> install to debian/tmp in the install target and use dh_install like
> the current version does instead of manually moving stuff around?

I think this one is just personal preference. (I've chosen to do four
mv calls instead of adding three more .install files and am mostly
moving whole directories.) The 1.8 package version even used dh_movefiles. ;)

> There are several lintian complaints:

Lintian (even with -IE --pedantic) is now down to

] P: libdumbnet1: no-upstream-changelog
] P: python-dumbnet: no-upstream-changelog

which I can't remedy myself.

> Who is he...@pool.math.tu-berlin.de?

Me, as at least the changelog and the key I'm signing these mails with
should show. I don't like the whole debian-list volume hitting my univer-
sity address, so I'm writing these mails from a different account.

> [/usr/share/doc/{packages}]

I'm sharing the doc directory between the lib and the dev package, and as
the difference in files I'd like to install in those directories is so
small I'm not inclined to change that.

> Likewise, the package descriptions should reflect the audiences.
> libdumbnet-dev/python-dumbnet probably needs a fair bit of information
> but libdumbnet1 will probably always be automatically installed so
> needs vastly less information.

How could I convey less information? Only include the single sentence
"libdumbnet provides [...] networking routines."? That wouldn't satisfy
me as a user at all. The items give me an idea of what that library
actually does and why another package might need it - I don't want to
remove them.
I've changed the short description to make the packages distinguishable.

> A single autoreconf call can replace the
> aclocal/autoheader/autoconf/automake calls (but not the libtoolize one
> IIRC).

If I'm forced to rerun the autotools in order to keep the diff/patchset small,
I'd rather list explicitly what I'm calling and which parameters I use.

PS: I've activated the test suite, but it has its limitations and might
not be of as much use as you might have intended. (Another thing upstream
should take care of, at least partially.)


Regards,

Jan

[1]: http://www-pool.math.tu-berlin.de/~hesso/deb/libdumbnet_1.12-1.dsc


signature.asc
Description: Digital signature

Re: Dash and dot in package version

[Boyd Stephen Smith Jr.]

In <7337540c0905160100g59c1a3dem9f7622da6ca42...@mail.gmail.com>, Ludovico 
Cavedon wrote:
>I think I'll go for
>2.2~rc3+hg365+dfsg1

Just, IMO:
I prefer 2.2~rc3+hg365~dfsg1 so that 2.2~rc3+hg365 would be greater than it.  
In this way, it would allow distribution of the same upstream without 
repacking for Debian by a non-Debian (or simply unofficial) group.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/



signature.asc
Description: This is a digitally signed message part.

Re: RFC: Proposal for template for uploads

[Matthew Palmer]

On Sun, May 17, 2009 at 10:33:07AM +0100, Neil Williams wrote:
> On Sat, 16 May 2009 21:50:10 -0300
> Rogério Brito  wrote:
> 
> > Dear mentors,
> > 
> > I am looking for a sponsor for my package "foo".
> 
> [Include one of:]
> >
>  problems.>
> .>
> 
> [or some other description of the kind of upload required]

And when you're listing bug numbers, please put a summary of what the bug
is.  Make it *easy* for the sponsor to say "yes", rather than "meh, too
busy, might look at it later".

- Matt


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: scrotwm - dynamic tiling window manager

[Andrea Bolognani]

On Mon, 20 Apr 2009 10:48:12 +0200
Andrea Bolognani  wrote:

> Dear mentors,
> 
> I am looking for a sponsor for my package "scrotwm".
> 
> * Package name: scrotwm
>   Version : 0.9.2
>   Upstream Author : Marco Peereeboom 
> * URL : http://www.peereeboom.us/scrotwm/html/scrotwm.html
> * License : ISC, MIT
>   Programming Lang: C
>   Description : dynamic tiling window manager
>   Section : x11
> 
> It builds these binary packages:
> scrotwm - dynamic tiling window manager
> 
> The package appears to be lintian clean.
> 
> The upload would fix these bugs: 514322
> 
> I would be glad if someone uploaded this package for me.


Since sending this RFS, I've made some improvements to the packaging.

The packaging repository has been made available under the collab-maint
umbrella[1], and the package itself has been uploaded to mentors[2].

I'm still looking for a sponsor.


[1] http://bzr.debian.org/bzr/collab-maint/scrotwm/trunk
[2] http://mentors.debian.net/debian/pool/main/s/scrotwm/scrotwm_0.9.2-1.dsc
-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


pgphek9aFEzxD.pgp
Description: PGP signature

Re: RFS: udav

[Salvatore Bonaccorso]

Hi all 

On Mon, May 11, 2009 at 03:26:59PM +0200, Salvatore Bonaccorso wrote:
> I asked Alexey if that would be possible. I hope the point's can be
> solved by using icons known to be in the public domain. So I have to
> wait for his reply on this.

Short note, Alexey had now most of the icons repladed, there we search
only for three further ones: export, import and transparency. 

The other point to explain how icons from mathgl scripts are generated
is also in progress.

Bests
Salvatore


signature.asc
Description: Digital signature

Re: Bug 510765 won't appear as closed

[Don Armstrong]

On Fri, 15 May 2009, Adeodato Simó wrote:
> + Don Armstrong (Thu, 14 May 2009 13:24:29 -0700):
> > a message to control with 'close ' (deprecated, because it doesn't
> > tell the submitter that it was fixed, [...])
 
> Well, AFAIK they do get a mail that the bug has been closed, with
> subject "acknowledged by developer" and a generic blurb about the
> closure.

Yeah, my sentence should read "tell the submitter *why* it was fixed".


Don Armstrong

-- 
No amount of force can control a free man, a man whose mind is free
[...] You can't conquer a free man; the most you can do is kill him.
 -- Robert Heinlein _Revolt in 2010_ p54

http://www.donarmstrong.com  http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Problems pdebuilding a quilt-based package

[Benjamin Mesing]

Hello,

> >  fakeroot debian/rules clean
> > # do not abort if quilt pop fails (this is usually if there no 
> > patches applied
> > quilt pop -a || true
> > No patch removed
> > quilt push 10_addBuildInfrastructure
> > No patches in series
> 
> You probably have a .quiltrc that sets non-default options
> (e.g. QUILT_PATCHES=debian/patches).  The .quiltrc is not available in
> the pbuilder environment, thus the build fails.

Thanks a lot, that was indeed the reason.

Best regards 

Ben



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Problems pdebuilding a quilt-based package

[Ansgar Burchardt]

Hi,

Benjamin Mesing  writes:

>  fakeroot debian/rules clean
> # do not abort if quilt pop fails (this is usually if there no 
> patches applied
> quilt pop -a || true
> No patch removed
> quilt push 10_addBuildInfrastructure
> No patches in series

You probably have a .quiltrc that sets non-default options
(e.g. QUILT_PATCHES=debian/patches).  The .quiltrc is not available in
the pbuilder environment, thus the build fails.

The quilt makefile /usr/share/quilt/quilt.make uses the `--quiltrc
/dev/null' option and sets QUILT_PATCHES by hand for this reason.

Regards,
Ansgar


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Problems pdebuilding a quilt-based package

[Benjamin Mesing]

Hello,

I have a package which builds just fine when running debuild. It also
works fine, taking the source files created by debuild run "dpkg-soruce
-x" and then debuild in the resulting directory. However, I am unable to
pdebuild the package from the same directory where debuild works
perfectly. Pdebuild fails to apply the quilt patches(see below).

I have no idea what is causing this. I am including the significant
parts of the debuild output as well as the pdebuild output.

Here comes the pdebuild output:
[Setup of the build system using cowbuilder snipped]
Setting up fakeroot (1.12.2) ...
I: Copying back the cached apt archive contents
I: Copying source file
I: copying [/umlet/umlet_9.1-1.dsc]
I: copying [/umlet/umlet_9.1.orig.tar.gz]
I: copying [/umlet/umlet_9.1-1.diff.gz]
I: Extracting source
dpkg-source: warning: extracting unsigned source package 
(umlet_9.1-1.dsc)
dpkg-source: extracting umlet in umlet-9.1
dpkg-source: info: unpacking umlet_9.1.orig.tar.gz
dpkg-source: info: applying umlet_9.1-1.diff.gz
I: Building the package
dpkg-buildpackage: set CFLAGS to default value: -g -O2
dpkg-buildpackage: set CPPFLAGS to default value:
dpkg-buildpackage: set LDFLAGS to default value:
dpkg-buildpackage: set FFLAGS to default value: -g -O2
dpkg-buildpackage: set CXXFLAGS to default value: -g -O2
dpkg-buildpackage: source package umlet
dpkg-buildpackage: source version 9.1-1
dpkg-buildpackage: source changed by Benjamin Mesing 
dpkg-buildpackage: host architecture amd64
 fakeroot debian/rules clean
# do not abort if quilt pop fails (this is usually if there no patches 
applied
quilt pop -a || true
No patch removed
quilt push 10_addBuildInfrastructure
No patches in series
make: *** [clean-patched] Error 1
dpkg-buildpackage: failure: fakeroot debian/rules clean gave error exit 
status 2
E: Failed autobuilding of package
I: unmounting dev/pts filesystem
I: unmounting proc filesystem
 -> Cleaning COW directory
  forking: rm -rf /var/cache/pbuilder/build//cow.7782

Here comes the debuild output:
 dpkg-buildpackage -rfakeroot -D -us -uc
dpkg-buildpackage: set CFLAGS to default value: -g -O2
dpkg-buildpackage: set CPPFLAGS to default value: 
dpkg-buildpackage: set LDFLAGS to default value:  
dpkg-buildpackage: set FFLAGS to default value: -g -O2
dpkg-buildpackage: set CXXFLAGS to default value: -g -O2
dpkg-buildpackage: source package umlet 
dpkg-buildpackage: source version 9.1-1 
dpkg-buildpackage: source changed by Benjamin Mesing 
dpkg-buildpackage: host architecture amd64 
 fakeroot debian/rules clean   
# do not abort if quilt pop fails (this is usually if there no patches 
applied
quilt pop -a || true
  
No patch removed
  
quilt push 10_addBuildInfrastructure
  
Applying patch 10_addBuildInfrastructure.diff   
  
patching file Makefile  
  

Now at patch 10_addBuildInfrastructure.diff
rm -f build-stamp  
/usr/bin/make clean
make[1]: Entering directory `/home/ben/debian/umlet/umlet-9.1'
rm -f umlet.jar   
rm -f epsgraphics.jar 
rm -rf bin
rm -rf epsgraphics/bin
make[1]: Leaving directory `/home/ben/debian/umlet/umlet-9.1' 
dh_clean  
quilt pop -a  
Removing patch 10_addBuildInfrastructure.diff 
Removing Makefile 

No patches applied
QUILT_PATCHES=debian/patches quilt --quiltrc /dev/null pop -a -R || 
test $? = 2 
No patch removed

rm -rf .pc debian/stamp-patched 

 dpkg-source -b umlet-9.1   

dpkg-source: info: using source format `1.0'

dpkg-source: info: building umlet using existing umlet_9.1.orig.tar.gz  

Re: How to create quilt-based source packages using debuild

[Benjamin Mesing]

> Start with the unpatched upstream source.
> Copy the debian dir in including debian/patches/.
> echo "3.0 (quilt)" >debian/source/format
> remove patch system from debian/rules if present
> debuild

Thanks for the pointer. However, since the archive does not support
Format 3.0 (quilt) yet, I will stick to format 1.0 for now.

Best regards 

Ben



-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC: Proposal for template for uploads

[Piotr Ożarowski]

[Neil Williams, 2009-05-17]
> RFS: QA: 
> RFS: NEW: 
> RFS: RC: 

I like this. I'd add , though (see below)

> RFS: UPDATE: 

I ask my sponsorees to add a version in Subject field as well, this way
I know if it's new upstream release or an update (so UPDATE tag is not
needed) and I can distinguish different sponsorship requests (I remove
the whole thread from my Debian/RFS mailbox once all problems are
resolved and package is uploaded, sometimes package is uploaded without
minor changes I asked for so old thread remains in the mailbox)
-- 
http://people.debian.org/~piotr/sponsor


signature.asc
Description: Digital signature

Re: RFC: Proposal for template for uploads

[Neil Williams]

On Sat, 16 May 2009 21:50:10 -0300
Rogério Brito  wrote:

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

[Include one of:]
>
 problems.>
.>

[or some other description of the kind of upload required]

Alternatively (or possibly additionally), some reliable method of
encoding this at the start of the subject line:

RFS: QA: 
RFS: NEW: 
RFS: RC: 
RFS: UPDATE: 

(as long as NEW is tied to packages that need an ITP, not just those
that will go through the NEW processing queue due to a SONAME bump or a
new binary package.)

> ---
> 
> Its summary is:
> 
> * Package name: 
>   Version : 
>   Debian Revision : 
>   Upstream Author : >
> * URL : 
> * License : 
>   Language: 
>   Section : 
>   Long description:
>   
> 
> ---
> 
> It builds this/these binary package/s:
> foo-binary01 - short description 01
> foo-binary02 - short description 02
> foo-binary03 - short description 03
> ...
> foo-binaryn  - short description n
> 
> ---
> 
> The latest entry in the Debian changelog is:
>  

v.good idea.
 
> ---
> 
> As required, I tested the package against unstable's version of lintian
> and it (is|is not) lintian clean.
> 
>  

That's a lot better than the current template.
 
> ---
> 
> The package can be found at :
> - URL:
>   http://example.com/debian/pool/main/f/foo
> - Source repository:
>   deb-src http://example.com/debian unstable main contrib non-free
> - dget line:
>   dget http://example.com/debian/pool/main/f/foo/foo_version-revision.dsc
> 
> ---
> 
> I would be glad if someone uploaded this package for me.
> 
> Kind regards,
>  Joe Doe Maintainer


-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgp8jA9Lgxr85.pgp
Description: PGP signature

I have created a Canadian English dictionary package

[Daniel Dickinson]

I have created a package that during the build processes uses the
hunspell-tools munch utility to generate the dictionary file and on
install install the required files for the dictionary as per dictionary
policy.  I am, however, not a Debian Developer and the package has a
strict build depends on wcanadian-huge (because when the word list
changes so should the dictionary, and the dictionary shouldn't change
within the same dictionary version number, which is what will happen if
the wordlist changes).

Is there an OOo or other developer willing to look at/maintain this
package?

I am not currently subscribed to the list, but will do so if it is
deemed useful for me to do so by those who are interested.  Otherwise
please CC me.  

Note, I am subscribed to the CC'ed debian-mentors list,
but would like to be CCed anyway. I'd prefer if a DD would take
ownership of this package since otherwise each change of wcanadian-huge
will require a hunt for sponsorship.

Note also that I am interested in opinions on the wisdom of this
approach.  It is a 'pure' free software approach since the final
product is built from the source, but munch takes several hours on my
P4 2 GHz, which is a lot of processing just to build a dictionary.
Would it be acceptable to Debian to occasionally build the dictionary
even though the dictionary is technically not the 'preferred form for
modification' (though it could be modified from there if so desired)?

Regards,

Daniel

-- 
And that's my crabbing done for the day.  Got it out of the way early, 
now I have the rest of the afternoon to sniff fragrant tea-roses or 
strangle cute bunnies or something.   -- Michael Devore
GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C  http://gnupg.org
The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com


signature.asc
Description: PGP signature

Re: include desktop file and icon

[Chris Bannister]

[Please don't top-post. Instead, remove quoted material that you're
not replying to, and reply inline to the points you're responding to.]

On Tue, May 12, 2009 at 11:08:29AM +0200, Grammostola Rosea wrote:
> I hope this doesn't seem harsh ;) But in my experience, it works the  
> best at start to ask experienced people and learn bit by bit how things  
> work. At first the manpages are mostly 'acadabra' but picking up some  
> bits from others will help you to be able to quickly understand the more  
> sophisticated issues. In my experience, when people tell me how to do it  
> and I succeeded once, I don't have to ask it again how it works (like  
> the install file thing). After a while I see other people do things  
> different and then I can ask and investigate why...

No. Think this way: "investigate why and only if you then have trouble
ask." 

-- 
Chris.
==
I contend that we are both atheists. I just believe in one fewer god
than you do. When you understand why you dismiss all the other
possible gods, you will understand why I dismiss yours.
   -- Stephen F Roberts


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org