Re: RFS: tikiwiki

[Marcus Better]

Alec Berryman wrote:

> The version in experimental is probably vulnerable to CVE-2006-3048,
> CVE-2006-3047, and CVE-2006-2635.

These are resolved in 1.9.4 according to information here:

http://tikiwiki.org/tiki-read_article.php?articleId=131
http://www.securityfocus.com/bid/18143
http://www.securityfocus.com/bid/18421

> I'm unable to find mention that these issues have been resolved
> in the upstream changelog or in yours; 

Right. Upstream seems to be sloppy announcing things. I'll discuss it with
them, and put the CVE numbers in the Debian changelog.

Thanks,

Marcus


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

Re: RFS: tcpser

[Thijs Kinkhorst]

On Thu, 2006-07-06 at 05:54 +0100, Peter Collingbourne wrote:
> For some reason mentors.debian.org won't take, here is the new location:
> 
> http://www.doc.ic.ac.uk/~pcc03/tmp/debian/tcpser_1.0rc10-1.diff.gz
> http://www.doc.ic.ac.uk/~pcc03/tmp/debian/tcpser_1.0rc10-1.dsc
> http://www.doc.ic.ac.uk/~pcc03/tmp/debian/tcpser_1.0rc10.orig.tar.gz

Excellent, uploaded.


Thijs


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

RFS: gpsd - GPS (Global Positioning System) service daemon (bugfix upload)

[Tilman Koschnick]

Hi,

I'm looking for a one-time sponsor for the gpsd package. My usual
sponsor is not available at the moment, and the new upload would fix a
serious bug.

The changes to the previous revision consist of two lines only, not
counting the changelog.

Package is here:
.

Bug report (to keep the previous version out of testing) is here:


Anyone interested and able to help?

Cheers, Til


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

Re: RFS: gpsd - GPS (Global Positioning System) service daemon (bugfix upload)

[Thijs Kinkhorst]

Hello Tilman,

> I'm looking for a one-time sponsor for the gpsd package. My usual
> sponsor is not available at the moment, and the new upload would fix a
> serious bug.
> 
> The changes to the previous revision consist of two lines only, not
> counting the changelog.

When I diff the package with the version currently in the archive, I get
a lot more changes than that, mostly in the documentation/manpages it
seems. Did you upload the right version?


Thijs


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

Re: RFS: pmplib - create music databases used by portable media players

[Thijs Kinkhorst]

On Mon, 2006-07-03 at 00:30 +0100, Martin Ellis wrote: 
> I'm looking for someone to review the package as it stands, in order
> that any necessary changes for inclusion in Debian can be made
> before 0.12 is released.

Sure, no problem, here goes. In general the package looks good, good
work! I've got two small points:

* You install the upstream README, but that contains no relevant
  information (licence info is already in copyright);

* Upstream COPYING has an old FSF address.

Good luck with your package!


Thijs




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

Re: RFS: gpsd - GPS (Global Positioning System) service daemon (bugfix upload)

[Tilman Koschnick]

On Thu, 2006-07-06 at 12:19 +0200, Thijs Kinkhorst wrote:
> Hello Tilman,
> 
> > I'm looking for a one-time sponsor for the gpsd package. My usual
> > sponsor is not available at the moment, and the new upload would fix a
> > serious bug.
> > 
> > The changes to the previous revision consist of two lines only, not
> > counting the changelog.
> 
> When I diff the package with the version currently in the archive, I get
> a lot more changes than that, mostly in the documentation/manpages it
> seems. Did you upload the right version?

Hmm, yes. Not sure where this is coming from - slightly different build
environment between me and my sponsor? Updated xmlto or docbook-xsl
between the builds?

The resulting man pages in the binary packages are identical, though.

Cheers, Til


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

Re: RFS: ipbt

[Adam Borowski]

On Wed, Jul 05, 2006 at 10:19:15PM -0400, Bryan Donlan wrote:
> On 7/5/06, Adam Borowski <[EMAIL PROTECTED]> wrote:
> >On Wed, Jul 05, 2006 at 02:28:59PM -0400, Bryan Donlan wrote:
> >> * Package name: ipbt
> >> ipbt   - Fast, advanced ttyrec player
> >
> >Oops, on just loading a typical NetHack recording:
> >
> >real1m36.499s
> >user1m35.050s
> >sys 0m0.648s
> >
> >Something is terribly wrong here, as my very inefficient
> >implementation of the same loads the same file in a split second.
> 
> The current implementation loads all frames of the movie ahead of
> time, generates a list of (character position, frame index, new value)
> structures, then sorts by position and time. This allows it to rapidly
> reconstruct the value of any character at any  frame.

