Re: gfdl gcc documentation packages for non-free: update

[Matthias Klose]

Nikita V. Youshchenko writes:
> 
> > Nikita V. Youshchenko writes:
> > > Hello.
> > >
> > > I've updated gcc-4.1 documentation packages (Section: non-free/doc).
> > > Packages are no longer debian-native, also several issues have been
> > > fixed.
> > >
> > > Also, I've created gcc-doc-defaults package (Section: contrib/doc)
> > > that builds gcc-doc, cpp-doc, gfortran-doc and treelang-doc packages
> > > with proper dependences and symlinks.
> > >
> > > Maintainer of all those packages is set to debian-gcc@lists.debian.org
> > >
> > > As for over version of gcc - packages for those that are currently in
> > > sid still contain gfdl documentation. So creation of proper non-free
> > > packages has to be postponed until this documentation is not removed
> > > from there.
> > >
> > > Currently packages are at
> > > http://zigzag.lvk.cs.msu.su/~nikita/debian/gcc-doc/
> > >
> > > I'm going to upload there (to non-free and contrib) in a day or two.
> > > Comments welcome.
> >
> > some problems:
> >
> >  - the man pages (all except gfortran.1) are not built from
> >source. -> RC
> 
> Most manpages are available as is in upstream tarball - so I decided to use 
> those unmodified. Fortran manpage was not there - so I had to build it.
> 
> If that's a problem, all may be made built from texi source, that should be 
> simple.

AFAIK yes; docs have to be built from source. And you maybe want to
have the debian changes in the manpages as well.

> >  - the gfdl is not included in the man pages, nor the gfdl(7) man
> >pages are shipped, violating the GFDL (dropping invariant
> >sections). -> RC
> 
> What is the best approach to handle this? Include full gfdl text in 
> debian/copyright? Depend on a package that will provide gfdl.7 (or 
> maybe /usr/share/common-licenses/GFDL)?

include fsf-funding.7, gfdl.7, gpl.7 in the gcc-doc-defaults package.

> >  - the java man pages are not built
> >
> >  - the libstdc++ docs are not built
> 
> I've checked which files are in package set build from gcc-4.1 4.1.1-10, 
> but are not in files built from gcc-4.1 4.1.1ds1-13 source.
> 
> Probably java stuff is built from different source - so additional source 
> package is needed for it's docs?

no, they are included in the same source, just built separately by
demand of the release team. they should be built from a gcc-doc
package as well. same thing with gnat docs.

the gcc/doc/include directory seems to be missing as well.

> As for libstdc++, looks like you do still provide all docs in 
> libstdc++6-doc 4.1.1ds1-13 package?

there's at least one GFDL'd document missing.

> >  - the man pages are not up to date. you have to apply the patches
> >from our sources.
> 
> This could be done I guess.

please do. wrong documentation is worse than no documentation.

> So I did the minimal packaging, and will try to fix at least the required 
> minimum of issues so etch will include those (in non-free and contrib 
> sections). Btw, thanks for reports.
> 
> If anybody else wishes to create or maintain or co-maintain gcc docs 
> packages, using mine or your or any other approach, I have nothing 
> against. Just the opposite. I have bad and hopeless problems with free 
> time. All free software - related plans and ideas, even simple ones, are 
> frozen already for months. I'm doing gcc-doc packages only because I don't 
> see anybody else working on this problem, which I consider critical.

your help is welcome, but what is it good for having non-free
documentation for free software?

  Matthias


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

Re: XS-X-Vcs-XXX field not (yet) announced

[Manoj Srivastava]

On Fri, 22 Sep 2006 21:43:37 +0200, Stefano Zacchiroli <[EMAIL PROTECTED]> 
said: 

> On Fri, Sep 22, 2006 at 02:21:22PM -0500, John Goerzen wrote:
>> I would also like to raise a question: does it make any sense to be
>> able to list two URLs, one for the Debian branch and one for the
>> upstream branch?

> I've thought about similar issues. I made up my mind about these
> questions being in the wrong direction :)

> My idea for this field it to give a pointer intended for human
> consumption. Once a user knows where to look, if he is willing to
> have access to the repo he is probably able to discover branches,
> tags, learn the repo layout and so on. If we agree on this idea I
> would answer no, it doesn't make sense to me.

> Alternatively we can try to fully encode in the field(s) all the
> semantic information that might be needed to perform several tasks:
> automatic downloading of the appropriate branch matching a given
> debian release, spotting the tags matching given versions,
> whatever. I really think this is a dangerous slope, we will probably
> be swamped in the details of the VCS we consider.

> XS-Vcs-XXX was in my mind a one-size-does-fit-all solution, assuming
> the target of the information is a human. YMMV.

Seems to me that this is fit for centralized single branch
 repositories only -- at least, I fail to see how I can represent my
 mlti-branch (no yet multi-repository) configs that need at least 3
 different branches from three different categories to pull together
 my Debian packages.

If this is a SVN only thing, then  you could get awau with
 calling ti XS-SVN field.

manoj
-- 
The truth about a man lies first and foremost in what he hides. Andre
Malraux
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: XS-X-Vcs-XXX field not (yet) announced

[martin f krafft]

also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2006.09.23.0936 +0200]:
> Seems to me that this is fit for centralized single branch
>  repositories only -- at least, I fail to see how I can represent my
>  mlti-branch (no yet multi-repository) configs that need at least 3
>  different branches from three different categories to pull together
>  my Debian packages.

I would call this a deficiency with tla/baz. The point about the
field is to allow people easy access to the source. That, by
default, kind of rules out GNU arch already, and especially so if
you need to take 100 steps just to get there.

