Re: RFS: gnome-shell-extensions

[Leo 'costela7; Antunes]

On 06/11/11 12:34, Josselin Mouette wrote:
> Since there is no extension manager in 3.0, I think we should start this
> package from gnome-shell 3.2 (currently sitting in experimental). This
> way there would be no need for this hair-splitting
> one-extension-per-package which only makes things more complicated.

I imagine you probably heard this question a thousand times already, but
do you have a rough time-frame for 3.2 entering unstable?
If it's still months away, I'd suggest uploading it as-is now, because
IMHO its usefulness outweighs the slight annoyance of having to manually
disable the unwanted extensions after installing (and I imagine we're
only talking about sid/testing here, as the released version will
probably be ">= 3.2").


> Let’s just select a default set of extensions useful to enable by
> default (at least alternative-status-menu) and this should be much
> better.

User-theme might also be a good candidate, since it's unintrusive and
gnome-tweak-tool already expects to find it.


Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4eb682ce.7040...@debian.org

Re: RFS: gnome-shell-extensions

[Leo 'costela7; Antunes]

[taking the liberty of adding reply-to:mentors, to avoid further
cross-posting, but inform gnome-devels of intention to review/sponsor]

Hi,

On 01/11/11 10:24, Victor Seva wrote:
> I am looking for a sponsor for gnome-shell-extensions. The source is
> accessible at [0] and the binaries on [1]. As you can see on [2] I
> already have been helping maintaining other packages.
> The idea is to integrate the package in the gnome vcs if you think it
> deserves to be included in Debian.

The package seems good, but I have a couple of structural comments:
  - is there a reason for not packaging the schema files in the
respective extension-packages?
  - since all bin-packages already depend on -common, why not link
/usr/share/doc/g-s-e-* → /usr/share/doc/g-s-e-common? This saves a bit
of duplication.

And a couple of very minor notes:
  - how about changing the binary names to *-extension-* instead of
*-extensionS-* ?
  - are you actually using the REV/VER variables in debian/rules? Since
REV parses for bzr, I'd guess this is left-over from a copy-paste?
  - you check for bz2 in the watch file, but used a gz for your first
package (obviously not an error, just a minor inconsistency)


If no pkg-gnome maintainer objects, I could upload it in the coming week.


Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4eb58b4e.2050...@debian.org

Re: RFS: vnstat -- console-based network traffic monitor

[Leo "costela" Antunes]

On 13/08/11 15:03, Michael Rasmussen wrote:
> But vnstat is already present:

But it's maintained by the QA team, so maybe an adoption would be in order?


Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/j25uav$car$1...@dough.gmane.org

Re: Nitpicking: you are doing it wrong

[Leo "costela" Antunes]

 with dh_* almost 10 years ago. You can simply copy one
of the example dh-make rules files and semi-blindly hack away at it
until it compiles and generates a lintian-clean package. You don't
automatically gain more knowledge about the system simply because you
copied a template with more code in it.
But by the time the package compiled, you hopefully learned a bit about
how these tools work and fit together, because fixing build-bugs is the
best way to stimulate learning. And this can be said for *both* ways of
using debhelper - or any other helper, for that matter.
Bottom line is: unless you're writing your rules file completely by hand
(which would be very inefective - to say the least - for all but the
most pathological cases) you're always relying on something you probably
don't understand completely and making rules files more explicit, while
still using wrappers and helpers, has no direct effect on this. It only
makes for more text to parse.



Cheers


-- 
Leo "costela" Antunes
[insert a witty retort here]


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/iv9oln$1k5$1...@dough.gmane.org

Re: Nitpicking: you are doing it wrong

[Leo "costela" Antunes]

On 08/07/11 22:23, Thomas Goirand wrote:
> On 07/08/2011 08:47 PM, Scott Howard wrote:
>> Right now, the general consensus is the dh and cdbs produce
>> debian packages that are easier to maintain in the long run (if the
>> sponsor has to take over maintenance of the package or if NMUs are
>> required in the future.)
> I really would like you to explain WHERE you saw such a consensus.
> When it goes down to myself, I would *not* sponsor a package that
> is using either dh or CDBS, because I like to be in the control and see
> what's going on. I believe that CDBS/dh is hiding what's necessary to
> do a good packaging, and is calling too many unnecessary helpers,
> which slows down the build process. Also, with dh_override_*, if you
> have a lot of them, it soon becomes unreadable. That's only my opinion
> though, but I suspect that I might not be the only one to think this way.
> In anyways, I don't see at all a consensus here!!!

Seeing what's going on is important for learning and for debugging.
Thankfully debugging with dh is pretty mature, should you happen to need
it (don't really know about cdbs), but having to read a non-dh-using
rules file to understand exactly what happens when and why can be a lot
of work and shouldn't be imposed on your fellow DDs if you don't have a
good reason for it (curiosity and a micro-management tendency are not
good reasons; funky non-standard build-systems are)

Please use dh/cdbs/whatever other means necessary to make your packaging
work easy to read and understand. Don't make the packaging more complex
for other people just because you want to "know what's going on". That
sounds awfully like NIH[0].
You never know who might have to NMU it, make QA uploads, etc and even
you yourself might find it pretty hard to remember why you did something
in this particular fashion, when it actually could just as well be done
in a more common way.
Not using these tools goes against your own advice here[1]: you're
making the life of other developers who have to look at your code harder
for no reason.
Or to put it more succinctly in your own words: "otherwise, you have no
rules at all and it's a mess".

And your performance argument seems like a dud unless you can provide
some evidence that you actually save a significant amount of time by not
using dh/cdbs/whatever during package builds (and by significant I mean
more than just a couple of seconds per build).



Cheers

[0] http://en.wikipedia.org/wiki/Not_Invented_Here
[1] http://lists.debian.org/msgid-search/4e176b0d.8060...@debian.org


-- 
Leo "costela" Antunes
[insert a witty retort here]


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/iv7thn$faq$1...@dough.gmane.org

Re: Joining Debian

[Leo "costela" Antunes]

Paul Wise wrote:
> Changing the URL for that FAQ needs:
> 
> Matthew to be willing to edit and maintain the new URL. Some people do
> not like using Debian's wiki, not sure if Matthew feels that way.

I understand not liking wiki markup, but for a text document with just
simple bullet lists, links and headers, I'd consider it a minor problem
out-weighted by the advantage of easier collective management.

> A redirect from Matthew's version to the wiki version.

That would be nice. I'd consider it a sort of "blessing" from him. :)

> Update the lists.d.o page.
>
> Update the IRC channel topic.
> 
> Search the website for the old link and update all the links.

I'd consider doing these after the wiki version gathers at least a bit
of support. My point was just taking a bit of the responsibility off of
Mathew's back, but if that doesn't happen, the point is moot.


Cheers


-- 
Leo "costela" Antunes
[insert a witty retort here]


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/hlju3r$j1...@ger.gmane.org

Re: Joining Debian

[Leo 'costela7; Antunes]

[CC'ing Mathew just in case he stopped reading this thread; sorry for
the possibly duplicate email]

Paul Wise wrote:
> I just realised that what you have just done violates the license of
> Matthew's document. Please read the copyright / license section of it
> at the very end.

Mathew had answered saying I was free to do so, I just hadn't realized
his reply was private and not on-list. I interpreted this answer as
permission, but perhaps an explicit (and public) one would be better.


Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b7d6692.2060...@debian.org

Re: Joining Debian

[Leo "costela" Antunes]

Leo "costela" Antunes wrote:
> Matthew Palmer wrote:
>> In addition, the FAQ for this list:
>> http://people.debian.org/~mpalmer/debian-mentors_FAQ.html might answer some
>> of your questions.
> 
> As a side note, wouldn't the wiki be the perfect place for this?
> Don't get me wrong, I totally appreciate the work. It just seems like a
> bit of a waste of potential help, having it in a different place.

Putting my money where my mouth is: done.
http://wiki.debian.org/DebianMentorsFaq

Thanks again for putting it all together! I hope the footer suffices as
an expression of that gratitude! :)

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


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

Re: Joining Debian

[Leo "costela" Antunes]

Matthew Palmer wrote:
> In addition, the FAQ for this list:
> http://people.debian.org/~mpalmer/debian-mentors_FAQ.html might answer some
> of your questions.

As a side note, wouldn't the wiki be the perfect place for this?
Don't get me wrong, I totally appreciate the work. It just seems like a
bit of a waste of potential help, having it in a different place.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


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

Re: RFS: numptyphysics

[Leo "costela" Antunes]

Gabriele Giacone wrote:
> Man page is only a bad copy of the homepage.
> Regarding segfaults, yesterday evidently I've only chosen the right
> moment you were waiting for ;), but given that you already spent a lot
> of time and I didn't take it into account and given that I think I
> couldn't be useful anymore, please repackage it on your own and take
> ITPs back. This would also speed up release process.

No, c'mon, you also worked on it! I don't wanna be the whinny one here! ;)
Plus, you're eventually gonna go through to becoming a DM and eventually
a DD, right? So you need the practice!
I just wanna have a hand in it. Practically just a psychological thing! :)

If you still wanna maintain it, incorporate the mentioned fixes and I'll
upload it!


Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


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

Re: RFS: numptyphysics

[Leo "costela" Antunes]

Paul Wise wrote:
>> I don't think I'm seeing the issue here. Care to elaborate a bit more?
>> Isn't that the whole idea behind patching and running autoreconf in the
>> first place? If we wanted the changed files produced by autoreconf in
>> the debian.tar.gz we wouldn't need to run it, right? What am I missing?
> 
> If you don't remove the files on clean, then after autoreconf they
> will be different from the ones in the orig.tar.gz. If you build the
> package multiple times, then dpkg-source (with format v3) will add a
> patch to debian/patches containing the diff of those files, for
> dpkg-source 1.0, the diff will be added to the diff.gz. The patches
> are ugly and a waste of space if you're running autoreconf before
> ./configure anyway.

Oh, damn, right, absolutely! You mean the other way around. Should have
thought of that... :)
Still, probably wouldn't cause build issues, but it sure is ugly!


Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


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

Re: RFS: numptyphysics

[Leo "costela" Antunes]

Paul Wise wrote:
> I personally think Debian should remove menu and replace it with
> upstreamed patches for FreeDesktop menu support.

Agreed in the long run, but since there are AFAIK (haven't checked in a
while) still some window-managers/desktop-environments that don't fully
support desktop files, it's just a minor hassle.