My idea was to store the unprocessed vt100 stream and just generate
checkpoints every X bytes.  Every checkpoint contains a snapshot of
the tty state, so seeking is a matter of silently sending the vt100
stream since the last checkpoint to your tty emulator -- silently as
in "no immediate screen updates".

On any recording of reasonable size this is actually going so fast
that in my last alpha release (termrec) I create the checkpoints but
not actually use them yet; every seek does a complete reload since
the very start.

PuTTY tty engine is more sophisticated than mine, but I don't see any
reason why it would be significantly slower; this appears to be a
fault of the storage data structure.

Anyway, I doubt if I'll find the time to finish up termrec anytime
soon, but if you would find any pieces of code useful, feel free to
take them, without bothering yourself with license issues (ipbt is
MITed; termrec is GPLed but it's mine -- so here's the license grant).

Meep?
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Empty files in pbuilder chroot

[Thibaut Paumard]

Hello,

I'm trying to set up pbuilder, but I end up with empty files (0 size,
access rights set to a-rwx). In particular, cc is empty. When running
pbuilder build, ldconfig complains about many libraries that are also
empty.

Any idea where it comes from?

Regards, Thibaut.


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

Re: Empty files in pbuilder chroot

[George Danchev]

On Thursday 06 July 2006 18:13, Thibaut Paumard wrote:
> Hello,

Hello,

> I'm trying to set up pbuilder, but I end up with empty files (0 size,
> access rights set to a-rwx). In particular, cc is empty. When running
> pbuilder build, ldconfig complains about many libraries that are also
> empty.
>
> Any idea where it comes from?

My very wild guess is:
- You are running out of space on the file system you are creating the chroot
Possible further pointers:
- Examine the output of "pbuilder create sid --debug"
- Check BTS logs

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


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

Re: Empty files in pbuilder chroot

[Thibaut Paumard]

Thanks,

> Le jeudi 06 juillet 2006 à 18:34 +0300, George Danchev a écrit :
> > I'm trying to set up pbuilder, but I end up with empty files (0 size,
> > access rights set to a-rwx). In particular, cc is empty. When running
> > pbuilder build, ldconfig complains about many libraries that are also
> > empty.
> >
> > Any idea where it comes from?
>
> My very wild guess is:
> - You are running out of space on the file system you are creating the chroot

That was also my first thought. I initially had 1.9G left, I now have
3.5G and the problem remains.

> Possible further pointers:
> - Examine the output of "pbuilder create sid --debug"

It's pretty stuffy, but the only line that looks potentially troublesome
to me is:
W: can't find package: base-config

> - Check BTS logs

Couldn't find anything similar.

Regards, Thibaut.


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

header sanity check?

[Tyler MacDonald]

I just created a /usr/local/include/hi_there.h , #include'd it from a header
file, and built a -dev debian package containing that header file without
any sort of warnings or errors.

So it's really easy to package a -dev package with a header file, that
#include's a header file in a package that it doesn't depend on.

Going through Developer's Corner I don't see anything that helps define how
to catch this or if there are any requirements. pbuilder won't even catch it
if the Build-Depends for the source package contains all the -dev packages
needed.

Is there anything like dh_headerdeps or guidelines on how -dev packages
should depend on eachother?

My gut feeling is that:

1. If you #include a header directly, you have to depend on that
package.

2. If you #include a header of a package that #includes a header
whose definitions you use (eg; #including httpd.h and then using apr_
stuff), and stick to stuff that is part of the former header's published
interface (eg; using apr_status_t), you're okay if you just depend on the
former -dev package.

3. If you do the above but use part of the latter's header that
*isn't* part of the former's public interface (eg; APR_HAS_UNICODE_FS), then
you're not only dealing with (or being) a lazy C programmer, you also have
to depend on the latter -dev package as well.

4. If you #include a header that doesn't belong to *any* package
(including the source package you're currently building), that's just
outright evil.

I also think that #1 and #4 would be easy (trivial, even) to catch in some
automated way, and that would make an excellent addition to lintian and/or
linda... #2 and #3 might be more tricky. At least determining #1, and
providing a ${headers:Depends} value would be a valuable tool to
maintainers and should be possible in most cases.

Is it worth doing? Has it been done or hashed out already?

Thanks,
Tyler


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