How about you identify the main repository and add a README?

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
i wish this wish not to be granted!
-- achilles (hofstadter's geb)


signature.asc
Description: Digital signature (GPG/PGP)

Re: XS-X-Vcs-XXX field not (yet) announced

[Reinhard Tartler]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

>> XS-Vcs-XXX was in my mind a one-size-does-fit-all solution, assuming
>> the target of the information is a human. YMMV.
>
> Seems to me that this is fit for centralized single branch
>  repositories only -- at least, I fail to see how I can represent my
>  mlti-branch (no yet multi-repository) configs that need at least 3
>  different branches from three different categories to pull together
>  my Debian packages.

Not everyone uses arch/tla/baz the way you do. But you are right, your
way is not representable using a single field. What would you need to
express how you version control your packages in a debian/control file?

> If this is a SVN only thing, then  you could get awau with
>  calling ti XS-SVN field.

No, this is definitly not an SVN only think, I can use it for bzr (a
decent decentral VCS) mantained packages pretty well.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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

Re: XS-X-Vcs-XXX field not (yet) announced

[Stefano Zacchiroli]

On Fri, Sep 22, 2006 at 08:25:13PM -0400, Joey Hess wrote:
> > file without the XS- prefix. Am I wrong? Request for help on this ...

> Vcs: svn svn://...
> 
> My preference is either the above or XS-Vcs-*

Thanks, my preference is now for XS-Vcs-*, it requires changes which
only affect the code I'm able to change right now and it's nice looking.
I will send a new patch for the PTS and try to document it.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: XS-X-Vcs-XXX field not (yet) announced

[Stefano Zacchiroli]

On Sat, Sep 23, 2006 at 02:36:46AM -0500, Manoj Srivastava wrote:
> Seems to me that this is fit for centralized single branch
>  repositories only -- at least, I fail to see how I can represent my
>  mlti-branch (no yet multi-repository) configs that need at least 3
>  different branches from three different categories to pull together
>  my Debian packages.
> 
> If this is a SVN only thing, then  you could get awau with
>  calling ti XS-SVN field.

It is definitely not an SVN only thing. As some evidence for this
consider how many non distributed VCS are available out there, that the
initial usage of the field by dato was for a Bzr repository, and that
the Common Lisp guys are able to use it with Darcs.

Still I see your point, it can be that not all repository layouts can be
expressed with it. My point on this is still the same: where do you use
to commit patches to the packaging? or better, do you have a repo you
consider "master" wrt to the other? If there is one, as I think, mention
it in the field and use debian/README.Debian-source for additional info.

If you really think your scheme is specific of a given VCS of a given
way of working you can propose a URL scheme able to encode multiple
URLs, or we can imagine put in the field a comma separated list of URLs.
After all the semantic of the value of XS-Vcs-* will be *-driven.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: stale lock files

[Goswin von Brederlow]

Roger Leigh <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>
>> Roger Leigh <[EMAIL PROTECTED]> writes:
>>
>>> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>>>
 Write the pid and host to the lock file. When you detect a lock and
 the lock is on the local host then check the pid is still valid. If
 not the lock is stale. If the lock is from a remote host there is
 little you can do but ask.
>>>
>>> Why not use fcntl/lockf byte region locking on the entire file?  It
>>> gets released as soon as the process terminates, so there are no
>>> issues with stale locks, and it works over NFS.
>
>> NFS isn't everything.
>
> Of course, but you get that extra feature "for free".  Why would that
> be a be something to avoid?

Because NFS isn't everything.

What do you do on fuse, afs, coda, oracle fs, lustrefs? Do they all
have fcntl? What if the nfs has no lockd running?

I'm not saying to avoid a good thing. But you might not always have
it.

MfG
Goswin


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

Re: RFA libtorrent and rtorrent

[Goswin von Brederlow]

Graham Wilson <[EMAIL PROTECTED]> writes:

> On Wed, Sep 20, 2006 at 04:23:35PM -0500, Graham Wilson wrote:
>> On Wed, Sep 20, 2006 at 10:04:14PM +0100, Qingning Huo wrote:
>> > Because of recent changes in my Real Life, I cannot spend enough time on
>> > libtorrent and rtorrent as I would like.  Whoever want to adopt are
>> > welcome to take over their maintenance.  I would recommend them be
>> > adopted together, because they are closely related (same author), and
>> > new upstream versions are always released at the same time.
>> 
>> I use rtorrent quite a bit, so I'd be glad to take over maintence.
>
> Looks like Jose sent his mail first, so he is welcome to take them, but
> I'd be glad to if things fall through.

How about comaintainership? Could you two (or three looking further in
the thread) work well together?

Unless your characters clash: the more the merrier.

MfG
Goswin


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

Re: Compatibility between Debian amd64 and other distributions

[Goswin von Brederlow]

Daniel Jacobowitz <[EMAIL PROTECTED]> writes:

> On Sat, Sep 23, 2006 at 02:50:35AM +0200, Goswin von Brederlow wrote:
>> But running Debian binaries on other distributions remains a
>> problem. For example static binaries that use libnss* plugins will
>> fail to find those plugins on other systems. Copying the debian libc6
>> to your ~/lib/ dir on another distribution will break locale plugins.
>
> Do you have any less contrived examples?  FWIW, I think in either of
> these cases you deserve to keep both pieces.

How do you keep both pieces if you are not root?

MfG
Goswin


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

Re: Bug#387813: ITP: gpar2 -- A GUI for verifying and repairing PAR and PAR2 recovery sets

[Ondřej Surý]

On Sat, 2006-09-16 at 21:24 +0200, Khalid El Fathi wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Khalid El Fathi <[EMAIL PROTECTED]>
> 
> * Package name: gpar2
>   Version : 0.3
>   Upstream Author : John Augustine <[EMAIL PROTECTED]>
> * URL : http://sourceforge.net/projects/parchive/
> * License : GPL
>   Description : A GUI for verifying and repairing PAR and PAR2 recovery 
> sets
> 
> A simple, easy to use graphical interface for verification and repairation of
> PAR v1.0 and PAR v2.0(PAR2) recovery sets. PAR1 support is currently minimal,
> as it is deprecated this most likely will not change, so do not expect the
> headers, progress, output, and status to update when performing actions on
> these.

You can add more (sentense or two) about what is PAR recovery set and...

> GPar2 is based on GTKMM, a wrapper for GTK+, and requires the
> standard par2 library, libpar2, to run.

...strip this sentense, you should describe functionality and not
programming language/libraries used to create package.  Anybody can just
look at Depends: to see what libraries are used.

Ondrej.
-- 
Ondřej Surý <[EMAIL PROTECTED]>


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

Re: Media players in Debian

[Reinhard Tartler]

FWIW, I found your mail unnecessarily offensive.

"Andrew Donnellan" <[EMAIL PROTECTED]> writes:

> On 9/22/06, Reinhard Tartler <[EMAIL PROTECTED]> wrote:
>> Upstream does care for legal issues, and patents in particular. Check
>> the mplayer development mailing list archive for the last months.
>
> For the last months, as you say. Maybe this is because of the increased
> pressure now that software patents are now being enforced and so on. At
> the beginning they seemed to just chuck in whatever.
>
[...]
> The Mplayer devs are still not communicating with Debian about the
> remaining problems. To rectify them we need to communicate better and
> get their input on d-l and d-d.

Regarding your attitude and how you (most probably not delibrately, and
its really not only you) spread misinformation, I can really understand
why upstream mplayer developers do not seek dialogue on the public
mailing lists debian-devel and debian-legal. It's a too wide audience
and a too heated topic to get useful results.

On the other hand, I got contacted by upstream (DonDiego and Rathann)
because I care for the mplayer package in ubuntu. They were very
friendly, helpful and listened to our concerns. They explained us some
thing we didn't really realise, and helped us to improve the
package. You see, upstream does communicate with distros. In fact, they
told us that they contacted SuSE (IIRC) before.

Considering your contributions to this thread, I see 3 possibilites:

 - you are interested in not having a mplayer package in debian, then
   please clearly say so. I don't have that impression
 - you are not interested in having a mplayer package in debian, then
   please refrain from contributing offensive posts like your previous
   ones.
 - you are interested in having a mplayer package in debian, then please
   try to learn the current status and problems why its not in debian
   (yet). As I said in another post, I don't really know them either,
   but I'm confident that Andrea and the ftpmaster will come up with an
   result in due time.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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

bts behaviour - versioning issue?

[Adrian von Bidder]

Yodel!

When I look at , I'm confused at the 
information for #309511, which is listed as outstanding (wishlist), 
but "Done" and "Archived".

Can anybody tell me why?

cheers
-- vbi

-- 
featured link: http://fortytwo.ch/gpg/subkeys


pgpdhdKKN92N8.pgp
Description: PGP signature

Re: bts behaviour - versioning issue?

[martin f krafft]

also sprach Adrian von Bidder <[EMAIL PROTECTED]> [2006.09.23.1101 +0200]:
> When I look at , I'm confused at the 
> information for #309511, which is listed as outstanding (wishlist), 
> but "Done" and "Archived".
> 
> Can anybody tell me why?

It was only fixed in a branch (the volatile branch), not in the
unstable one.

Versioning support isn't quite perfect yet.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"courage is not the absence of fear, but the decision
 that something else is more important than fear."
  -- ambrose redmoon


signature.asc
Description: Digital signature (GPG/PGP)

Re: RFA libtorrent and rtorrent

[Arnaud Fontaine]

> "Goswin" == Goswin von Brederlow <[EMAIL PROTECTED]> writes:

Goswin> How about comaintainership?  Could you two (or three looking
Goswin> further in the thread) work well together?

Hey,

Why not? I'm interested by co-maintainership.

Bye,
Arnaud Fontaine


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

Re: Media players in Debian

[Andrew Donnellan]

On 9/23/06, Reinhard Tartler <[EMAIL PROTECTED]> wrote:

Considering your contributions to this thread, I see 3 possibilites:

 - you are interested in not having a mplayer package in debian, then
   please clearly say so. I don't have that impression
 - you are not interested in having a mplayer package in debian, then
   please refrain from contributing offensive posts like your previous
   ones.
 - you are interested in having a mplayer package in debian, then please
   try to learn the current status and problems why its not in debian
   (yet). As I said in another post, I don't really know them either,
   but I'm confident that Andrea and the ftpmaster will come up with an
   result in due time.


I'd prefer number 3, until there is an alternative that can play
absolutely everything Mplayer can it would be great to have it in
Debian. However given the fact that 99.999% of Debian people are not
subscribed to the MPlayer dev list (and therefore don't know what's
going on; me included) and that the MPlayer people haven't in the past
contributed too well to legal discussions on d-l, they do have a
(probably undeserved) reputation for not caring about patent issues.

If my previous mail was offensive to you, please disregard.

--
Andrew Donnellan
http://andrewdonnellan.com
http://ajdlinux.blogspot.com
Jabber - [EMAIL PROTECTED]
GPG - hkp://subkeys.pgp.net 0x5D4C0C58
---
Member of Linux Australia - http://linux.org.au
Debian user - http://debian.org
Get free rewards - http://ezyrewards.com/?id=23484
OpenNIC user - http://www.opennic.unrated.net


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

Re: bts behaviour - versioning issue?

[Andreas Metzler]

Adrian von Bidder <[EMAIL PROTECTED]> wrote:
[...]
> When I look at , I'm confused at the 
> information for #309511, which is listed as outstanding (wishlist), 
> but "Done" and "Archived".

> Can anybody tell me why?

The version tracking code uses branches. The bts seems to think that
the bug applies to sid and etch but is fixed in the volatile branch
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=postgrey;dist=volatile
and it does not apply to stable
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=postgrey;dist=stable

cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.(c) Jasper Ffforde


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

Re: bts behaviour - versioning issue?

[Steve Langasek]

On Sat, Sep 23, 2006 at 11:01:58AM +0200, Adrian von Bidder wrote:

> When I look at , I'm confused at the 
> information for #309511, which is listed as outstanding (wishlist), 
> but "Done" and "Archived".

"outstanding" means "not fixed in the current version (for this suite)". 
"Done" means "fixed in some version", and "Archived" means "would have been
archived by now under the previous implementation of bug archival, but isn't
really archived yet because how to archive bugs with v-t is not yet
decided/implemented".

To get rid of the bug, I would suggest:

 reopen 309511
 close 309511

This was never a sourceful bug in the package, so version tracking is of no
benefit here -- an unversioned close is really best.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: XS-X-Vcs-XXX field not (yet) announced

[Manoj Srivastava]

On Sat, 23 Sep 2006 09:58:39 +0200, martin f krafft <[EMAIL PROTECTED]> said: 

> also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2006.09.23.0936
> +0200]:
>> Seems to me that this is fit for centralized single branch
>> repositories only -- at least, I fail to see how I can represent my
>> mlti-branch (no yet multi-repository) configs that need at least 3
>> different branches from three different categories to pull together
>> my Debian packages.