>> - [subjective] I don't believe the debian/clean files are really
>> necessary. (though it probably doesn't hurt either)
> 
> That prevents the diff to those files after autoreconf from ending up
> in the debian.tar.gz.

I don't think I'm seeing the issue here. Care to elaborate a bit more?
Isn't that the whole idea behind patching and running autoreconf in the
first place? If we wanted the changed files produced by autoreconf in
the debian.tar.gz we wouldn't need to run it, right? What am I missing?



Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


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

Re: RFS: numptyphysics

[Leo 'costela7; Antunes]

Gabriele Giacone wrote:
> Leo "costela" Antunes wrote:
>> Was 0.3 already released somewhere? I can find no traces of it either on
>> the homepage, the maemo.org project page or SVN.
> 
> No and yes. There are no 0.3 binary releases but I found this [1]: 7
> weeks ago, 0.3.0.3 became 0.3.0.7. We could change 0.3 in 0.3.0.7 or we
> could follow a svnrevision-based versioning; I packaged the latest
> revision which is 148 so something like 0.2+svn148-1.
> Personally, I'd prefer the first one, 0.3.0.7.

I'd suggest using the SVN-based versioning, either 0.2+svn148 or
0.3~svn148. It may not look as good (highly subjective), but it keeps a
clean reference to upstream. In the long run, having a package versioned
0.3.0.7 in the archive and no upstream 0.3.0.7 release would make
digging through the repository to backport patches, for instance, a bit
harder than necessary.

Not to mention it might be confusing to users.

Paul Wise's suggestion to poke upstream into releasing 0.3 is also worth
a try, though I didn't get any response from my pings a few months back.

>> I'll take a look at it ASAP and get back to you.
> Thanks.

Some remarks:

- A licensecheck run tells me debian/copyright is missing some details,
if you intend to follow DEP-5:
- data/femkeklaver.ttf: it's AFAICT freeware and taken from here[0]
- zoomer.cpp has no copyright statement, but seems to be heavily
based on this[1] (could warrant another upstream poke)
- happyhttp.{cpp,h} uses the zlib/libpng licence and is copyright
2006 Ben Campbell
- all other files seem to be GPL-3+, not just GPL-3

- [subjective] You don't seem to be shipping a menu entry.

- Your patch 00Makefile.am isn't enough to keep it from compiling with
and linking against the shipped version of Box2D:
$ objdump -x /usr/games/numptyphysics | grep -i box2d
$

And the build log confirms this. I have attached my version of the
patch, which I used for my ITP. AFAICT it solves this issue without
side-effects.

- [subjective] I don't believe the debian/clean files are really
necessary. (though it probably doesn't hurt either)

- [subjective] The dh_auto_configure override in debian/rules could
probably call dh_auto_configure instead of ./configure manually. Makes
it slightly more forward-compatible.

- [subjective] A watchfile would be nice. I also attached the one I was
working on for the original ITP. Not so thoroughly tested, but seems to
work.


Aside from these remarks, the package seems OK, the manpage is a nice
touch, and I can't seem to replicate the segfaults I was having when I
attempted my ITP.
I'd still suggest co-maintaining it though, just cause I also devoted a
few hours to it myself, both packaging and playing! ;)


Cheers

[0] http://www.1001fonts.com/font_details.html?font_id=3180
[1] http://syllable.q52.eu/software/ruwen/SDL_rotozoom-1.6/SDL_rotozoom.c

-- 
Leo "costela" Antunes
[insert a witty retort here]
Index: numptyphysics-svn/Makefile.am
===
--- numptyphysics-svn.orig/Makefile.am	2009-12-30 20:31:51.0 +0100
+++ numptyphysics-svn/Makefile.am	2009-12-30 20:32:28.0 +0100
@@ -1,6 +1,4 @@
 bin_PROGRAMS = numptyphysics
-noinst_LIBRARIES = libbox2d.a
-INCLUDES = -IBox2D/Include
 
 numptyphysicsdir = $(datadir)/numptyphysics
 
@@ -34,8 +32,8 @@
 	OsFreeDesktop.cpp \
 	OsWin32.cpp
 
-numptyphysics_CPPFLAGS = -IXX $(SDL_CFLAGS) $(HILDON_CFLAGS)
-numptyphysics_LDADD = libbox2d.a $(SDL_LIBS) $(HILDON_LIBS)
+numptyphysics_CPPFLAGS = -IXX $(SDL_CFLAGS) $(HILDON_CFLAGS) $(BOX2D_CFLAGS)
+numptyphysics_LDADD = $(SDL_LIBS) $(HILDON_LIBS) $(BOX2D_LIBS)
 
 numptyphysics_DATA = \
 	data/C00_Title.npz \
@@ -58,36 +56,3 @@
 	data/femkeklaver.ttf
 
 
-libbox2d_a_SOURCES = \
-	Box2D/Source/Collision/b2Distance.cpp \
-	Box2D/Source/Collision/b2TimeOfImpact.cpp \
-	Box2D/Source/Collision/b2CollideCircle.cpp \
-	Box2D/Source/Collision/b2CollidePoly.cpp \
-	Box2D/Source/Collision/Shapes/b2PolygonShape.cpp \
-	Box2D/Source/Collision/Shapes/b2CircleShape.cpp \
-	Box2D/Source/Collision/Shapes/b2Shape.cpp \
-	Box2D/Source/Collision/b2PairManager.cpp \
-	Box2D/Source/Collision/b2Collision.cpp \
-	Box2D/Source/Collision/b2BroadPhase.cpp \
-	Box2D/Source/Dynamics/b2WorldCallbacks.cpp \
-	Box2D/Source/Dynamics/Joints/b2PrismaticJoint.cpp \
-	Box2D/Source/Dynamics/Joints/b2MouseJoint.cpp \
-	Box2D/Source/Dynamics/Joints/b2GearJoint.cpp \
-	Box2D/Source/Dynamics/Joints/b2Joint.cpp \
-	Box2D/Source/Dynamics/Joints/b2PulleyJoint.cpp \
-	Box2D/Source/Dynamics/Joints/b2DistanceJoint.cpp \
-	Box2D/Source/Dynamics/Joints/b2RevoluteJoint.cpp \
-	Box2D/Source/Dynamics/Contacts/b2CircleContact.cpp \
-	Box2D/Source/Dynamics/Contacts/b2PolyAndCircleContact.cpp \
-	Box2D/Source/Dynamics/Contacts/b2Contact.cpp \
-	Box2D/Source/Dynamics/Contacts/b2PolyContact.cpp \
-	Box2D/Source/D

Re: RFS: numptyphysics

[Leo "costela" Antunes]

Hi Gabriele

Gabriele Giacone wrote:
> I am looking for a sponsor for my package "numptyphysics".

As mentioned in the ITP[0], I'd gladly co-maintain/sponsor/whatever
numptyphysics.

> * Package name: numptyphysics
>   Version : 0.3-1

Was 0.3 already released somewhere? I can find no traces of it either on
the homepage, the maemo.org project page or SVN.

>   Upstream Author : Tim Edmonds 
> * URL : http://numptyphysics.garage.maemo.org/
> * License : GPL-3
>   Section : games

(...)

> http://mentors.debian.net/debian/pool/main/n/numptyphysics/numptyphysics_0.3-1.dsc
> 
> I would be glad if someone reviewed and uploaded this package for me.

I'll take a look at it ASAP and get back to you.

Cheers

[0] http://bugs.debian.org/496586

-- 
Leo "costela" Antunes
[insert a witty retort here]


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

Re: Building pdf from odt files noninteractively?

[Leo "costela" Antunes]

Felipe Sateler wrote:
> On Fri, 2009-10-16 at 17:31 -0300, Felipe Sateler wrote:
>> I have a source package that has pdf documentation, which is generated
>> with openoffice.org. Is it possible to generate said pdf without user
>> interacion (that is, for autobuilding in the buildds)? Or maybe I can
>> just ship the also-included pdf files? AFAICS, the license is not
>> violated.
> 
> The license is GPL, I forgot to add.
> 
> 

As long as you're shipping the ODTs in the source you should be OK. The
PDFs don't need to be generated at build time: they're arch-indep and
could be generated just as well before each new release.

Cheers
-- 
Leo "costela" Antunes
[insert a witty retort here]


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

Re: RFS: homebank

[Leo "costela" Antunes]

Charles Plessy wrote:
> from a 10 seconds scan on its changelog, the package also apperars to be well
> maintained since 2007. How about applying for upload rights on that package?

+1

>From what I've seen from sponsoring (and partly co-maintaining) one of
his other packages (blueproximity) I'd gladly advocate his DM status,
should he want to apply for it.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


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

Re: orig tarball in conflict with debian policy

[Leo "costela" Antunes]

Michael Rasmussen wrote:
> The tarball was named foo-0.7.2.tgz which I have renamed to
> foo-0.7.2.tar.gz (actually tar.bz2 since I prefer bzip2)

Then what's exactly the problem? Why not rename it to
"foo_0.7.2.orig.tar.bz2" and be done with it?

Note that if upstream uses gzip, it would be nice sticking to it, since
the repacking isn't necessary.

Slightly OT, you could take a look at the comparisons John Goerzen made
about compression mechanisms[0][1]. They might swing your preference for
bzip2.

> The source package does not postfix the source folder with version
> number which will cause lintian to complain.
> 
> Orig:
>   foo\
>  subdir1
>  subdir2
> 
> My suggestion:
>   foo-x.y.z\
>  subdir1
>  subdir2

As Mark Brown said, AFAICT this really doesn't make any practical
difference. If there is a problem with it, then I've unknowingly been
making this mistake for years... :)

Cheers

[0]http://changelog.complete.org/archives/910-how-to-think-about-compression
[1]http://changelog.complete.org/archives/931-how-to-think-about-compression-part-2


-- 
Leo "costela" Antunes
[insert a witty retort here]


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

Re: orig tarball in conflict with debian policy

[Leo "costela" Antunes]

Michael Rasmussen wrote:
> example:
> orig tarball: foo-y.y.z.tgz
> internal structure: foo\...

I may be jumping to conclusions here, but you mean the name of the
archive is against policy because it's not in the
"foo_x.y.z.orig.tar.gz" format?

Renaming it to the right format is perfectly in order in this case and
the name of the base source directory doesn't really matter much.

Or did I misunderstand your question?

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


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

Re: RFS: gnocky

[Leo "costela" Antunes]

Hi

Matthias Mailänder wrote:
> The package appears to be lintian clean.

Taking a look at the package:
W: gnocky source: out-of-date-standards-version 3.6.2 (current is 3.7.3)
W: gnocky: binary-without-manpage usr/bin/gnocky
W: gnocky: package-contains-empty-directory usr/share/applications/
W: gnocky: package-contains-empty-directory usr/sbin/
W: gnocky: copyright-lists-upstream-authors-with-dh_make-boilerplate
W: gnocky: copyright-contains-dh_make-todo-boilerplate
E: gnocky: menu-icon-not-in-xpm-format phone
W: gnocky: menu-item-uses-apps-section /usr/share/menu/gnocky:5
W: gnocky: menu-item-creates-new-section Apps/Net /usr/share/menu/gnocky:5
W: gnocky: description-starts-with-leading-spaces
W: gnocky: syntax-error-in-debian-changelog line 12 "couldn't parse date
Di, 01 Apr 2008 09:26:51 +0200"


And this last warning actually stops it from building in pbuilder.
Please make sure you're building your package in Unstable/Sid and that
you have the latest version of lintian to check it with.
When you've gone through these problems, let me know and I'll take
another look.

As a last hint: perhaps you could expand the long description to be a
bit more informative about what the program can do.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: RFS: blueproximity

[Leo "costela" Antunes]

Francesco Namuri wrote:
> Hi Leo,
> thanks for the interest... :)