> I would call this a deficiency with tla/baz.

Sure, you can call things whatever you want to. There is
 nothing that really constrains you to reality.

The role of arch is to make life easier for me, the developer,
 not to fit some arbitrary criteria like  all projects must be
 describable by a single URL.  If you think lacking that characteristic
 is a failure of the version control system  ... Umm, I am speechless.

See, upstream comes from its own source, it seems a good idea
 to keep sources for different packages separate. I can do
 tla_load_dirs to maintain the upstream branch, detect and handle file
 renames, etc.

All my ./debian dirs have more in common with each other than
 the upstream package -- so the ./debian dir in make is very
 similar to the ./debian dir in ucf --  than it is to either make or
 ucf itself.  Makes sense to derive all ./debian dirs from an
 archetypical parent -- this allows me to make changes (like when I
 created md5sums for files in packages) -- by replaying changes to the
 parent in all the children, and updating the checked our dirs (one
 change, one simple one-off script).

I also have one common */debian/common dir (which is where the
 bulk of the md5sum changes occured).

So my lay out gives me flexibility, reduces the time when
 creating new packages, and reduces work required to make common
 changes across my packages, and also the work required when there is a
 new upstream.

It would be far harder to automate the upgrade-to-new-upstream
 scripts were it  all munged into one unholy mess of a  combined
 category. 

> The point about the field is to allow people easy access to the
> source. That, by default, kind of rules out GNU arch already, and
> especially so if you need to take 100 steps just to get there.

A hundred steps? I see you either have no idea what you are
 talking about, or are trolling, so I shall drop this conversation
 here.

I fear I have been trolled. I have lost. Sorry for the noise.

manoj
-- 
When you're dining out and you suspect something's wrong, you're
probably right.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: XS-X-Vcs-XXX field not (yet) announced

[Manoj Srivastava]

On Sat, 23 Sep 2006 10:20:15 +0200, Stefano Zacchiroli
<[EMAIL PROTECTED]> said:  

> Still I see your point, it can be that not all repository layouts
> can be expressed with it. My point on this is still the same: where
> do you use to commit patches to the packaging?

I commit changes to a local repo behind a couple of firewalls
 that do not accept external connections.

> or better, do you have a repo you consider "master" wrt to the
> other?

That private repository is the master.

> If there is one, as I think, mention it in the field and use
> debian/README.Debian-source for additional info.

That information is mostly useless.

I do have a signed public mirror of the repository which any
 one can read, and branch and pull from, but it does not take
 commits. 

> If you really think your scheme is specific of a given VCS of a
> given way of working

I do. Arch configs were present from the very earliest days of
 Arch, and most of the non-toy arch projects I have seen do use
 configs to pull together a project from multiple branches/

> you can propose a URL scheme able to encode multiple URLs, or we can
> imagine put in the field a comma separated list of URLs.  After all
> the semantic of the value of XS-Vcs-* will be *-driven.

URL's are not what would be needed.

The information that is required could possibly be couched
  like so (RFC 2822 field folding) (for flex in stable)
,
| XS-VCS-ARCH-Repo:  [EMAIL PROTECTED]
| http://arch.debian.org/arch/private/srivasta/archive-2003
| XS-VCS-ARCH-CONFIG:
|  ./flex/flex-2.5.31 
|   [EMAIL PROTECTED]/flex--devo--2.5--versionfix-3
|  ./flex/flex-2.5.31/debian
|   [EMAIL PROTECTED]/debian-dir--flex--1.0--versionfix-4
|  ./flex/flex-2.5.31/debian/common
|   [EMAIL PROTECTED]/skeleton-make-rules--main--0.1--patch-13
`

Hmm. This still does not provide a pointer to my archive gpg key.
 XS-VCS-ARCH-GPG-KEYID: 0x40612C84

manoj
-- 
"Big Brother is hallucinating."  Elizabeth D Zwicky
([EMAIL PROTECTED]), title of a comp.risks article
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Media players in Debian (was: new mplayer)

[Petter Reinholdtsen]

[Bartosz Fenski]
> Mplayer comes with his friend mencoder. I doubt that koffeine,
> totem, xine, vlc have something to offer in that regard.

Yes, I believe you are right there.  I suspect ffmpeg is the closest
"replacement" for mencoder, thought the feature set is different. :)

> And if I can't play something with vlc I'm almost sure it's playable with
> mplayer + w32codecs.

I've experienced both, movies playable with vlc and not mplayer, and
the other way around.  And vlc will use the w32codecs as well, so
there is not much difference there.

> Yes, I know there won't be w32codecs package in Debian, but even
> mplayer would be great addition.

I agree, but understand and accept that the license issues need to be
checked before it is accepted into debian.

Friendly,
-- 
Petter Reinholdtsen


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

Bug#388730: ITP: libnetfilter-log -- Netfilter netlink-log library

[Max Kellermann]

Package: wnpp
Severity: wishlist
Owner: Max Kellermann <[EMAIL PROTECTED]>

* Package name: libnetfilter-log
  Version : 0.0.13-1
  Upstream Author : Harald Welte <[EMAIL PROTECTED]>
* URL : http://www.netfilter.org/projects/libnetfilter_log/
* License : GPL
  Description : Netfilter netlink-log library

libnetfilter_log is a userspace library providing interface to packets
that have been logged by the kernel packet filter. It is is part of a
system that deprecates the old syslog/dmesg based packet logging.


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

Bug#388731: ITP: libnetfilter-queue -- Netfilter netlink-queue library

[Max Kellermann]

Package: wnpp
Severity: wishlist
Owner: Max Kellermann <[EMAIL PROTECTED]>

* Package name: libnetfilter-queue
  Version : 0.0.12-1
  Upstream Author : Harald Welte <[EMAIL PROTECTED]>
* URL : http://www.netfilter.org/projects/libnetfilter_queue/
* License : GPL
  Description : Netfilter netlink-queue library

libnetfilter_queue is a userspace library providing an API to packets
that have been queued by the kernel packet filter. It is is part of a
system that deprecates the old ip_queue / libipq mechanism.


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

Re: Media players in Debian (was: new mplayer)

[Sam Hocevar]

On Fri, Sep 22, 2006, Bartosz Fenski aka fEnIo wrote:

> Mplayer comes with his friend mencoder. I doubt that koffeine, totem, xine,
> vlc have something to offer in that regard.

   You seem rather mistaken. VLC has more encoding and streaming
features than mencoder. http://www.videolan.org/streaming-features.html

-- 
Sam.


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

Re: XS-X-Vcs-XXX field not (yet) announced

[Stefano Zacchiroli]

On Sat, Sep 23, 2006 at 04:21:21AM -0500, Manoj Srivastava wrote:
> I commit changes to a local repo behind a couple of firewalls
>  that do not accept external connections.

That settles this. If your repo does not accept external connections,
your users have no point in knowing it exists.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: XS-X-Vcs-XXX field not (yet) announced

[Stefano Zacchiroli]

On Sat, Sep 23, 2006 at 04:09:11AM -0500, Manoj Srivastava wrote:
> The role of arch is to make life easier for me, the developer,
>  not to fit some arbitrary criteria like  all projects must be
>  describable by a single URL.  If you think lacking that characteristic

You are stretching the intended meaning of the field. It it not, at
least in my mind, intended to be "a description of a project". It is
intended to be a pointer for package users to know where to look.
Nothing more than that.

> > The point about the field is to allow people easy access to the
> > source. That, by default, kind of rules out GNU arch already, and
> > especially so if you need to take 100 steps just to get there.
> A hundred steps? I see you either have no idea what you are
>  talking about, or are trolling, so I shall drop this conversation
>  here.

Please guys, not another flame war on VCS :-)

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Bug#388738: ITP: bongo-el -- buffer-oriented media player for Emacs

[Romain Francoise]

Package: wnpp
Severity: wishlist
Owner: Romain Francoise <[EMAIL PROTECTED]>

* Package name: bongo-el
  Version : 20060922 (darcs snapshot)
  Upstream Author : Daniel Brockman <[EMAIL PROTECTED]>
* URL or Web page : http://www.brockman.se/software/bongo/
* License : GNU GPL
  Description : buffer-oriented media player for Emacs

Bongo is a flexible buffer-oriented media player for Emacs.

It supports several player backends such as mpg321, ogg123 or mplayer
and has built-in support for displaying album covers and submitting
songs to Last.fm. It is comparable to EMMS but has a nicer user
interface.

-- 
  ,''`.
 : :' :Romain Francoise <[EMAIL PROTECTED]>
 `. `' http://people.debian.org/~rfrancoise/
   `-


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

Re: Debian cares more about documents than people

[Torsten Landschoff]

On Thu, Sep 21, 2006 at 11:28:02PM +0100, Jon Dowland wrote:
> and reverse engineering.  The out-of-tree patches at the
> time of 2.6.17 result in much faster transfers to SDHCI
> devices.  I don't know if dapper has these, and I don't
> know if they made 2.6.18.
 
I think that was one of the biggest changes in 2.6.18, the better SDHCI
support. So yes, they made it :)

Reference: 

http://mmc.drzeus.cx/wiki/Linux/Drivers/sdhci: Download 2.6.18-rc1 or
newer to get that version of the driver. 

Greetings

Torsten


signature.asc
Description: Digital signature

Re: Media players in Debian (was: new mplayer)

[Bartosz Fenski aka fEnIo]

On Fri, Sep 22, 2006 at 11:23:58AM +0200, Petter Reinholdtsen wrote:

> I agree, but understand and accept that the license issues need to be
> checked before it is accepted into debian.

I understand that, but mplayer inclusion is a problem since I remember that
mplayer exists. 

I really don't know what have to be checked and why it takes more than
4 years.

Many people contributed much time to make mplayer ready to enter our
archives and as far as I can see they are simply ignored.

Please tell me what's wrong with *current* package and what can we do to
make it better and stop saying me it's license issue.

That's simply boring. Which part of mplayer is non-free for you?

regards
fEnIo

-- 
  ,''`.  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo
 : :' :   32-050 Skawina - Glowackiego 3/15 - malopolskie v. - Poland
 `. `'   phone:+48602383548 | proud Debian maintainer and user
   `-  http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001


signature.asc
Description: Digital signature

Re: Media players in Debian (was: new mplayer)

[Thomas Weber]

Hi, 

Am Samstag, den 23.09.2006, 13:07 +0200 schrieb Bartosz Fenski aka
fEnIo:
> Please tell me what's wrong with *current* package and what can we do to
> make it better and stop saying me it's license issue.

IIRC, one of the things that lead to the rejection of the mplayer
package last time:
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2006-July/044840.html

Regards
Thomas


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

Re: Media players in Debian (was: new mplayer)

[Hendrik Sattler]

Am Freitag 22 September 2006 13:21 schrieb Andreas Tille:
> On Fri, 22 Sep 2006, Steinar H. Gunderson wrote:
> > I've heard these claims (ÿÿplayer X should be more than good enough, what
> > do you need mplayer for these days?ÿÿ) for at least the last five years
> > -- it's a difficult claim to refute, since people have rather different
> > viewing habits, different platforms and different needs. For _my_ part,
> > I've still not seen any player that works remotely as reliably over a
> > wide range over file formats and various brokenness as mplayer does.
>
> And, BTW, do we really need Emacs if we have vi?

What is vi? An emacs mode? ;)
But you are right. Except those frontends (totem, kaffeine) that use various 
backends (xine, gstreamer), there are stand-alone solutions like vlc and 
mplayer (and all those share many, many libs).
Every of those concepts, be it xine, gstreamer, vlc or mplayer, offer a 
slightly different way to use it. And all of them have pros and cons.

I could give examples why e.g. I do not like vlc at all but are a happy user 
of kaffeine/xine and mplayer. But to what gain?

HS

Re: bts behaviour - versioning issue?

[Adrian von Bidder]

On Saturday 23 September 2006 11:17, Steve Langasek wrote:
[...]

Ok, thanks everybody.

(Steve, I hope you do something today besides explaining things to me ;-)

cheers
-- vbi


-- 
Protect your privacy - encrypt your email: http://fortytwo.ch/gpg/intro


pgpBWHkmganv2.pgp
Description: PGP signature

Re: Compatibility between Debian amd64 and other distributions

[Daniel Jacobowitz]

On Sat, Sep 23, 2006 at 10:29:37AM +0200, Goswin von Brederlow wrote:
> Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> 
> > On Sat, Sep 23, 2006 at 02:50:35AM +0200, Goswin von Brederlow wrote:
> >> But running Debian binaries on other distributions remains a
> >> problem. For example static binaries that use libnss* plugins will
> >> fail to find those plugins on other systems. Copying the debian libc6
> >> to your ~/lib/ dir on another distribution will break locale plugins.
> >
> > Do you have any less contrived examples?  FWIW, I think in either of
> > these cases you deserve to keep both pieces.
> 
> How do you keep both pieces if you are not root?

That has nothing to do with it.  Copying libc.so.6 to something other
than its configured location breaks in plenty of other ways.  Static
binaries using nss are a long-standing and known source of problems,
and if you copy them to any other version of glibc - configured
differently or not - you're liable to crash.

-- 
Daniel Jacobowitz
CodeSourcery


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

Re: XS-X-Vcs-XXX field not (yet) announced

[Manoj Srivastava]

On Sat, 23 Sep 2006 12:37:20 +0200, Stefano Zacchiroli <[EMAIL PROTECTED]> 
said: 

> On Sat, Sep 23, 2006 at 04:09:11AM -0500, Manoj Srivastava wrote:
>> The role of arch is to make life easier for me, the developer, not
>> to fit some arbitrary criteria like all projects must be
>> describable by a single URL.  If you think lacking that
>> characteristic

> You are stretching the intended meaning of the field. It it not, at
> least in my mind, intended to be "a description of a project". It is
> intended to be a pointer for package users to know where to look.
> Nothing more than that.

That is not what I said. the field, used as in my example, 
 provides enough information to checkout a working copy of my flex as
 packaged for Sarge,  and you can create a local read-only version, or
 crete a mutable branch, merge back with me, or ask me to pull from
 you,  help in collaborative development, of just look at the history
 and run annotate or whatever.

I do suggest you read up  on distributed VCSs and get a feel
 for how differently a distributed schema works than the old
 centralized  ones did.

manoj
-- 
O'Reilly's Law of the Kitchen: Cleanliness is next to impossible
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: XS-X-Vcs-XXX field not (yet) announced

[Manoj Srivastava]

On Sat, 23 Sep 2006 12:33:18 +0200, Stefano Zacchiroli <[EMAIL PROTECTED]> 
said: 

> On Sat, Sep 23, 2006 at 04:21:21AM -0500, Manoj Srivastava wrote:
>> I commit changes to a local repo behind a couple of firewalls that
>> do not accept external connections.

> That settles this. If your repo does not accept external
> connections, your users have no point in knowing it exists.

No, all this settles is that it shows that you have a
 centralized VCS bent of mind, and do not understand the paradigm of
 distributed version control.

People have helped me with devotee in collaborative
 development; none of us had write access to the others repo. It is
 just not needed.

Even in collaborative development, no one ever needs to commit
 to the repo belonging to another person (look at darcs -- doing so
 would be, err, hard).

The idea is that you branch off my public mirror, hack, and
 tell me to pull off your branch -- and any number of us can do that.

As an example of how such merges work, look at
 http://people.debian.org/~srivasta/ikiwiki.png 

manoj
-- 
... Linux und seine Programme sind damit so etwas wie ein real
existierender Sozialismus der besseren Art...-- Christian Seel in der
Berliner Morgenpost v. 9.3.1997
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Compatibility between Debian amd64 and other distributions

[Goswin von Brederlow]

Daniel Jacobowitz <[EMAIL PROTECTED]> writes:

> On Sat, Sep 23, 2006 at 10:29:37AM +0200, Goswin von Brederlow wrote:
>> Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
>> 
>> > On Sat, Sep 23, 2006 at 02:50:35AM +0200, Goswin von Brederlow wrote:
>> >> But running Debian binaries on other distributions remains a
>> >> problem. For example static binaries that use libnss* plugins will
>> >> fail to find those plugins on other systems. Copying the debian libc6
>> >> to your ~/lib/ dir on another distribution will break locale plugins.
>> >
>> > Do you have any less contrived examples?  FWIW, I think in either of
>> > these cases you deserve to keep both pieces.
>> 
>> How do you keep both pieces if you are not root?
>
> That has nothing to do with it.  Copying libc.so.6 to something other
> than its configured location breaks in plenty of other ways.  Static
> binaries using nss are a long-standing and known source of problems,
> and if you copy them to any other version of glibc - configured
> differently or not - you're liable to crash.

So what you seem to say is: If you copy the libc6 or static libraries
between distributions you deserve to fail. Thats fine if you say it
straight out.

Does the same apply to libX11. Or can we do the compile for lib64, use
lib trick there as it is not frozen?


As for after etch I hope binutils will add the multiarch patch and
then we can finaly start moving stuff there as was planed for after
sarge.

MfG
Goswin

PS: Should the bug be retitled "Note FHS exception/deviation for amd64
in release notes"?


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

Re: Media players in Debian

[Joerg Jaspert]

On 10786 March 1977, Bartosz Fenski aka fEnIo wrote:

> Many people contributed much time to make mplayer ready to enter our
> archives and as far as I can see they are simply ignored.
> Please tell me what's wrong with *current* package and what can we do to
> make it better and stop saying me it's license issue.

I tell you that you are wrong, mplayer isnt ignored. There is just no
reason to discuss it on -devel, interaction with maintainer works
better.

-- 
bye Joerg
> 20. What would you do if you wanted to retire from the project?
Remove the passphrase from the (secret) gpg key and post it to
debian-devel. The keyring maintainers will lock the account ASAP.


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

Re: XS-X-Vcs-XXX field not (yet) announced

[Joey Hess]

Stefano Zacchiroli wrote:
> On Fri, Sep 22, 2006 at 08:25:13PM -0400, Joey Hess wrote:
> > > file without the XS- prefix. Am I wrong? Request for help on this ...
> 
> > Vcs: svn svn://...
> > 
> > My preference is either the above or XS-Vcs-*
> 
> Thanks, my preference is now for XS-Vcs-*, it requires changes which
> only affect the code I'm able to change right now and it's nice looking.
> I will send a new patch for the PTS and try to document it.

While the name is still in flux, could I suggest XS-Repo-*?

I tend to get VCS and RCS confused :-) and the capitalisation Vcs is a
little bit strange.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: stale lock files

[Josselin Mouette]

Le samedi 23 septembre 2006 à 10:33 +0200, Goswin von Brederlow a
écrit :
> > Of course, but you get that extra feature "for free".  Why would that
> > be a be something to avoid?
> 
> Because NFS isn't everything.
> 
> What do you do on fuse, afs, coda, oracle fs, lustrefs? Do they all
> have fcntl? 

AFAIK, afs, fuse and ocfs2 have (although recently introduced) posix
locking support. Lustre users get what they pay for, and I don't know
for coda.

> What if the nfs has no lockd running?

In this case I guess you can hire a new sysadmin.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Media players in Debian

[Russ Allbery]

Andrew Donnellan <[EMAIL PROTECTED]> writes:

> I'd prefer number 3, until there is an alternative that can play
> absolutely everything Mplayer can it would be great to have it in
> Debian. However given the fact that 99.999% of Debian people are not
> subscribed to the MPlayer dev list (and therefore don't know what's
> going on; me included) and that the MPlayer people haven't in the past
> contributed too well to legal discussions on d-l, they do have a
> (probably undeserved) reputation for not caring about patent issues.

Yeah, I do hope that willingness to participate in legal discussions in
d-l is not a prerequisite for believing that upstream authors care about
patent issues.  That's really not a particularly fun experience, and if
they feel like they've resolved all the problems, they may or may not feel
inclined to defend that position to random people on d-l at length.

Also, if I were a fairly busy upstream developer who didn't care greatly
about whether my software was included in any particular Linux
distribution (a perfectly reasonable perspective, IMO), I'd want someone
to fill me in on whether my software needed to comply with oh, say,
Nathaneal Nerode's opinions on legal issues or Marco d'Itri's before I
spent a lot of time discussing it.  Or perhaps something inbetween or
entirely different.  Reading for long enough to build up a score card
loses to improving the software when it comes to priorities for a random
upstream developer.

In other words, the fastest way to get legal issues with mplayer clarified
would be for someone who cared specifically about getting mplayer into
Debian putting together a list of the specific questions that need to be
resolved before Debian can take the package, and then go to upstream
(probably doing research in the mailing list first) and develop answers to
those questions.  Unfortunately, the hard part in the past has been
getting clarity on that first point.  It's not at all clear to me that
anyone really *knows* what issues need to be resolved before Debian can
take the package.  You'd probably have to do something like put together a
list of the questions that you think need to be resolved and then see if
one of the ftp-masters would be willing to read that over and see if it
includes everything they were concerned about.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: stale lock files

[Russ Allbery]

Josselin Mouette <[EMAIL PROTECTED]> writes:
> Le samedi 23 septembre 2006 à 10:33 +0200, Goswin von Brederlow a écrit :

>> What do you do on fuse, afs, coda, oracle fs, lustrefs? Do they all
>> have fcntl? 

> AFAIK, afs, fuse and ocfs2 have (although recently introduced) posix
> locking support. Lustre users get what they pay for, and I don't know
> for coda.

AFS has supported full-file locks for many years, but doesn't support
byte-range locking (or, rather, byte-range locks that do not cover the
entire file are only enforced on the local system).  In other words, it
basically supports flock and not fcntl, but it will convert fcntl locks
that cover the entire file into the lock type it does understand.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: XS-X-Vcs-XXX field not (yet) announced

[Stefano Zacchiroli]

On Sat, Sep 23, 2006 at 12:02:00PM -0400, Joey Hess wrote:
> > Thanks, my preference is now for XS-Vcs-*, it requires changes which
> > only affect the code I'm able to change right now and it's nice looking.
> > I will send a new patch for the PTS and try to document it.
> 
> While the name is still in flux, could I suggest XS-Repo-*?
> 
> I tend to get VCS and RCS confused :-) and the capitalisation Vcs is a
> little bit strange.

The capitalization is not significant in AFAIK.

I don't like XS-Repo-* because "Repo" is neither an acronym nor a full
word. What about XS-Repository-*?  I like it.  But this choice still
leaves me puzzled about the name "repository", is it a significant name
across different VCS?

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Work-needing packages report for Sep 22, 2006

[Christoph Berg]

[sending manually, the cron mail got stuck somewhere]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 309 (new: 20)
Total number of packages offered up for adoption: 99 (new: 6)
Total number of packages requested help for: 31 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   binutils-h8300-hms (#387772), orphaned 6 days ago
 Description: GNU cross assembler for H8/300[HS], linker and binary
   utilities
 Reverse Depends: brickos gcc-h8300-hms
 Installations reported by Popcon: 28

   brickos (#387769), orphaned 6 days ago
 Description: alternative OS for LEGO(r) Mindstorms RCX. Supports
   devel. in C/C++
 Installations reported by Popcon: 8

   divine (#387774), orphaned 6 days ago
 Description: Automatic IP configuration detection for laptops
 Installations reported by Popcon: 12

   exdbm (#387773), orphaned 6 days ago
 Description: eXode database manager
 Reverse Depends: gpsim
 Installations reported by Popcon: 70

   feta (#388363), orphaned 2 days ago
 Description: simpler interface to APT, dpkg, and other package tools
 Installations reported by Popcon: 178

   gcc-h8300-hms (#387771), orphaned 6 days ago
 Description: The GNU C/C++ cross-compilers for the Hitachi
   H8/300[HS] processors
 Reverse Depends: brickos
 Installations reported by Popcon: 17

   gpsim-led (#387778), orphaned 6 days ago
 Description: LED module for gpsim
 Installations reported by Popcon: 31

   gpsim-logic (#38), orphaned 6 days ago
 Description: logic module for gpsim
 Installations reported by Popcon: 36

   lnpd (#387770), orphaned 6 days ago
 Description: daemon for LNP communication with BrickOS
 Installations reported by Popcon: 1

   pathological (#388358), orphaned 2 days ago
 Description: puzzle game involving paths and marbles
 Installations reported by Popcon: 158

   pathological-music (#388359), orphaned 2 days ago
 Description: puzzle game involving paths and marbles
 Reverse Depends: pathological
 Installations reported by Popcon: 173

   pydance (#388361), orphaned 2 days ago
 Description: dancing simulation game similar to the kind in arcades
 Installations reported by Popcon: 82

   pydance-music (#388360), orphaned 2 days ago
 Description: Songs and step patterns for pydance
 Reverse Depends: pydance
 Installations reported by Popcon: 104

   tkcon (#388520), orphaned yesterday
 Installations reported by Popcon: 27

   typo3-dummy (#388763), orphaned today
 Description: Empty TYPO3 site package for starting a new site from
   scratch
 Reverse Depends: typo3
 Installations reported by Popcon: 24

   typo3-quickstart (#388764), orphaned today
 Description: TYPO3 Quickstart package with example pagetree
 Reverse Depends: typo3
 Installations reported by Popcon: 16

   typo3-site-installer (#388765), orphaned today
 Description: TYPO3 site installer
 Reverse Depends: typo3
 Installations reported by Popcon: 50

   typo3-src (#388766), orphaned today
 Description: Powerful content management framework (Meta package)
 Reverse Depends: typo3 typo3-dummy typo3-quickstart typo3-testsite
 Installations reported by Popcon: 25

   typo3-testsite (#388767), orphaned today
 Description: A site package to show the abilities of TYPO3
 Reverse Depends: typo3
 Installations reported by Popcon: 9

   uligo (#388362), orphaned 2 days ago
 Description: tsumego (go problems) practice tool
 Installations reported by Popcon: 97

289 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   gift (#388134), offered 3 days ago
 Description: the giFT filesharing system
 Reverse Depends: apollon gift giftd giftoxic giftui libgift-dev
   libgiftproto-dev libgiftproto0 libgnutella-gift libopenft-gift
 Installations reported by Popcon: 441

   gift-gnutella (#388135), offered 3 days ago
 Description: giFT plugin for the Gnutella network
 Reverse Depends: gift
 Installations reported by Popcon: 234

   gift-openft (#388136), offered 3 days ago
 Description: giFT plugin for the OpenFT network
 Reverse Depends: gift
 Installations reported by Popcon: 371

   libifp (#388365), offered 2 days ago
 Description: communicate with iRiver iFP audio devices
 Reverse Depends: amarok ifp-line-libifp ifpgui libifp-dev
 Installations reported by Popcon: 1713

   remind (#388426), offered 2 days ago
   

Bug#388805: RFP: please package mod_auth_xradius

[Ondřej Surý]

retitle 388805 RFP: please package mod_auth_xradius
reassign 388805 wnpp
severity 388805 wishlist
thank you

You have filled bug at wrong package. Apache 2.X doesn't contain module
for radius auth.  However I was able to find mod_auth_xradius, so I am
changing your bug to RFP (Request For Package) and reassigning it to our
WNPP database.


mod_auth_xradius provides high performance authentication against 
RFC 2865 RADIUS Servers.

Features
*Supports popular RADIUS Servers including 
 OpenRADIUS, FreeRADIUS and commercial servers.
*Distributed Authentication Cache using apr_memcache.
*Local Authentication Cache using DBM.
*Uses standard HTTP Basic Authentication, unlike 
 mod_auth_radius which uses cookies for sessions.

Kind regards,
-- 
Ondřej Surý <[EMAIL PROTECTED]>


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

Re: XS-X-Vcs-XXX field not (yet) announced

[martin f krafft]

also sprach Stefano Zacchiroli <[EMAIL PROTECTED]> [2006.09.23.2108 +0200]:
> I don't like XS-Repo-* because "Repo" is neither an acronym nor
> a full word. What about XS-Repository-*?  I like it.  But this
> choice still leaves me puzzled about the name "repository", is it
> a significant name across different VCS?

The word certainly doesn't have the same meaning across all VCS.

I'd vote for "X-VCS-svn" and the likes.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"in just seven days, i can make you a man!"
  -- the rocky horror picture show


signature.asc
Description: Digital signature (GPG/PGP)

Re: Bug#388805: RFP: please package mod_auth_xradius

[Matthew Wilcox]

reassign 388805 libapache-mod-auth-radius
retitle 388805 Please build apache 2 version
kthxbye

On Fri, Sep 22, 2006 at 07:10:04PM +0200, Ond??ej Sur?? wrote:
> retitle 388805 RFP: please package mod_auth_xradius
> reassign 388805 wnpp
> severity 388805 wishlist
> thank you
> 
> You have filled bug at wrong package. Apache 2.X doesn't contain module
> for radius auth.  However I was able to find mod_auth_xradius, so I am
> changing your bug to RFP (Request For Package) and reassigning it to our
> WNPP database.

Yeah, but that's wrong.  libapache-mod-auth-radius contains the source
for an apache 2.0 module, it jsut isn't built right now.

> 
> mod_auth_xradius provides high performance authentication against 
> RFC 2865 RADIUS Servers.
> 
> Features
> *Supports popular RADIUS Servers including 
>  OpenRADIUS, FreeRADIUS and commercial servers.
> *Distributed Authentication Cache using apr_memcache.
> *Local Authentication Cache using DBM.
> *Uses standard HTTP Basic Authentication, unlike 
>  mod_auth_radius which uses cookies for sessions.
> 
> Kind regards,
> -- 
> Ond??ej Sur?? <[EMAIL PROTECTED]>
> 


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

Re: Problem including (linux-kernel-headers 2.6.17)

[Martin Kittel]

>> /usr/include/linux/seqlock.h:76: error: expected '=', ',', ';\
>> ', 'asm' or '__attribute__' before 'unsigned'
>> /usr/include/linux/seqlock.h:91: error: expected '=', ',', ';\
>> ', 'asm' or '__attribute__' before 'int'
> 
> This comes from the __always_inline that is not defined. To define it, 
> include 
> linux/compiler.h
> Kernel headers tend to not include all headers for the things they use, you 
> magically have to find the right combination yourself.
> 

Thanks for your answer. This takes me one step further, which is this:

RTESys_MicroTime.c fast
In file included from /usr/include/linux/cpumask.h:86,
 from /usr/include/asm-x86_64/processor.h:23,
 from /usr/include/asm/processor.h:8,
 from /usr/include/asm-x86_64/timex.h:14,
 from /usr/include/asm/timex.h:8,
 from RTESys_MicroTime.c:77:
/usr/include/linux/bitmap.h: In function 'bitmap_zero':
/usr/include/linux/bitmap.h:128: error: 'BITS_PER_LONG' undeclared \
(first use in this function)
/usr/include/linux/bitmap.h:128: error: (Each undeclared identifier is \


BITS_PER_LONG seems to be declared in asm/types.h (i.e.
asm-x86_64/types.h in my case) and looks like this:

/*
 * These aren't exported outside the kernel to avoid name space clashes
 */
#ifdef __KERNEL__

#define BITS_PER_LONG 64

#ifndef __ASSEMBLY__


The same is true for the macro DECLARE_BITMAP which is used in cpumask.h
and defined in linux/types.h.

So this brings me back to me original problem: are user-space
applications allowed/supposed to use these headers? And if so, how are
they to be used if the headers rely on __KERNEL__ to be defined?

Thanks once more for any help,

Martin.


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

Bug#389091: ITP: obexpushd -- program for receiving files via Buetooth or IRDA

[Eugeniy Meshcheryakov]

Package: wnpp
Severity: wishlist
Owner: Eugeniy Meshcheryakov <[EMAIL PROTECTED]>

* Package name: obexpushd
  Version : 0.2
  Upstream Author : Hendrik Sattler <[EMAIL PROTECTED]>
* URL : http://www.hendrik-sattler.de/self/
* License : GPL
  Programming Lang: C
  Description : program for receiving files via Buetooth or IRDA

 This program can be used to receive files with OBEX protocol
 over Bluetooth or IrDA (infrared) connection. This program
 should work with many mobile devices like PDA's and mobile
 phones.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18-me
Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.UTF-8 (charmap=UTF-8)


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

Work-needing packages report for Sep 22, 2006

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 309 (new: 20)
Total number of packages offered up for adoption: 99 (new: 6)
Total number of packages requested help for: 31 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   binutils-h8300-hms (#387772), orphaned 6 days ago
 Description: GNU cross assembler for H8/300[HS], linker and binary
   utilities
 Reverse Depends: brickos gcc-h8300-hms
 Installations reported by Popcon: 28

   brickos (#387769), orphaned 6 days ago
 Description: alternative OS for LEGO(r) Mindstorms RCX. Supports
   devel. in C/C++
 Installations reported by Popcon: 8

   divine (#387774), orphaned 6 days ago
 Description: Automatic IP configuration detection for laptops
 Installations reported by Popcon: 12

   exdbm (#387773), orphaned 6 days ago
 Description: eXode database manager
 Reverse Depends: gpsim
 Installations reported by Popcon: 70

   feta (#388363), orphaned 2 days ago
 Description: simpler interface to APT, dpkg, and other package tools
 Installations reported by Popcon: 178

   gcc-h8300-hms (#387771), orphaned 6 days ago
 Description: The GNU C/C++ cross-compilers for the Hitachi
   H8/300[HS] processors
 Reverse Depends: brickos
 Installations reported by Popcon: 17

   gpsim-led (#387778), orphaned 6 days ago
 Description: LED module for gpsim
 Installations reported by Popcon: 31

   gpsim-logic (#38), orphaned 6 days ago
 Description: logic module for gpsim
 Installations reported by Popcon: 36

   lnpd (#387770), orphaned 6 days ago
 Description: daemon for LNP communication with BrickOS
 Installations reported by Popcon: 1

   pathological (#388358), orphaned 2 days ago
 Description: puzzle game involving paths and marbles
 Installations reported by Popcon: 158

   pathological-music (#388359), orphaned 2 days ago
 Description: puzzle game involving paths and marbles
 Reverse Depends: pathological
 Installations reported by Popcon: 173

   pydance (#388361), orphaned 2 days ago
 Description: dancing simulation game similar to the kind in arcades
 Installations reported by Popcon: 82

   pydance-music (#388360), orphaned 2 days ago
 Description: Songs and step patterns for pydance
 Reverse Depends: pydance
 Installations reported by Popcon: 104

   tkcon (#388520), orphaned yesterday
 Installations reported by Popcon: 27

   typo3-dummy (#388763), orphaned today
 Description: Empty TYPO3 site package for starting a new site from
   scratch
 Reverse Depends: typo3
 Installations reported by Popcon: 24

   typo3-quickstart (#388764), orphaned today
 Description: TYPO3 Quickstart package with example pagetree
 Reverse Depends: typo3
 Installations reported by Popcon: 16

   typo3-site-installer (#388765), orphaned today
 Description: TYPO3 site installer
 Reverse Depends: typo3
 Installations reported by Popcon: 50

   typo3-src (#388766), orphaned today
 Description: Powerful content management framework (Meta package)
 Reverse Depends: typo3 typo3-dummy typo3-quickstart typo3-testsite
 Installations reported by Popcon: 25

   typo3-testsite (#388767), orphaned today
 Description: A site package to show the abilities of TYPO3
 Reverse Depends: typo3
 Installations reported by Popcon: 9

   uligo (#388362), orphaned 2 days ago
 Description: tsumego (go problems) practice tool
 Installations reported by Popcon: 97

289 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   gift (#388134), offered 3 days ago
 Description: the giFT filesharing system
 Reverse Depends: apollon gift giftd giftoxic giftui libgift-dev
   libgiftproto-dev libgiftproto0 libgnutella-gift libopenft-gift
 Installations reported by Popcon: 441

   gift-gnutella (#388135), offered 3 days ago
 Description: giFT plugin for the Gnutella network
 Reverse Depends: gift
 Installations reported by Popcon: 234

   gift-openft (#388136), offered 3 days ago
 Description: giFT plugin for the OpenFT network
 Reverse Depends: gift
 Installations reported by Popcon: 371

   libifp (#388365), offered 2 days ago
 Description: communicate with iRiver iFP audio devices
 Reverse Depends: amarok ifp-line-libifp ifpgui libifp-dev
 Installations reported by Popcon: 1713

   remind (#388426), offered 2 days ago
 Description: a sophisticated reminder service
 Re

Re: RFA libtorrent and rtorrent

[Jose Luis Rivas]

2006/9/23, Arnaud Fontaine <[EMAIL PROTECTED]>:

> "Goswin" == Goswin von Brederlow <[EMAIL PROTECTED]> writes:

Goswin> How about comaintainership?  Could you two (or three looking
Goswin> further in the thread) work well together?

Hey,

Why not? I'm interested by co-maintainership.


I think that's great! Please contact me in private so we could arrenge
something together ;)


Bye,
Arnaud Fontaine


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





--
~ghostbar @ debian etch 2.6.15
http://ghostbar.no-ip.biz/ Linux Counter# 382503
San Cristobal, Tachira - Venezuela.
0110011101101110 011100110111010001100010011101110010
Fingerprint = 3E7D 4267 AFD5 2407 2A37  20AC 38A0 AD5B CACA B118


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

Re: Why are all packages getting so much bigger?

[Nathanael Nerode]

I'm guessing translations.  They eat up space really fast.
Is there a way to compare packages after localepurge runs?

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

This space intentionally left blank.


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

Bug#388569: general: always printed in letter format

[gerhard oettl]

On Fri, Sep 22, 2006 at 01:00:28PM +0200, gregor herrmann wrote:
>On Thu, 21 Sep 2006 11:13:27 +0200, gerhard oettl wrote:
>
>> Since updating to etch some weeks ago i was not able to print
>> from firefox, because always letter format is requested on the
>> printer panel.
>
>Do you have /etc/papersize and what is its content?



ls -l /etc/paper*
-rw-r--r-- 1 root root 595 2002-03-20 12:02 /etc/paper.config
-rw-r--r-- 1 root root   3 2004-03-26 14:53 /etc/papersize
-rw-r--r-- 1 root root   7 2004-12-10 15:35 /etc/papersize.dpkg-dist
-rw-r--r-- 1 root root   7 2006-09-09 23:01 /etc/papersize.dpkg-inst
-rw-r--r-- 1 root root   7 2006-08-16 19:19 /etc/papersize.ucf-dist



File paper.config:

[Paper]
US-Letter={612 792 72 72 72 72}
US-Legal={612 1008 72 72 72 72}
A3={841.88976 1190.5512 80 80 80 80 }
A4={595.27559 841.88976 80 80 80 80}
A5={420.94488 595.27559 80 80 80 80}
B4={730 1034 60 60 60 60}
B5={500 710 80 80 80 80}
B5-Japan={517 730 80 80 80 80}
Half-Letter={612 397 72 72 72 72}
Executive={523 758 72 72 72 72}
Tabloid/Ledger={794 1227 72 72 72 72}
Monarch={280 542 10 10 10 10}
SuperB={843 1227 80 80 80 80}
Envelope-Commercial={298 686 5 5 5 5}
Envelope-Monarch={280 542 5 5 5 5}
Envelope-DL={312 625 5 5 5 5}
Envelope-C5={460 650 5 5 5 5}
EuroPostcard={298 420 5 5 5 5}

File papersize:
A4

File papersize.dpkg-dist:
letter

File papersize.dpkg-inst:
letter

File papersize.ucf-dist:
letter


I changed /etc/papersize from A4 to a4 temporary (and restarted
to be sure) -> unchanged behaviour.

The environment variables PAPERSIZE and PAPERCONF are not set.




I am not an expert in postscript but as far as i anderstand the
papersize is inital set correct to A4.

According to 


the correct /PageSize value for A4 is [ 595 842 ] in default user
space units.

firefox by:
%%BoundingBox: 0 0 595 842
%%HiResBoundingBox: 0 0 595.25 841.9
%%DocumentPaperSizes: A4
and later in the suspect conditional area:
  dup /PageSize [ 595.25 841.9 ] put

xpdf by:
%%DocumentMedia: plain 595 841 0 () ()
%%BoundingBox: 0 0 595 841


The minimal differences seam to be ok. Both documents can 
be printed without changing this parts. But if the line 
containing
/PageSize 3
is present something unexpected happens.
All i understand is that a condition (that i dont anderstand) 
is tested and that the conditional part that contains that
/PaperSize 3 
line is proceeded.



Could there be an error in the ppd (postscript printer
description file) the reason for this? 
On the other hand: When setting the printer to a lexmark 
the first 250 lines of the postscript file are the same.



The printing also looks fine, if i remove the whole block that
contains that /PageSize 3 line. So it looks like this block is
not necessary at all or there is an error in the tested condition
and the test should return an result that does not process that
block.

--- firefox_letter.ps   2006-09-21 10:41:32.0 +0200
+++ firefox_a4-min.ps   2006-09-22 19:44:40.0 +0200
@@ -12,12 +12,7 @@
 
 %%BeginProlog
 /setpagedevice where
-{ pop 2 dict
-  dup /PageSize [ 595.25 841.9 ] put
-  dup /Policies 1 dict
-dup /PageSize 3 put
-  put
-  setpagedevice
+{
 } if
 [ /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef
  /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef


--- xpdf_letter.ps  2006-09-21 10:25:32.0 +0200
+++ xpdf_a4-min.ps  2006-09-22 19:46:21.0 +0200
@@ -17,12 +17,6 @@
 /pdfSetup {
   3 1 roll 2 array astore
   /setpagedevice where {
-pop 3 dict begin
-  /PageSize exch def
-  /ImagingBBox null def
-  /Policies 1 dict dup begin /PageSize 3 def end def
-  { /Duplex true def } if
-currentdict end setpagedevice
   } {
 pop pop
   } ifelse



The remaining question is: Where does this parts come from?


-- 
 .''`.   gerhard oettl   on   Debian/Gnu Linux