Thanks for the quick action! :)

> Why not, in this moment, I'm very busy so the help is very appreciated,
> I've added you to uploaders...

Thanks!

Package uploaded. You should receive the usual emails shortly.

Just a small cosmetic change you might want to talk to the Bluetooth
team about: putting you on the Uploaders field and the
pkg-bluetooth-mainteiners on the Maintainer field, in keeping with what
the guys there are already using, and since it makes little practical
difference. I didn't want to intrude into anything you guys might have
already talked about, but it seemed like a nice step to integrate it
with the team.


Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: RFS: blueproximity

[Leo "costela" Antunes]

Hey Francesco,

Francesco Namuri wrote:
>   Package name: blueproximity
>   Version : 1.2.5-1
>   Upstream Author : Lars Friedrichs <[EMAIL PROTECTED]>
>   URL : http://blueproximity.sourceforge.net/
>   License : GPL
>   Section : admin
> 
> It builds these binary packages:
> blueproximity - locks/unlocks your desktop tracking a bluetooth device

I'm taking a look at the package now and it seems OK, but what do you
think about adding an autostart script (/etc/xdg/autostart/*) before
uploading ?

BTW, I find this package really interesting, if you ever need a
co-maint, let me know! :-)

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: Help with watch file -- pre-release upstream versions

[Leo "costela" Antunes]

Hi,

Székelyi Szabolcs wrote:
> What's the usual way of handling "preX" upstream version numbers in
> watch files? I'm having trouble because uscan considers 1.0pre3 newer
> than 1.0.

Perhaps mangling the upstream version to use the tilde ("~") as a
separator? But I don't really know if uscan even recognizes it...

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: RFS: dblatex (updated package): 2nd try

[Leo "costela" Antunes]

Andreas Hoenen wrote:
> I rememer a thread on this mailing list starting with [1] that discussed
> the issue of reusing the same version number for different uploads to
> mentors.debian.net.  Most participants agreed to use a new version
> number for each upload.  I like this approach, as m.d.n. is public, thus
> somehow the upload to m.d.n already is a form of distribution.  And it
> gets quite confusing if there exist different distributions with the
> same version number.

Totally agreed. I was just too dumb to see the obvious and practical
option '-v', as pointed out by others! :-)

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: RFS: yougrabber

[Leo "costela" Antunes]

[EMAIL PROTECTED] wrote:

>> People could think that this will be some kind of 
>> gtk/qt/whatever, but the screenshot shows an ncurses 
>> application.
>>
> 
> In my point of view, ncurse applications are graphic applications, moreover
> the "technically speaking" paragraph gives clear detail ("ncurses-based")
> about that. 

I don't mean to nitpick, but I don't think this is a point of view
issue. The term "graphic interface" in computer related subjects is
relatively well defined as being related to icons and widgets. A console
based interface such as ncurses - complex as it may be - is still based
on just characters.

Regardless of the semantical uncertainties, "graphic interface" should
not be used to describe this program specifically because it muddles the
relatively clear distinction between what is classically (in the linux
world) called a "graphical interface" and what's not. Your point of view
is not as important as the common denominator's point of view (no
offense), in our case: the end users.
My suggestion - if you feel so strongly about using the term - would be
something like "console-based graphical interface", alluding to ncurses
intention of being the closest you can get to "graphical", without
leaving the console. But IMHO you'd still be better off leaving the gray
area and making it clear that it's a console application, without having
to read the technical fine print to figure it out (it sounds like cheap
advertising: "it's graphical! ... but technically, it's not" ;-) ).


Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: RFS: Mupen64 -- Nintendo 64 emulator and plugins

[Leo "costela" Antunes]

Ryan Schultz wrote:
> * License : GPL

> DFSG repackaging removes a plugin with ambiguous licensing.

It seems there's still an awful lot of files without explicit
licenses[0]. Can you get upstream to take a look and perhaps rectify this?

Also, the whole upstream build-system seems completely misused.

I didn't go very deep into the package (the build system scared me :-)
), but here are some remarks:

- You could bump to debhelper >= 5 (both build-deps and compat file)

- Even though the build-system is a mess, perhaps patching the config.h
instead of copying over it would be better?

- The whole arch-dependent logic for passing arguments to MAKE could be
avoided, specially since they're practically the same for all arches.
Use the schemes provided in the reference and policy to handle
'-O2 -Wall -g'. Probably just adding '-DX86' in case of i386 and
'-DCOMPARE_CORE -D_BIG_ENDIAN' in all other cases could be better then
setting the whole option line in one go. (anyway, are these options
really necessary?)

- Changelog.DFSG shouldn't be in the source root, instead it should be
moved to somewhere like debian/README.debian or debian/README.Debian-source.

- The DFSG tarball should only have the offending files removed, the
other changes mentioned in Changelog.DFSG should be handled via patching
on build-time (via dpatch, quilt, etc).


Hope it helps.

Cheers

[0] since many files have a non-standard copyright header, I found them
via a dirty 'licensecheck -r ./ | grep UNKNOWN | cut -d: -f1 | while
read file; do grep -L "General Public Licence" $file; done'

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: RFS: dblatex (updated package): 2nd try

[Leo "costela" Antunes]

Felipe Sateler wrote:
> This can be triggered with the -v option to dpkg-buildpackage

Live and learn. Never noticed that one before! :-)

Uploading.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: RFS: dblatex (updated package): 2nd try

[Leo "costela" Antunes]

Andreas Hoenen wrote:

> I have just uploaded dblatex 0.2.8-2 to mentors.debian.net [1].
> Regarding the new lintian warning 'spelling-error-in-changelog' I have
> opened a bug report [2].
> 
> [1] dget 
> http://mentors.debian.net/debian/pool/main/d/dblatex/dblatex_0.2.8-2.dsc

Now there's just one last minor problem: since you closed some bugs on
0.2.8-1 which never got uploaded, you would have to close them manually
as the automatic bug handling wouldn't be triggered for them.

I don't know if there's anything on mentors.d.o that stops you from
doing this, but I'd personally say you don't need to bump versions
before the package actually gets into the archive, so you could just
stick with '-1' for a Debian version, so merging the changelog entries
should do the trick.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: RFS: dblatex (updated package): 2nd try

[Leo "costela" Antunes]

Andreas Hoenen wrote:

> what shall I say for advertisement?  I think dblatex is not an
> unimportant package, AFAIK it's the only free, working DocBook->PDF tool
> in Debian.  Moreover, the current Debian version (0.2.6-1) is quite
> outdated as sadly 0.2.7-1 did not get sponsored.  Thus I would really
> appreciate if someone could sponsor the new version.

I am fairly inexperienced with docbook and python policy, but here are a
few remarks that I hope make sense:

- the package adds a Makefile on '/usr/share/dblatex/tests/mathml/'
- I'm not sure the lintian override for the changelog line length is
necessary; you could just mention "bug # on the sourceforge tracker".
Using the override could mask a future line length issue, and even
though this is certainly something minor, I personally don't think it's
worth it.
- the wrapper in /usr/bin seems strange, isn't there a better way to
implement this? The way I see it, it makes the script in
/usr/share/dblatex a bit redundant.
- perhaps you could remove the sourceforge site link from the
description? It's linked from the homepage.

Overall, I'd say doing a quick check with debc, aside from lintian is
always a good idea, but the package seems good.

After you take a look at these issues (or just justify them) I can
sponsor you, if no one with more expertise in this sort of package pops
up until - let's say - monday.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: Packages getting created without signature

[Leo "costela" Antunes]

iluvlinux wrote:
[snip]
> ie  $ dpkg-buildpackage -rfakeroot -k -sgpg
[snip]

Complementing what Bart said: '-k' and '-sgpg' are also not needed.
The '-k' is mostly only needed for sponsoring uploads. After a quick
read of the thread, it seems you intend on maintaining this package
yourself.
The '-sgpg' switch is also not necessary in this context. Read
dpkg-buildpackage's manpage to understand why.

> So is there any way that i can automate this stuff. ie the dpkg-buildpkg
> should not ask for passphrase every time i build a new package, it should
> take it from a file or some ENV variable.

This would be VERY unsafe.
You have to understand the basics of cryptography and - more importantly
- the REASON for cryptography in Debian to see that you have to keep
your GPG key very safe and that includes not storing your passphrase in
any easily accessible place.
This definition of "easily" is very debated, but certainly a config file
or an ENV variable don't pass any test.
Most people agree that your passphrase shouldn't be stored at all, if
possible, and instead you should just backup your key and your
revocation certificate in safe, offline places, in case of emergency.

Do some research on the topic. Wikipedia is your friend (even if it's
not always particularly right about everything). It might ease your life
if you intend on becoming a Debian Maintainer or Developer.

Cheers and good luck with the package!

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: rpath issue on 64 bit architectures

[Leo "costela" Antunes]

Russ Allbery wrote:

> lintian.debian.org only checks i386.

Oh, now that makes sense!
Guess the obvious sometimes slips by unnoticed :-)

But anyway, I have an amd64 server and a package with the same problem
which chrpath solved, so my argument stands.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: rpath issue on 64 bit architectures

[Leo "costela" Antunes]

Anibal Avelar wrote:

> I will recheck it, but I don't have an AMD machine to confirm again
> :(. I Just received this from my package's sponsor that he has a AMD
> machine.

Which of your packages has this problem? I have an amd64 machine and
could do some testing for you, if you want.

> Yes, I don't want to rebuild the configure script with autoconf. I
> know the aclocal.m4 would be unecessary if I rebuild the configure
> script. But I don't want to do that :P

I think you got it the other way around.
You don't need to patch aclocal.m4, in case you're NOT rebuilding the
configure script.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: rpath issue on 64 bit architectures

[Leo "costela" Antunes]

Anibal Avelar wrote:
> On 12/5/07, Leo costela Antunes <[EMAIL PROTECTED]> wrote:
>> 
>> - And, of course, using 'chrpath' on debian/rules
>
> No, it doesn't work for AMD. I tried to use chrpath directly to
> binaries files, but it didn't work.

Are you sure? Check out package 'transmission', it's been using chrpath
for the last 3 releases (IIRC) without issues on any arch (at least
according to lintian.debian.org).
If it's being used correctly and for some reason doesn't work, please
file a bug to it (as of now it has no bugs whatsoever, giving me the
impression that it must work flawlessly).

> I had to do the option for a patch on aclocal.m4 and configure scripts
> with dpatch on build-time.
>
> On aclocal4 and configure the changes are (for each occurrence):
> -  hardcode_into_libs=yes
> +  hardcode_into_libs=no
>
> -hardcode_into_libs=$hardcode_into_libs
> +hardcode_into_libs=no

I haven't looked into your case, but unless I'm mistaken you shouldn't
need to patch aclocal.m4 if you're already patching the configure
script. You should either patch aclocal.m4 in case the configure script
will be re-generated on build-time (which is unlikely your case) or
patch the configure script directly. Or am I missing something?

BTW, it certainly seems easier to patch this option instead of patching
the '${wl}--rpath' definition, thanks for the tip!

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: rpath issue on 64 bit architectures

[Leo "costela" Antunes]

Leo "costela" Antunes wrote:
> 
> The way I see it the options for dealing with RPATH are:
> 

- And, of course, using 'chrpath' on debian/rules

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: rpath issue on 64 bit architectures

[Leo "costela" Antunes]

Russ Allbery wrote:
> Francesco Namuri <[EMAIL PROTECTED]> writes:
>> Il giorno 04/dic/07, alle ore 01:23, Russ Allbery ha scritto:
> 
>>> The problem is that libtool doesn't think that lib64 is on the regular
>>> library search path and hence decides that it needs to add rpath, which
>>> is broken at several different levels but best avoided by just using
>>> lib.
> 
>> at this point, the only way is to patch libtool after the creation...
>> is it a better solution respect at the use of chrpath?
> 
> I guess what I don't understand is that I don't think we're seeing this
> with everything in the archive, and lots of other packages also use
> libtool.  Are we seeing this behavior everywhere, or is there something
> different about your package than others?

With sid's Sources.bz2:
cat Sources | grep -E 'Build-Depends:.*(?<=,|\s)chrpath'

This shows 116 packages, so perhaps many of them have similar reasons to
use chrpath, while admittedly many may also have non libtool based
build-systems.

Another example is the transmission package, which I sponsor and
co-maintain. I haven't looked as deeply into it, but it shares the same
lack of --disable-rpath option.

> It may be that upgrading the version of libtool used by the package to the
> current Debian unstable version would fix it, for instance.

It seems to already be the newest version available: aclocal.m4 was
created with aclocal 1.10, so the macros are up-to-date and they set
--rpath in many places.

The way I see it the options for dealing with RPATH are:

- Ask upstream to remove the hardcoded --rpath, either by manually
stripping it from aclocal.m4 or by relibtoolizing with a modified
libtool (since it has the hardcoded rpath set inside its source)

- Suggest the use of the AC_RELOCATABLE macro, which seems to be used by
many projects in their build systems, but I can't find a canonical
source for it.

- Patch the aclocal.m4/confirure.{ac,in} and re-run autoconf on build-time

- Patch the configure script on build-time

Any other ideas?
I'll probably update the wiki[0] with these suggestions and give it a
little cleanup, while I'm at it! :-)

Cheers

[0] http://wiki.debian.org/RpathIssue
-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: New package "unicornscan" , I GIVE UP !

[Leo "costela" Antunes]

Hans-J. Ullrich wrote:
>> If you don't want to be the maintainer for the package, and instead only
>> want to have it packaged, you can file a RFP (request for package) bug
>> to the package 'wnpp'.
>> Simply using 'reportbug wnpp' and filling in the proper fields should be
>> enough. It should guide you through.
>>
> 
> I do not understand, how it works. The docu mentioned this, too, but there 
> was 
> no backjground about the process or policy to find. 

If you're running a Debian system (and you should, since you want to
work with it), you can just type 'man reportbug' to see how it works (it
should be installed by default).
Also take a look at http://bugs.debian.org to acquaint yourself with the
Bug Tracking System (BTS).

> Yes, I know. And I am also knowing, that my little work is not important for 
> Debian. But I think: If everyone is doing a little bit work for Debian, as 
> litle as it might be, the whole work together will bring the Debian idea 
> further on. My little part is more in user teaching and supporting in my home 
> area, and not coding. Now I wanted to enter a new task. O.k., I failed.

I didn't mean to say that your work is of no importance. Every help
counts! And you can only say you "failed" if you really give up on a two
hour period.

> Yes, I gave up. I had the feeling, no one was interested in new packages at 
> all, so I gave up. And yes, I had no fun and the package worked on my 
> system

Again: you probably got your feeling wrong.
Take a look at http://lists.debian.org, check the lists archives for
debian-mentors and see how new people usually get involved. 2 hours is a
very short period to base your expectations on.

> Thanks, I will remember that. Again: I AM willing to read, but I need help in 
> the beginning, too. 

I understand, that's why we pointed you to some documentation that has
been done specifically to help beginners.

> O.k., I will try a new effort, but when it fails again, I will send you the 
> whole stuff. Thanky for this ! 

That doesn't sound very optimistic.
But even if you do "fail" (by your standards) there's no need to send me
the packages. I can get them from the original website.

Cheers and good luck

-- 
Leo "costela" Antunes
[insert a witty retort here]


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

Re: New package "unicornscan" , I GIVE UP !

[Leo "costela" Antunes]

Hans-J. Ullrich wrote:
> I suppose, this is all to difficult and complicated for me. As the package is 
> new, I get MD5-errors and more. So, as this process is too difficult for me, 
> and is taking to much of long time, I give up.

Sorry to hear that.

> Sorry, I am not willing to collect all the different docs and reaqd, this is 
> boring and for one package it is too much of a thing.

Unfortunately, if you want to maintain a package for Debian, that means
you have to be responsible for their state in Debian, understanding how
the packaging process works and so on. So yes, that takes some reading.
Remember that Debian is a big group of people. We need some sort of
organization to be able to work together effectively, so it may take a
bit of learning in order to successfully interact with this community,
even if you just want to get a simple piece of software inside it.

If you don't want to be the maintainer for the package, and instead only
want to have it packaged, you can file a RFP (request for package) bug
to the package 'wnpp'.
Simply using 'reportbug wnpp' and filling in the proper fields should be
enough. It should guide you through.

> Anyway, if someone likes to have a look at the package, I will sent him as an 
> email, if not, no problem: It is running on my computer. 
> 
> I was just intend to take part in the community, but it seem not to work.

Again, taking a part in the community takes a bit of learning.
There are many people that want to take part in it and all of them have
questions like you. Many of these questions have already been answered
somewhere, so instead of taking our time to answer personally to each
and every question (time that could be spent improving the quality of
Debian, and which I'm ironically losing myself) we simply direct people
to places where they can find the answers themselves and in the process
they show that they are willing to make an effort to contribute to the
community by learning.

> And please: Do not write me, "read here", "read there", "read somewhere!", 
> really, for some few questions, I am not willing to read hours lots of stuff.

If you are not willing to make this effort, it seems you're not willing
to be a part of the community, but perhaps I understand you wrong: if
you're just frustrated because you can't find the answer to your
question where people pointed you to, or because people seem to have
misunderstood your question, please don't hesitate to ask again. But be
patient. We're all volunteers, your questions can take some time to be
answered. You gave up in less then 2 hours, from what I see in your emails.

Remember: your "some few questions" may seem straightforward to you, but
the answers may not be and if they've already been answered somewhere
else, what would be the difference between answering them in a personal
email to you, or reading them in a different place? Just the work of the
person writing you an answer (in this case: me).


At any rate, if you're not interested in making an effort with this
package, I might take it over and package it myself. It seems
interesting, but I'll need to take a better look before committing to it.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


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

Re: rpath issue on 64 bit architectures

[Leo "costela" Antunes]

Francesco Namuri wrote:
> I would like to know, what in your opinion is the best solution.
> And then, I am mistaken thinking that the problem is related to the fact
> that lib64/ is a symlink to lib/ ?

I'm I don't think this is exactly the problem.
RPATH is meant to help/supplant the linker on runtime, to make sure it
finds the correct library which carries the symbols needed by the
executable. There should be no need for it in a system where the linker
is correctly configured and all installed libraries are in predictable
places, such as Debian, but in a system where libraries could possibly
be installed in different places, this becomes useful.

With that in mind, what I interpret from the given reason is that
libtool could be trying to deal with a possibly mixed 32/64
installation, where it wouldn't trust the linker to find the correct
library. This isn't needed for Debian.

At any rate, this is just speculation.
What you could suggest upstream is that - if he really believes rpath to
still be useful and doesn't want to completely abandon it as other gnome
projects have done - he could implement something like the widely used
AC_RELOCATABLE macro to his scripts, to make a '--disable-rpath' option
available at configure time. This in turn could be added to debian/rules
and the chrpath hack could be removed.

Hope it helps.

Also, something I hadn't seen while sponsoring the package: it seems
that you accidentally copied the rules file to a file named '\' on the
base source code dir.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: RFS: gnome-phone-manager

[Leo "costela" Antunes]

Paul Wise wrote:
> Obviously that is a hack/workaround for upstream's buggy build system,
> be sure to send a patch upstream that fixes it.

Yup, agreed.
This shouldn't be too hard since upstream is (was?) a DD (hadess).

The package has been uploaded with the workaround for now.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: RFS: gnome-phone-manager

[Leo "costela" Antunes]

Francesco Namuri wrote:
> Maybe the rpath issue is not i386 related?

Yeah, possibly.

> How to implement it using cdbs? adding a common-install-arch rule?
> Somethink like:
>
> common-install-arch::
>   chrpath --delete debian/gnome-phone-manager/usr/bin/gnome-phone-manager
>

Precisely, this did the trick. Just add 'chrpath' to the build-deps too.
Update it in the SVN and I'll upload it.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: RFS: gnome-phone-manager

[Leo "costela" Antunes]

Francesco Namuri wrote:
> I've added it to svn, but I get the same warnings...

>> Also, lintian is complaining about a RPATH set to /usr/lib. I didn't
>> delve into it, but this seems like a real error.
>> Does it have a good reason to do it, that I failed to see?
> 
> About this, I've no idea I check all packages with lintian after the
> build, I don't get any warning or info, I run lintian with -I -i
> always... :\

I've just done a second build inside pbuilder, with a clean orig
downloaded from upstream and the RPATH issue still shows up. Are you
using pbuilder? Are you sure your orig is not tampered in any way?
Which arch are you building on?

Taking a fast look inside the configure script, it seems to set RPATH in
many different cases, including the default when the build arch can't be
determined. In this case I would use chrpath to clean it after the build
and advise upstream to cleanup the configure script.

What do you think?

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: RFS: gnome-phone-manager

[Leo "costela" Antunes]

Francesco Namuri wrote:

> I've fixed all... :)

The package is hitting the new dpkg issue[0] with libusb-0.1-4. I
successfully dodged the issue adding

DEB_DH_SHLIBDEPS_ARGS_ALL := -u'--ignore-missing-info'

to debian/rules, but I don't want to upload without your blessing on the
change.

Also, lintian is complaining about a RPATH set to /usr/lib. I didn't
delve into it, but this seems like a real error.
Does it have a good reason to do it, that I failed to see?

Let me know so I can update the package accordingly and upload it.

Cheers

[0] http://lists.debian.org/debian-devel/2007/11/msg00722.html

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: RFS: gnome-phone-manager

[Leo "costela" Antunes]

Mike O'Connor wrote:
 > src/gconf-bridge.* and most of the files in the telepathy directory
> have copyright holders not mentioned in debian/copyright.

Francesco, will you take a look at these, before I sponsor the package?

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: RFS: gnome-phone-manager

[Leo "costela" Antunes]

Francesco Namuri wrote:

> I'm looking for a temporary sponsor for gnome-phone-manager 0.40-3,

Still need this? Can I check it out from svn.d.o, or do you have any
uncommited changes somewhere?

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]



signature.asc
Description: OpenPGP digital signature

Re: RFS: gaim-hotkeys

[Leo \"Costela\" Antunes]

Hi,

I know it's been some time, but do you still need a hand with this?
Sounds like an interesting package.

Cheers
On Qua, 2004-10-13 at 18:17 +0800, Ivan Wong wrote:


Hi,

I think the package maintainer of Gaim is too busy for it. Is there anyone
give me a hand with this?
Any help would be appreciated.

Files: http://www.ivanwong.info/gaim-hotkeys/

Cheers,
Ivan.
GPG: 1024D/4A9A664A 2004-10-04








-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 "you must cut down the mightiest tree in the forest... with... a herring!"








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

Re: RFS: x-no-session-manager - restore default X behavior with gnome/kde installed

[Leo \"Costela\" Antunes]

Hi

On Qui, 2005-02-03 at 13:54 +0100, Goswin von Brederlow wrote:

> The advantage of having this as package is that
> 
> 'update-alternatives --config x-session-manager'
> 
> will show you 3 options now: gnome, kde and none. Having to tweak the
> alternative manually to something non executable but existing requires
> insight knowledege into the alternatives system and xfree86-common
> that a normal user wouldn't have. Installing the package is simple,
> effective and can be done in automatic installations, e.g. via FAI.

I see your point and I agree, but I don't think this should be put in a
separate package. Sounds very kludgy.
The "none" option could be included with X itself, this way you'd be
able to use the alternatives system without the need for a hack and the
setting would persist.

This could be a wishlist bug for X.

Cheers

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: RFS: gaim-encryption -- encryption plugin for gaim

[Leo \"Costela\" Antunes]

[no need to CC me, I'm subscribed to d-mentors]

On Seg, 2004-10-18 at 11:01, Chris Vanden Berghe wrote:
> Hi Leo,
Hi

> I decided to make my own gaim-encryption package, since:
Your motives are perfect. I agree with all of them.

> You're right about the gaim headers: it would be much nicer to have a
> gaim-dev package (that's why I also wrote to the gaim maintainers). 
> But, since it is not there and it won't be there in the near future
> we're better off being pragmatic and transition to the ideal solution
> when it's possible.  Perfection is nice, but I rather prefer to have a
> pragmatic but working solution than none.
That's where we differ. IMO a kludgy solution belongs in a personal
repository, not in the official one.

> In response to your three points:
> 1) only when the gaim plugin APIs change (and they should be backwards
> compatible throughout the 1.x.y versions), so that is not such a big
> problem

True, hopefully.

> So, no, it is not a Debian-only patch.  It is a solution to the
> incorrect assumption the nobody would compile gaim with --disable-nss. 
> This is now in the default upstream release.

This is good.

> Btw, I would have contacted you if I knew you were serious about adding
> your package to the main repository...  I certainly did not try to
> package it behind your back, I did make an ITP and talked about it with
> the gaim maintainers and the upstream developer.  None of them told me
> about your efforts.

That's OK, I just got a little upset, but nothing personal.
Furthermore, my upseting shouldn't get in the way of us doing Debian
work.

> So, in short: I still think gaim-encryption is a very useful package to
> have in Debian, and no I don't think my package is a 'hacky' one.  Sorry
> about the bad communication, though, that was my fault... I should have
> looked harder for a possible ITP bug.

The usefulness is not questioned, but I still think it's not ideal and
it doesn't pass my personal[1] threshold for entry into the archive.
I am trying to recompile Gaim and create a dev package, if I succeed
I'll poke Robert McQueen about uploading it, if he agreed. 
That should solve all our problems (in an ideal world, as you pointed
out).

Cheers

[1] To stress it out: that's my opinion, anyone can still sponsor you.

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: RFS: gaim-encryption -- encryption plugin for gaim

[Leo \"Costela\" Antunes]

[no need to CC me, I'm subscribed to d-mentors]

On Seg, 2004-10-18 at 11:01, Chris Vanden Berghe wrote:
> Hi Leo,
Hi

> I decided to make my own gaim-encryption package, since:
Your motives are perfect. I agree with all of them.

> You're right about the gaim headers: it would be much nicer to have a
> gaim-dev package (that's why I also wrote to the gaim maintainers). 
> But, since it is not there and it won't be there in the near future
> we're better off being pragmatic and transition to the ideal solution
> when it's possible.  Perfection is nice, but I rather prefer to have a
> pragmatic but working solution than none.
That's where we differ. IMO a kludgy solution belongs in a personal
repository, not in the official one.

> In response to your three points:
> 1) only when the gaim plugin APIs change (and they should be backwards
> compatible throughout the 1.x.y versions), so that is not such a big
> problem

True, hopefully.

> So, no, it is not a Debian-only patch.  It is a solution to the
> incorrect assumption the nobody would compile gaim with --disable-nss. 
> This is now in the default upstream release.

This is good.

> Btw, I would have contacted you if I knew you were serious about adding
> your package to the main repository...  I certainly did not try to
> package it behind your back, I did make an ITP and talked about it with
> the gaim maintainers and the upstream developer.  None of them told me
> about your efforts.

That's OK, I just got a little upset, but nothing personal.
Furthermore, my upseting shouldn't get in the way of us doing Debian
work.

> So, in short: I still think gaim-encryption is a very useful package to
> have in Debian, and no I don't think my package is a 'hacky' one.  Sorry
> about the bad communication, though, that was my fault... I should have
> looked harder for a possible ITP bug.

The usefulness is not questioned, but I still think it's not ideal and
it doesn't pass my personal[1] threshold for entry into the archive.
I am trying to recompile Gaim and create a dev package, if I succeed
I'll poke Robert McQueen about uploading it, if he agreed. 
That should solve all our problems (in an ideal world, as you pointed
out).

Cheers

[1] To stress it out: that's my opinion, anyone can still sponsor you.

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: RFS: gaim-encryption -- encryption plugin for gaim

[Leo \"Costela\" Antunes]

Hi

On Seg, 2004-10-18 at 05:06, Chris Vanden Berghe wrote:
> I've been in contact with the gaim developers who seem to be reluctant
> to add a gaim-dev package in the near future (they are considering an
> experimental package, though).  Therefore, I think it is better to go
> ahead and just ship a copy of the gaim headers until the gaim-dev is
> available.  Btw, the original ITP is more than one year old...

Shipping Gaim's headers with gaim-encryption's source is a bad idea,
IMHO, for three reasons:
1:You'll have to sync it with Gaim for every new version and you'll have
non-working plugins in the meantime between gaim's upload and your
upload
2:Gaim's headers don't belong in gaim-encryption, they belong in gaim.
3:Your source will be different from upstream (at least if I understand
you correctly)

My ITP is more then one year old because I believe any other solution
that's been suggested this far to be a kludge.

> I've also been in contact with the upstream author who, at my request,
> has altered his plugin especially for Debian.  The Debian gaim package
> is namely compiled with --disable-nss.  Thanks to this change, this
> version of the plugin can be used without altering the gaim package
> (before it could only be shipped as gaim+gaim-encryption, now it's a
> real plugin).

What change was this, exactly? Did he port the whole NSS+NSPR code from
Gaim to gaim-encryption?
Has this change been applied to the normally distributed source or is it
a debian-hack-only?

> I think people would really like a gaim-encryption plugin package in the
> main Debian repository...

Yes, I can assume that by the number of emails I get about it, but that
doesn't justify including a hacky package, IMHO.

I'm sorry if I sound rude, but I've been packaging gaim-encryption for a
while now and would find it polite to be informed about such plans.
(Yes, I have all that fatherly crap about packages I work on)
From what I've  understood, I don't particularly like your plan, but
you're free to try to convince me, prove me wrong, or just ignore me and
upload it anyway.

Cheers
-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: RFS: gaim-encryption -- encryption plugin for gaim

[Leo \"Costela\" Antunes]

Hi

On Seg, 2004-10-18 at 05:06, Chris Vanden Berghe wrote:
> I've been in contact with the gaim developers who seem to be reluctant
> to add a gaim-dev package in the near future (they are considering an
> experimental package, though).  Therefore, I think it is better to go
> ahead and just ship a copy of the gaim headers until the gaim-dev is
> available.  Btw, the original ITP is more than one year old...

Shipping Gaim's headers with gaim-encryption's source is a bad idea,
IMHO, for three reasons:
1:You'll have to sync it with Gaim for every new version and you'll have
non-working plugins in the meantime between gaim's upload and your
upload
2:Gaim's headers don't belong in gaim-encryption, they belong in gaim.
3:Your source will be different from upstream (at least if I understand
you correctly)

My ITP is more then one year old because I believe any other solution
that's been suggested this far to be a kludge.

> I've also been in contact with the upstream author who, at my request,
> has altered his plugin especially for Debian.  The Debian gaim package
> is namely compiled with --disable-nss.  Thanks to this change, this
> version of the plugin can be used without altering the gaim package
> (before it could only be shipped as gaim+gaim-encryption, now it's a
> real plugin).

What change was this, exactly? Did he port the whole NSS+NSPR code from
Gaim to gaim-encryption?
Has this change been applied to the normally distributed source or is it
a debian-hack-only?

> I think people would really like a gaim-encryption plugin package in the
> main Debian repository...

Yes, I can assume that by the number of emails I get about it, but that
doesn't justify including a hacky package, IMHO.

I'm sorry if I sound rude, but I've been packaging gaim-encryption for a
while now and would find it polite to be informed about such plans.
(Yes, I have all that fatherly crap about packages I work on)
From what I've  understood, I don't particularly like your plan, but
you're free to try to convince me, prove me wrong, or just ignore me and
upload it anyway.

Cheers
-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: pearpc_0.3.1-2_i386.changes UNACCEPT

[Leo \"Costela\" Antunes]

On Sex, 2004-10-15 at 16:29, Bartosz Fenski aka fEnIo wrote:
> > Rejected: pearpc_0.3.1-2.dsc refers to pearpc_0.3.1.orig.tar.gz, 
> > but I can't find it in the queue or in the pool.
> 
> Are you sure you made your package with the same (md5) orig file as the
> previous version?

Yes, both -1 and -2 versions were built with the exact same file. The
.dsc's both have the same md5sum.

But thanks anyway.

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

pearpc_0.3.1-2_i386.changes UNACCEPT

[Leo \"Costela\" Antunes]

Hi all

What can I do about the forwarded problem?
I tried reuploading the files + the orig.tar.gz, but it generated the
same problem.
Any pointers?

Cheers and thanks

-Forwarded Message-
> From: Debian Installer <[EMAIL PROTECTED]>
> To: Leo Costela <[EMAIL PROTECTED]>
> Cc: Debian Installer <[EMAIL PROTECTED]>
> Subject: pearpc_0.3.1-2_i386.changes UNACCEPT
> Date: Fri, 15 Oct 2004 14:54:34 -0400
> 
> Rejected: pearpc_0.3.1-2.dsc refers to pearpc_0.3.1.orig.tar.gz, but I can't 
> find it in the queue or in the pool.
> 
> 
> ===
> 
> Despite being ACCEPTed, this package failed the database sanity checks
> at the time of install.  This should only happen rarely and in
> corner-cases (a binary upload of a package which has since been
> melanie'd for example), so no code to do the necessary unaccept
> actions has been written.  These actions (e.g. bug reopening,
> announcement rescinding, etc.) will have to be done by hand.  Also,
> the files have been left in the accepted directory; please deal with
> them as well.
-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: pearpc_0.3.1-2_i386.changes UNACCEPT

[Leo \"Costela\" Antunes]

On Sex, 2004-10-15 at 16:29, Bartosz Fenski aka fEnIo wrote:
> > Rejected: pearpc_0.3.1-2.dsc refers to pearpc_0.3.1.orig.tar.gz, 
> > but I can't find it in the queue or in the pool.
> 
> Are you sure you made your package with the same (md5) orig file as the
> previous version?

Yes, both -1 and -2 versions were built with the exact same file. The
.dsc's both have the same md5sum.

But thanks anyway.

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

pearpc_0.3.1-2_i386.changes UNACCEPT

[Leo \"Costela\" Antunes]

Hi all

What can I do about the forwarded problem?
I tried reuploading the files + the orig.tar.gz, but it generated the
same problem.
Any pointers?

Cheers and thanks

-Forwarded Message-
> From: Debian Installer <[EMAIL PROTECTED]>
> To: Leo Costela <[EMAIL PROTECTED]>
> Cc: Debian Installer <[EMAIL PROTECTED]>
> Subject: pearpc_0.3.1-2_i386.changes UNACCEPT
> Date: Fri, 15 Oct 2004 14:54:34 -0400
> 
> Rejected: pearpc_0.3.1-2.dsc refers to pearpc_0.3.1.orig.tar.gz, but I can't find it 
> in the queue or in the pool.
> 
> 
> ===
> 
> Despite being ACCEPTed, this package failed the database sanity checks
> at the time of install.  This should only happen rarely and in
> corner-cases (a binary upload of a package which has since been
> melanie'd for example), so no code to do the necessary unaccept
> actions has been written.  These actions (e.g. bug reopening,
> announcement rescinding, etc.) will have to be done by hand.  Also,
> the files have been left in the accepted directory; please deal with
> them as well.
-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

PearPC Section (contrib or main)

[Leo \"Costela\" Antunes]

Hi all,

A couple of days ago, I uploaded PearPC for inclusion into the archive.
More specifically into the contrib/otherosfs section, but now I got one
doubt troubling me.

PearPC does not need MacOS X or other non-free operating system to be
fully used, it can be used with Debian/PPC for example, so, does it need
to stay in contrib?

Maybe it's still time to contact the archive admins and change the
section before the first version hits unstable (during security
scrutiny).

Cheers

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

PearPC Section (contrib or main)

[Leo \"Costela\" Antunes]

Hi all,

A couple of days ago, I uploaded PearPC for inclusion into the archive.
More specifically into the contrib/otherosfs section, but now I got one
doubt troubling me.

PearPC does not need MacOS X or other non-free operating system to be
fully used, it can be used with Debian/PPC for example, so, does it need
to stay in contrib?

Maybe it's still time to contact the archive admins and change the
section before the first version hits unstable (during security
scrutiny).

Cheers

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: How to deal with sql-database structures on upgrade

[Leo \"Costela\" Antunes]

On Seg, 2003-12-15 at 20:05, Thorsten Sauter wrote:
> Hi all,

Hi

> I have tried to write some postinst scripts to migrate the existing
> database into the new one, but I think now this is impossible, because
> maybe informations which are needed in the new version are missing in
> the old one.
> 
> Some other packages like sysstat simply prints a message about a
> incompatible dataformat, and move or delete the old datafile. Is this an
> acceptable way for such a program also? And if so, should I do a
> database export first, before deleting and recreating the database with
> the new tables?
> 
> Any hints are welcome :-)

The way I see it, the best solution is:
1) set up a preinst script to warn of the change and confirm the upgrade
2) after that run a postinst script to migrate whatever possible
remembering the user to double check and finnish manually the new
database
3) do not delete the old one without asking explicitly, with a high
debconf priority (IMHO that's the best threshold between user
interaction and space bloat)

Remember to have a sensible enough preinst to detect the need for
migration.

Cheers
-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: How to deal with sql-database structures on upgrade

[Leo \"Costela\" Antunes]

On Seg, 2003-12-15 at 20:05, Thorsten Sauter wrote:
> Hi all,

Hi

> I have tried to write some postinst scripts to migrate the existing
> database into the new one, but I think now this is impossible, because
> maybe informations which are needed in the new version are missing in
> the old one.
> 
> Some other packages like sysstat simply prints a message about a
> incompatible dataformat, and move or delete the old datafile. Is this an
> acceptable way for such a program also? And if so, should I do a
> database export first, before deleting and recreating the database with
> the new tables?
> 
> Any hints are welcome :-)

The way I see it, the best solution is:
1) set up a preinst script to warn of the change and confirm the upgrade
2) after that run a postinst script to migrate whatever possible
remembering the user to double check and finnish manually the new
database
3) do not delete the old one without asking explicitly, with a high
debconf priority (IMHO that's the best threshold between user
interaction and space bloat)

Remember to have a sensible enough preinst to detect the need for
migration.

Cheers
-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: Standards-Version

[Leo \"Costela\" Antunes]

On Qui, 2003-12-11 at 20:00, Florian Zaehringer wrote:
> Hi folks!

Hi 

> So I wonder how I can do that? Is there some ChangeLog for the Debian Policy?
> Does somebody know where I can find the right docs? Or better: Does somebody 
> perhaps know what needs to be done for a simple gtk-program to be moved from 
> 3.5.2 to 3.6.1?

Read:
/usr/share/doc/debian-policy/upgrading-checklist.txt.gz 
(package debian-policy)

There souldn't be much that needs to be done to keep your package up to
date policy-wise. Using lintian and linda should catch most mistakes
before you upload anything.

Good luck
Cheers
-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: Standards-Version

[Leo \"Costela\" Antunes]

On Qui, 2003-12-11 at 20:00, Florian Zaehringer wrote:
> Hi folks!

Hi 

> So I wonder how I can do that? Is there some ChangeLog for the Debian Policy?
> Does somebody know where I can find the right docs? Or better: Does somebody perhaps 
> know what needs to be done for a simple gtk-program to be moved from 3.5.2 to 3.6.1?

Read:
/usr/share/doc/debian-policy/upgrading-checklist.txt.gz 
(package debian-policy)

There souldn't be much that needs to be done to keep your package up to
date policy-wise. Using lintian and linda should catch most mistakes
before you upload anything.

Good luck
Cheers
-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: newbie packaging question

[Leo \"Costela\" Antunes]

On Ter, 2003-08-12 at 14:38, Eric Winger wrote:
> * all the deb-src entries i tried to add to my sources.list give me 
> errors when I try to get the source. What is the url for sources? This 
> is my latest attempt:
> 
> deb-src ftp://ftp.debian.org/debian testing main contrib free

My sources.list has:

deb-src http://http.us.debian.org/debian unstable main contrib non-free

Change "unstable" for the distribution you use.
Why the hell did you put "free" in there? That's redundant! =]

Hope this works out for you.

Cheers
-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Key Fingerprint: 8AE6 CDFF 6535 192F B5B6 5921 2262 D36F 7ADF 9466
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: newbie packaging question

[Leo \"Costela\" Antunes]

On Ter, 2003-08-12 at 14:38, Eric Winger wrote:
> * all the deb-src entries i tried to add to my sources.list give me 
> errors when I try to get the source. What is the url for sources? This 
> is my latest attempt:
> 
> deb-src ftp://ftp.debian.org/debian testing main contrib free

My sources.list has:

deb-src http://http.us.debian.org/debian unstable main contrib non-free

Change "unstable" for the distribution you use.
Why the hell did you put "free" in there? That's redundant! =]

Hope this works out for you.

Cheers
-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Key Fingerprint: 8AE6 CDFF 6535 192F B5B6 5921 2262 D36F 7ADF 9466
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: about gzip

[Leo \"Costela\" Antunes]

On Qui, 2003-07-24 at 09:09, Halil Demirezen wrote:
[snip]
> my first question: is it a true usage to put gzip into rules?
> and secondly, should i specify "gzip" as a Build-Depends?

No need to specify the dependency on gzip because it's in
build-essential, according to policy.
I'm not sure about the gzip direct usage though (but assume It's OK).

Cheers

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Key Fingerprint: 8AE6 CDFF 6535 192F B5B6 5921 2262 D36F 7ADF 9466
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: about gzip

[Leo \"Costela\" Antunes]

On Qui, 2003-07-24 at 09:09, Halil Demirezen wrote:
[snip]
> my first question: is it a true usage to put gzip into rules?
> and secondly, should i specify "gzip" as a Build-Depends?

No need to specify the dependency on gzip because it's in
build-essential, according to policy.
I'm not sure about the gzip direct usage though (but assume It's OK).

Cheers

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Key Fingerprint: 8AE6 CDFF 6535 192F B5B6 5921 2262 D36F 7ADF 9466
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: Questions of legality WRT dvd software

[Leo \"Costela\" Antunes]

Hi

On Ter, 2003-07-08 at 12:21, Stephen Gran wrote:
> The reason I'm writing is because I wonder about two things - the
> program itself is only a single .c file, about 15K compressed, and I
> wonder if there is any point in packaging up something this small and
> easy to compile.  Granted, it's not some 4 line shell script, but it
> still seems to push the lower bounds of reasonable.

If you feel it doesn't "deserve" it's own package, maybe you could
arrange a merge with another related package, even though I can't really
think of any suitable one.
IMO it should be packaged independently for one reason: ease of
distribution. End users should be freed - whenever possible - of the
"burden" of compilation and hand tunning of programs.

> The second thing is the legality of this.  There are, I know, issues
> around the DMCA and friends that govern what you are allowed to do with
> dvd's, at least in some uncivilized countries, and I don't know if a
> program that's sole purpose is to extract stuff off of dvd's will be
> redistributable by Debian.  I know that apps like transcode are not in
> Debian, although I don't know if this is is the reason.  Anybody
> familiar with this terrain feel like commenting?

For your second problem, I think debian-legal is a better place to ask,
though I assume you will encounter resistance in your path...
Worst case scenario: package it anyway and create a personal repository,
like many before you! =]

Cheers
-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Key Fingerprint: 8AE6 CDFF 6535 192F B5B6 5921 2262 D36F 7ADF 9466
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: Questions of legality WRT dvd software

[Leo \"Costela\" Antunes]

Hi

On Ter, 2003-07-08 at 12:21, Stephen Gran wrote:
> The reason I'm writing is because I wonder about two things - the
> program itself is only a single .c file, about 15K compressed, and I
> wonder if there is any point in packaging up something this small and
> easy to compile.  Granted, it's not some 4 line shell script, but it
> still seems to push the lower bounds of reasonable.

If you feel it doesn't "deserve" it's own package, maybe you could
arrange a merge with another related package, even though I can't really
think of any suitable one.
IMO it should be packaged independently for one reason: ease of
distribution. End users should be freed - whenever possible - of the
"burden" of compilation and hand tunning of programs.

> The second thing is the legality of this.  There are, I know, issues
> around the DMCA and friends that govern what you are allowed to do with
> dvd's, at least in some uncivilized countries, and I don't know if a
> program that's sole purpose is to extract stuff off of dvd's will be
> redistributable by Debian.  I know that apps like transcode are not in
> Debian, although I don't know if this is is the reason.  Anybody
> familiar with this terrain feel like commenting?

For your second problem, I think debian-legal is a better place to ask,
though I assume you will encounter resistance in your path...
Worst case scenario: package it anyway and create a personal repository,
like many before you! =]

Cheers
-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Key Fingerprint: 8AE6 CDFF 6535 192F B5B6 5921 2262 D36F 7ADF 9466
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: Documentation

[Leo \"Costela\" Antunes]

Hi

I imagine a simple suggests with a note on the README pointing to the
documentation on doc-linux-{html,text} would be fine.
I don't think using the extra space for duplicate documentation is a
good idea, but maybe there's a more gentle solution...

PS.:(pt_BR) eu me sinto um idiota escrevendo inglês pra gente do
Brasil... mas tudo bem...

On Seg, 2003-07-07 at 07:22, Michelle Ribeiro wrote:
> Hello, all. 
> 
> My package upstream's have a doc, about the package installation and 
> configuration at LDP. So, this doc is also in the doc-linux-html package. 
> 
> Should I release the doc html and txt version with my package?
> Make doc-linux-html a dependency doesn't seems good to me due the size. 
> 
> Best cheers, 
> 
> -- 
> --
> Michelle Ribeiro
-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Key Fingerprint: 8AE6 CDFF 6535 192F B5B6 5921 2262 D36F 7ADF 9466
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: Documentation

[Leo \"Costela\" Antunes]

Hi

I imagine a simple suggests with a note on the README pointing to the
documentation on doc-linux-{html,text} would be fine.
I don't think using the extra space for duplicate documentation is a
good idea, but maybe there's a more gentle solution...

PS.:(pt_BR) eu me sinto um idiota escrevendo inglês pra gente do
Brasil... mas tudo bem...

On Seg, 2003-07-07 at 07:22, Michelle Ribeiro wrote:
> Hello, all. 
> 
> My package upstream's have a doc, about the package installation and configuration 
> at LDP. So, this doc is also in the doc-linux-html package. 
> 
> Should I release the doc html and txt version with my package?
> Make doc-linux-html a dependency doesn't seems good to me due the size. 
> 
> Best cheers, 
> 
> -- 
> --
> Michelle Ribeiro
-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Key Fingerprint: 8AE6 CDFF 6535 192F B5B6 5921 2262 D36F 7ADF 9466
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: Machine access for NM Applicants.

[Leo \"Costela\" Antunes]

The buildd-logs[1] don't provide enough debug information?
I know this doesn't answer your question, but I assume the portability
issues you mention are all build problems in one of Debian's supported
architectures, am I right?
If so, the build logs[1] should give you more then enough help to track
your problems down before asking for another upload, and therefore
triggering another buildd run.

I hope I haven't missunderstood anything =]

[1] http://buildd.debian.org/build.php

Cheers

On Ter, 2003-05-27 at 11:55, Mike Schacht wrote:
> Hello,
> 
> I am not an official debian developer, but I maintain a couple of 
> packages. One of them, kdirstat, is already in the official 
> distribution. I intend to apply as a NM soon, but in the meantime, 
> since the last update of kdirstat, I am having portability problems. I 
> have no resources for confirming a fix the these problems. My sponser 
> has access to the developer machines and can reproduce the problems on 
> the other architectures, but hasn't had time to fix the failures or 
> test my fixes. 
> This list of debian machines: http://db.debian.org/machines.cgi, shows 
> that some of the machines allow access by "all". There is no further 
> explanation of who qualifies as "all", or how someone who is "all" can 
> get access.
> 
> The debian-admin list is given at the Admin contact for these machines, 
> but subscriptions are not open and archives are not available.
> 
> Can anyone tell me if I might qualify for access to these machines for 
> debugging packaging portability problem purposes, and if how, how to 
> get it.
> 
> Thanks,
> 
> Mike Schacht
[EMAIL PROTECTED]
-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Key Fingerprint: 8AE6 CDFF 6535 192F B5B6 5921 2262 D36F 7ADF 9466
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: Machine access for NM Applicants.

[Leo \"Costela\" Antunes]

The buildd-logs[1] don't provide enough debug information?
I know this doesn't answer your question, but I assume the portability
issues you mention are all build problems in one of Debian's supported
architectures, am I right?
If so, the build logs[1] should give you more then enough help to track
your problems down before asking for another upload, and therefore
triggering another buildd run.

I hope I haven't missunderstood anything =]

[1] http://buildd.debian.org/build.php

Cheers

On Ter, 2003-05-27 at 11:55, Mike Schacht wrote:
> Hello,
> 
> I am not an official debian developer, but I maintain a couple of 
> packages. One of them, kdirstat, is already in the official 
> distribution. I intend to apply as a NM soon, but in the meantime, 
> since the last update of kdirstat, I am having portability problems. I 
> have no resources for confirming a fix the these problems. My sponser 
> has access to the developer machines and can reproduce the problems on 
> the other architectures, but hasn't had time to fix the failures or 
> test my fixes. 
> This list of debian machines: http://db.debian.org/machines.cgi, shows 
> that some of the machines allow access by "all". There is no further 
> explanation of who qualifies as "all", or how someone who is "all" can 
> get access.
> 
> The debian-admin list is given at the Admin contact for these machines, 
> but subscriptions are not open and archives are not available.
> 
> Can anyone tell me if I might qualify for access to these machines for 
> debugging packaging portability problem purposes, and if how, how to 
> get it.
> 
> Thanks,
> 
> Mike Schacht
[EMAIL PROTECTED]
-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Key Fingerprint: 8AE6 CDFF 6535 192F B5B6 5921 2262 D36F 7ADF 9466
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: Querying what packages are installed in postinst

[Leo \"Costela\" Antunes]

'dpkg -l ' has the official answer. Of course the package
_might_ have been removed manually, but in that case the user has
already messed up with all infrastructure we care to provide =]
I belive this method should be enough.

Cheers

On Ter, 2003-05-27 at 05:28, Alan Woodland wrote:
> For the next version of a package which I currently have sponsored in 
> Debian (mozilla-mozgest) I want to add support for mozilla-firebird 
> (preliminary packages are avalible from 
> http://people.debian.org/~eric/debian/i386) and mozilla-snapshot. The 
> problem is that in order to do this I need to do different things for 
> each of the browsers in postinst and postrm. Basicaly what I'd like to 
> know is if theres a nicer way to test if a package is installed than 
> just testing the existance of files that the package would create if it 
> was installed?
> 
> Thanks,
> Alan
-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Key Fingerprint: 8AE6 CDFF 6535 192F B5B6 5921 2262 D36F 7ADF 9466
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: webCDwriter: Native vs. Non-native package

[Leo \"Costela\" Antunes]

On Sex, 2003-05-09 at 19:53, José Luis Tallón wrote:
> Hi all,
> 
> * Even though the upstream sources contain no debian subdirectory,
>   dpkg-buildpackage says it is creating a Debian-native package,
>   and thus creates no .diif.gz containing my debian subdirectory.
> I have put packagename-version.orig.tar.gz in the parent directory, per the 
> manual pages/howto/.. [can't remember now]

The file should be called packagename_version.orig.tar.gz. Mind the
underscore, that's a subtle and common mistake.
Also be sure to use the right version notation.

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Key Fingerprint: 8AE6CDFF6535192FB5B659212262D36F7ADF9466
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: Library version naming/sonames

[Leo \"Costela\" Antunes]

On Mon, 2003-04-28 at 18:37, Morgon Kanter wrote:
> Should it be:
> libzthread2-9:2.11
> libzthread2-2.2.11
> libzthread9-2.2.11
> libzthread2.9-2.2.11

The third one is the best, but you shouldn't use the exact version in
the package name, since this whole name changing thing is about
conflicting packages, i.e.: packages that break binary compatibility.
Therefore: libzthread9 is the one to go, with a 2.2.11 version field.
You could also use something like libzthread2.2-9 but that would only
make sense if you had two branches of the lib being developed at the
same time, and had the possibility of many sonames in the 2.2 branch and
many others in the 2.3 branch, for example (like libgtk1.2 and libgtk2.0
I guess).

All of this is better explained in policy and maybe I'm wrong with some
assumptions, so do your reading =]

Cheers

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Key Fingerprint: 8AE6CDFF6535192FB5B659212262D36F7ADF9466
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: Moving packages from "Requested" to "Can't be packaged"

[Leo \"Costela\" Antunes]

I second that.

But maybe we still need a canonical list of problematic packages, and
the CBP status would only be aplicable to inform wannabe packagers that
there's an ongoing analysis on the "packagability" of that software.

On second thought, I'm not sure it would be worth it, but I like the
idea... (how unconclusive!)

Cheers

On Fri, 2003-04-25 at 08:23, Bas Zoetekouw wrote:
> Hi andy.grafham!
> 
> You wrote:
> 
> > Is there any way of requesting the BTS to move a package from
> > "Requested" to "Can't be packaged"? I was investigating packaging
> > "VisualBoyAdvance" a gameboy advance emulator, but it looks like
> > license problems will make it impossible to include in debian.
> 
> AFAIK, there is no automatic way of doing this.  
> What about adding a new tag, something like CBP (cannot be packaged), to
> the wnpp?
> 
> -- 
> Kind regards,
> ++
> | Bas Zoetekouw  | GPG key: 0644fab7 |
> || Fingerprint: c1f5 f24c d514 3fec 8bf6 |
> | [EMAIL PROTECTED], [EMAIL PROTECTED] |  a2b1 2bae e41f 0644 
> fab7 |
> ++ 
-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Key Fingerprint: 8AE6CDFF6535192FB5B659212262D36F7ADF9466
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: Replacing a package with a newer, renamed version of itself.

[Leo \"Costela\" Antunes]

On Sat, 2003-04-19 at 15:22, Sean 'Shaleh' Perry wrote:
> the conflicts and replaces make a new install of the package over the old one 
> go smoothly.  However, it will not cause apt to automatically move to the new 
> package.

A good solution IMO is to keep a fake (empty) package of
radiusd-freeradius that depends on the new freeradius package, that way,
if someone does have it installed, apt-get will try to upgrade it and
then install the new package. You'll have to dump the Conflicts though,
or else apt-get won't let you upgrade a package that'll be removed on
the same run.

Hope I've been helpful

Cheers
-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Key Fingerprint: 8AE6CDFF6535192FB5B659212262D36F7ADF9466
 "you must cut down the mightiest tree in the forest... with... a herring!"
-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Key Fingerprint: 8AE6CDFF6535192FB5B659212262D36F7ADF9466
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: RFS: readpst - Converts Outlook PST files to mbox and others

[Leo \"Costela\" Antunes]

Hi

On Wed, 2003-04-16 at 09:36, Joe Nahmias wrote:
> I posted a "clarification" from upstream about this to the BTS -- see
> the ITP (bug #178113) .  It doesn't seem
> (to me) that there is any _real_ legal issues -- perhaps mailing -legal
> is the right thing to do...

I'd dare to compare this to Abiword's treatment of .DOC's and _assume_
it's not a problem, but most of us here aren't lawyers so enquiring
about this on -legal is most advised, even for upstream's sake.

> Of course, if it turns out that the problem is sourceforge itself, we
> could host the project on alioth, no?

It really doesn't look like a SF issue, IMHO

Cheers

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Key Fingerprint: 8AE6CDFF6535192FB5B659212262D36F7ADF9466
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Lame Makefile problem

[Leo \"Costela\" Antunes]

Hi

I'm having this very lame problem with my debian/rules file:
I'm setting CFLAGS to -g in case the DEBUG build option is set but then
running
$(MAKE) CFLAGS=$(CFLAGS) 
inside the build target results in overridden variables.
From what I could find, the Makefile uses CFLAGS internally to store
pkg-config output. Is there a way to tell Make to append to the CFLAGS
variable?

Thanks for the attention
Cheers

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Key Fingerprint: 8AE6CDFF6535192FB5B659212262D36F7ADF9466
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: Got program, howto debianize ?

[Leo \"Costela\" Antunes]

On Tue, 2003-04-01 at 17:04, josX wrote:
> John wrote:
> >josX wrote:
> >> I wrote a program, and i would like to have it in debian format,
> >> and if people like it in the debian releases. If packaging isn't
> >> too difficult i would have no problems with debianizing it, but
> >> it is not my first interest (packaging/installing etc). OTOH, maybe
> >> it is fun to do, i've no idea what exacly it involves and how
> >> difficult it is.
> >
> >See http://www.debian.org/doc/maint-guide/.
> 
> Ok thanks.
> Problem: its not just one binary which goes into $PATH.
> Problem 2: packaging doesn't interest me to the point that i can hardly
> focus to read the docs about it.
> If someone wants to package the program, let me know and i'll be
> happy to help out where i can with changing the sources to something
> suitable.

File a RFP on your own program, wait for a suitable Debian Developer (or
wannabe Developer) to become interested.
IMO, it's easier that way! =]

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Public Key: http://wallsplash.net/leo/pubkey.asc
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: Got program, howto debianize ?

[Leo \"Costela\" Antunes]

On Tue, 2003-04-01 at 17:04, josX wrote:
> John wrote:
> >josX wrote:
> >> I wrote a program, and i would like to have it in debian format,
> >> and if people like it in the debian releases. If packaging isn't
> >> too difficult i would have no problems with debianizing it, but
> >> it is not my first interest (packaging/installing etc). OTOH, maybe
> >> it is fun to do, i've no idea what exacly it involves and how
> >> difficult it is.
> >
> >See http://www.debian.org/doc/maint-guide/.
> 
> Ok thanks.
> Problem: its not just one binary which goes into $PATH.
> Problem 2: packaging doesn't interest me to the point that i can hardly
> focus to read the docs about it.
> If someone wants to package the program, let me know and i'll be
> happy to help out where i can with changing the sources to something
> suitable.

File a RFP on your own program, wait for a suitable Debian Developer (or
wannabe Developer) to become interested.
IMO, it's easier that way! =]

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Public Key: http://wallsplash.net/leo/pubkey.asc
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Help with RC bugs

[Leo \"Costela\" Antunes]

Hi

I'm having some problems with two RC bugs in my packages, I'd like to
see if any mentor can help me out...

FIRST (#184121): is it OK to declare an explicit dependency on
libsigc++-dev if my dev package includes files from it? (I'm guessing it
is, by documentation, but something doesn't look right...)

SECOND (#184431): what's the best practice with packages that have a
*-gnome (1.2) version that requires applet support? Now that gnome 1.2
support is gone for the panel and applets in unstable, should I just
stop uploading new versions of the -gnome package to it? I can't upload
them to testing and I shouldn't upload them to unstable since only
people with an old libpanel-applet0 installed will be able to install it
(that's why it took me some time to detect this bug). Maybe
libpanel-applet0 should remain on unstable just to keep gnome1.2 apps
running, or is it the plan to force gnome1.2 apps into gnome2?

THIRD and last: should I bump the changelog's urgency about this bugs?
(the next upload will also be recompiled against libsigc++c102/gcc3.2)

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Public Key: http://wallsplash.net/leo/pubkey.asc
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Help with RC bugs

[Leo \"Costela\" Antunes]

Hi

I'm having some problems with two RC bugs in my packages, I'd like to
see if any mentor can help me out...

FIRST (#184121): is it OK to declare an explicit dependency on
libsigc++-dev if my dev package includes files from it? (I'm guessing it
is, by documentation, but something doesn't look right...)

SECOND (#184431): what's the best practice with packages that have a
*-gnome (1.2) version that requires applet support? Now that gnome 1.2
support is gone for the panel and applets in unstable, should I just
stop uploading new versions of the -gnome package to it? I can't upload
them to testing and I shouldn't upload them to unstable since only
people with an old libpanel-applet0 installed will be able to install it
(that's why it took me some time to detect this bug). Maybe
libpanel-applet0 should remain on unstable just to keep gnome1.2 apps
running, or is it the plan to force gnome1.2 apps into gnome2?

THIRD and last: should I bump the changelog's urgency about this bugs?
(the next upload will also be recompiled against libsigc++c102/gcc3.2)

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Public Key: http://wallsplash.net/leo/pubkey.asc
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: Debian Policy and related documents

[Leo \"Costela\" Antunes]

On Thu, 2003-03-13 at 15:32, deFreese, Barry wrote:
> Hello,
> 
> Is there a single document source for the Debian Policy and related
> documents?  I have been trying to diligently read through all of them but
> occasionally I want to read it offline and I really don't want to have to go
> through each page to print it.

apt-get install debian-policy

=]

cheers

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Public Key: http://wallsplash.net/leo/pubkey.asc
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: Debian Policy and related documents

[Leo \"Costela\" Antunes]

On Thu, 2003-03-13 at 15:32, deFreese, Barry wrote:
> Hello,
> 
> Is there a single document source for the Debian Policy and related
> documents?  I have been trying to diligently read through all of them but
> occasionally I want to read it offline and I really don't want to have to go
> through each page to print it.

apt-get install debian-policy

=]

cheers

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Public Key: http://wallsplash.net/leo/pubkey.asc
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: need help with bug #178837 (automake)

[Leo \"Costela\" Antunes]

On Seg, 2003-02-03 at 16:40, Frank Gevaerts wrote:
> CFLAGS  = -Wall -O3 `freetype-config --cflags` ${SDL_CFLAGS} 
> ${BUMPREF_CFLAGS} `
> 
> What do I have to change to be able to add -mieee on alpha, preferably
> from debian/rules, or configure ?

I'd use something like this:

CFLAGS = "-O2 -Wall"
if 
CFLAGS += "-mieee"
endif

I'm not sure this is the Best Way(tm), but it should work...

Cheers

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Public Key: http://wallsplash.net/leo/pubkey.asc
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: need help with bug #178837 (automake)

[Leo \"Costela\" Antunes]

On Seg, 2003-02-03 at 16:40, Frank Gevaerts wrote:
> CFLAGS  = -Wall -O3 `freetype-config --cflags` ${SDL_CFLAGS} ${BUMPREF_CFLAGS} `
> 
> What do I have to change to be able to add -mieee on alpha, preferably
> from debian/rules, or configure ?

I'd use something like this:

CFLAGS = "-O2 -Wall"
if 
CFLAGS += "-mieee"
endif

I'm not sure this is the Best Way(tm), but it should work...

Cheers

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Public Key: http://wallsplash.net/leo/pubkey.asc
 "you must cut down the mightiest tree in the forest... with... a herring!"



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

Re: Producing a None-Hardware specific .deb

[Leo \"Costela\" Antunes]

On Fri, 2003-01-31 at 22:06, Ian Wilkinson wrote:
> and if anyone tells me to RTFM please point out where TFM is, as I can't 
> find it :-)

Maybe you could find some aswers in the Perl Packaging Policy, at:
http://www.debian.org/doc/packaging-manuals/perl-policy/ (TFM =] )

Appart from the specifics of packaging a Perl module, packaging an
arch-indep source should be almost the same as packaging a
arch-dependant one, the only difference is putting all your debhelper
(or other script) calls in the arch-indep rule or your debian/rules
file, and not forget to specify it as an arch-indep package on the
control file.

I think that's it, but what do I know? I'm on the AM queue for 6 months
=]

Cheers

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Public Key: http://wallsplash.net/leo/pubkey.asc
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: Producing a None-Hardware specific .deb

[Leo \"Costela\" Antunes]

On Fri, 2003-01-31 at 22:06, Ian Wilkinson wrote:
> and if anyone tells me to RTFM please point out where TFM is, as I can't 
> find it :-)

Maybe you could find some aswers in the Perl Packaging Policy, at:
http://www.debian.org/doc/packaging-manuals/perl-policy/ (TFM =] )

Appart from the specifics of packaging a Perl module, packaging an
arch-indep source should be almost the same as packaging a
arch-dependant one, the only difference is putting all your debhelper
(or other script) calls in the arch-indep rule or your debian/rules
file, and not forget to specify it as an arch-indep package on the
control file.

I think that's it, but what do I know? I'm on the AM queue for 6 months
=]

Cheers

-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Public Key: http://wallsplash.net/leo/pubkey.asc
 "you must cut down the mightiest tree in the forest... with... a herring!"



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

Re: [mindas@ziedas.ktu.lt: Bug#177332: libphp-adodb on testing should be applied to the stable]

[Leo \"Costela\" Antunes]

Hi

> Should I do nothing an tag as wontfix? Or try to upload into stable?
> Any comments?

IMHO, these are quite serious bugs, but do not render the package
unusable OR pose any security threat, since using GetUpdateSQL is not
the only way to do it.
Furthermore, introducing the new version to stable could - if the
internal changes were really so big - bring a whole series of unforeseen
compatibility issues.

I'd advise the user to upgrade manually or use another way to do his
thing, record your reasons in the bug's log and tag it wontfix.

Cheers


-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Public Key: http://wallsplash.net/leo/pubkey.asc
 "you must cut down the mightiest tree in the forest... with... a herring!"


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

Re: [mindas@ziedas.ktu.lt: Bug#177332: libphp-adodb on testingshould be applied to the stable]

[Leo \"Costela\" Antunes]

Hi

> Should I do nothing an tag as wontfix? Or try to upload into stable?
> Any comments?

IMHO, these are quite serious bugs, but do not render the package
unusable OR pose any security threat, since using GetUpdateSQL is not
the only way to do it.
Furthermore, introducing the new version to stable could - if the
internal changes were really so big - bring a whole series of unforeseen
compatibility issues.

I'd advise the user to upgrade manually or use another way to do his
thing, record your reasons in the bug's log and tag it wontfix.

Cheers


-- 

 Leo Costela
 <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
 Public Key: http://wallsplash.net/leo/pubkey.asc
 "you must cut down the mightiest tree in the forest... with... a herring!"



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