: :'  :  
`. `'`   gpg key: 1024D/D59131AA 2002-06-18
  `-


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

Re: XS-X-Vcs-XXX field not (yet) announced

[Manoj Srivastava]

On Sat, 23 Sep 2006 21:08:55 +0200, Stefano Zacchiroli <[EMAIL PROTECTED]> 
said: 

> On Sat, Sep 23, 2006 at 12:02:00PM -0400, Joey Hess wrote:
>> > Thanks, my preference is now for XS-Vcs-*, it requires changes
>> > which only affect the code I'm able to change right now and it's
>> > nice looking.  I will send a new patch for the PTS and try to
>> > document it.
>> 
>> While the name is still in flux, could I suggest XS-Repo-*?
>> 
>> I tend to get VCS and RCS confused :-) and the capitalisation Vcs
>> is a little bit strange.

> The capitalization is not significant in AFAIK.

Before we go on statndardizing it and writing coed to make
 part of of infrastructure do stuff with it, can we have a clear idea
 of the semantics of the field?

As I currently understand it, the format is
XS-VCS-XXX: $TAG:${URL}

Isn't XXX duplicating the effect of $TAG? And what meaning is
 ascribed to the $URL? Is it something that shall show up in PTS
 pages, and points to a web page that details how to get the sources?

If the ${URL}  part is supposed to have enough informnation
 for automated downloads, then I  POSIT that a single URL may not be
 enough; and this should be documented (only specific VCS layouts are
 amenable to a single-url-contains enough information to download the
 package sources).

manoj
-- 
The only way to learn a new programming language is by writing
programs in it. Brian Kernighan
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: XS-X-Vcs-XXX field not (yet) announced

[Ben Finney]

Joey Hess <[EMAIL PROTECTED]> writes:

> Stefano Zacchiroli wrote:
> > Thanks, my preference is now for XS-Vcs-*
>
> While the name is still in flux, could I suggest XS-Repo-*?
>
> I tend to get VCS and RCS confused :-)

On the other hand, "repo" is ambiguous and doesn't necessarily suggest
"repository of a version control system"; it could be a repository of
*anything* related to the project.

I'm -1 on "repo", +1 on "vcs". (And those are worth dog biscuits
because IANADD :-)

-- 
 \  "People demand freedom of speech to make up for the freedom of |
  `\thought which they avoid."  -- Soren Aabye Kierkegaard |
_o__)  (1813-1855) |
Ben Finney


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

Re: Media players in Debian

[Andrew Donnellan]

On 9/24/06, Russ Allbery <[EMAIL PROTECTED]> wrote:

In other words, the fastest way to get legal issues with mplayer clarified
would be for someone who cared specifically about getting mplayer into
Debian putting together a list of the specific questions that need to be
resolved before Debian can take the package, and then go to upstream
(probably doing research in the mailing list first) and develop answers to
those questions.  Unfortunately, the hard part in the past has been
getting clarity on that first point.  It's not at all clear to me that
anyone really *knows* what issues need to be resolved before Debian can
take the package.  You'd probably have to do something like put together a
list of the questions that you think need to be resolved and then see if
one of the ftp-masters would be willing to read that over and see if it
includes everything they were concerned about.


That's definitely the issue - no-one really knows all the issues.
There have been endless flamewars over this...

Perhaps someone could make a list of relevant d-l discussions and then
get someone to read through it and make a list of the main points and
check on their progress (not me; i'm too busy.)

--
Andrew Donnellan
http://andrewdonnellan.com
http://ajdlinux.blogspot.com
Jabber - [EMAIL PROTECTED]
GPG - hkp://subkeys.pgp.net 0x5D4C0C58
---
Member of Linux Australia - http://linux.org.au
Debian user - http://debian.org
Get free rewards - http://ezyrewards.com/?id=23484
OpenNIC user - http://www.opennic.unrated.net


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

RFH: tpctl/thinkpad-source

[martin f krafft]

Dear collagues,

when I took over the thinkpad package from Thomas Hood, I did not
know that mdadm and hibernate were going to keep me *that much*
occupied. It turns out that I found no time to work on the thinkpad
package, despite all my great plans for it. It does not look like
I'll find the time between now and "etch" either.

It is thus that I solicit help for the package. Basically, the
packaging needs an update to support module-assistant, and a new
upstream version has been released. There is also a small number of
bugs (http://bugs.debian.org/tpctl).

The packages (actually, two of them: tpctl and thinkpad) are
maintained in SVN right now:

  http://svn.debian.org/wsvn/pkg-tpctl/thinkpad/trunk?op=dir
  svn://svn.debian.org/pkg-tpctl/thinkpad/trunk
  svn+ssh://svn.debian.org/svn/pkg-tpctl/thinkpad/trunk

  http://svn.debian.org/wsvn/pkg-tpctl/tpctl/trunk?op=dir
  svn://svn.debian.org/pkg-tpctl/tpctl/trunk
  svn+ssh://svn.debian.org/svn/pkg-tpctl/tpctl/trunk

If you can dedicate some time to it to get it ready for etch, please
do so. Ping me and I'll give you SVN access ASAP, and use svk in
between.

Cheers,

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"literature always anticipates life.
 it does not copy it, but moulds it to its purpose.
 the nineteenth century, as we know it,
 is largely an invention of balzac."
-- oscar wilde


signature.asc
Description: Digital signature (GPG/PGP)

Re: XS-X-Vcs-XXX field not (yet) announced

[Stefano Zacchiroli]

On Sat, Sep 23, 2006 at 05:20:01PM -0500, Manoj Srivastava wrote:
> Before we go on statndardizing it and writing coed to make
>  part of of infrastructure do stuff with it, can we have a clear idea
>  of the semantics of the field?
> 
> As I currently understand it, the format is
> XS-VCS-XXX: $TAG:${URL}
> 
> Isn't XXX duplicating the effect of $TAG? And what meaning is

No, because the format is parsed as

  XS-VCS-XXX: ${URL}

$TAG is not distinguished, it's the scheme of URL. In svn it *can* be
svn://. For other vcs it does not necessarily match the tag of the vcs:

  [EMAIL PROTECTED]:~$ apt-cache showsrc amule | grep -i vcs
  X-Vcs-Bzr: http://people.debian.org/~adeodato/code/packages/amule

>  ascribed to the $URL? Is it something that shall show up in PTS
>  pages, and points to a web page that details how to get the sources?

The proposed meaning is: a URL meaningful for the given VCS so that a
user seeing it is able to find the source code.

> If the ${URL}  part is supposed to have enough informnation
>  for automated downloads, then I  POSIT that a single URL may not be
>  enough; and this should be documented (only specific VCS layouts are
>  amenable to a single-url-contains enough information to download the
>  package sources).

Ok, we should document it.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Re: XS-X-Vcs-XXX field not (yet) announced

[Stefano Zacchiroli]

On Sun, Sep 24, 2006 at 01:42:25AM +0200, Stefano Zacchiroli wrote:
> The proposed meaning is: a URL meaningful for the given VCS so that a
> user seeing it is able to find the source code.

Sorry, I should have said more on this. That was the original intended
meaning (to me), listening to Joey suggestions though I think it would
be good to be able to automatically download stuff or browse source code
too.

So, for vcs/layouts where this is possible it should be document which
is the preferred url to be but there so that it's possible, maybe with a
best practice. For other vcs/layouts the value of the field in my mind
should be what I said above: something meaningful for a user so that he
can find the source code.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Results for Constitutional Amendment GR: Handling assets for the project

[devotee]

Greetings,

This message is an automated, unofficial publication of vote results.
 Official results shall follow, sent in by the vote taker, namely
Debian Project Secretary

This email is just a convenience for the impatient.
 I remain, gentle folks,

Your humble servant,
Devotee (on behalf of Debian Project Secretary)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Starting results calculation at Sun Sep 24 00:00:18 2006

Option 1 "Amend the constitution  [needs 3:1]"
Option 2 "Further Discussion"

In the following table, tally[row x][col y] represents the votes that
option x received over option y.

  Option
  1 2 
===   === 
Option 1  242 
Option 2 23   



Looking at row 2, column 1, Further Discussion
received 23 votes over Amend the constitution  [needs 3:1]

Looking at row 1, column 2, Amend the constitution  [needs 3:1]
received 242 votes over Further Discussion.

Option 1 Reached quorum: 242 > 47.4341649025257


Option 1 passes Majority.  10.522 (242/23) > 3


  Option 1 defeats Option 2 by ( 242 -   23) =  219 votes.


The Schwartz Set contains:
 Option 1 "Amend the constitution  [needs 3:1]"



-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The winners are:
 Option 1 "Amend the constitution  [needs 3:1]"

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

-- 
The voters have spoken, the bastards... --unknown
DEbian VOTe EnginE
digraph Results {
  ranksep=0.25;
 "Amend the constitution  [needs 3:1]\n10.52" [ style="filled" , 
color="powderblue", shape=egg, fontcolor="Navy Blue", fontname="Helvetica", 
fontsize=10  ];
 "Amend the constitution  [needs 3:1]\n10.52" -> "Further Discussion" [ 
label="219" ];
 "Further Discussion" [ style="filled" , shape=diamond, fontcolor="Red", 
fontname="Helvetica", fontsize=10  ];
}


pgpHONActKXr4.pgp
Description: PGP signature

Re: Compatibility between Debian amd64 and other distributions

[Daniel Jacobowitz]

On Sat, Sep 23, 2006 at 05:40:42PM +0200, Goswin von Brederlow wrote:
> So what you seem to say is: If you copy the libc6 or static libraries
> between distributions you deserve to fail. Thats fine if you say it
> straight out.

That's what I was trying to do!

> Does the same apply to libX11. Or can we do the compile for lib64, use
> lib trick there as it is not frozen?

I don't think it matters, but it's up to the X maintainers.

-- 
Daniel Jacobowitz
CodeSourcery


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

Re: Mass bug filing for debconf "abuse" by using low|medium priority debconf notes

[Christian Perrier]

Quoting Christian Perrier ([EMAIL PROTECTED]):
> As explained in
> http://lists.debian.org/debian-devel/2006/09/msg00438.html, I plan a
> mass bug filing for packages using debconf "notes" templates and
> display them at low or medium priorities.


135 bug reports have been files on Saturday Sept. 23rd morning
(UTC). Some of these were filed on Friday 22nd, as a final test of the
MBF process.

This mass bug filing is listed on
http://wiki.debian.org/I18n/BTSActions, as this action is considered
to be an action from the Debian i18n task force, one of the first
consequences of the i18n Extremadura meeting (translators are the
first people annoyed by useless, and often very long, notes which they
have to translate without knowing if their translations will be of
some use).






signature.asc
Description: Digital signature