Re: Any reason why libmotif3 vanished for Sparc

[Andreas Tille]

On Mon, 29 Aug 2005, Andreas Metzler wrote:


I know that it was there formerly because I once got it without any extra
lines in my sources.list file.  Now the Sparc port can be found at



   http://ftp.unixdev.net/pub/debian-udev/pool/non-free/o/openmotif/


This is a version with security issues.


Thanks for the hint.


libmotif3 is non-free and not-autobuilt, it requires somebody with


I'm aware of this and I could offer building the package on my Sparc machine,
but ...


access to a sparc machine to build it manually. Sadly this seems to be
made difficult by a FTBFS on sparc, http://bugs.debian.org/323798


... I'm not skilled enough to fix this. :-(

(I put debian-sparc in CC - perhaps this increases the audience.)

Kind regards

 Andreas.

--
http://fam-tille.de


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

Re: Any reason why libmotif3 vanished for Sparc

[Petter Reinholdtsen]

[Andreas Tille]
> ... I'm not skilled enough to fix this. :-(

Try using lesstif instead.  It is a motif clone.  I recommend
installing lesstif2-dev instead of the motif development package, and
try again.


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

Bug#325671: ITP: psignifit -- Fitting and testing hypotheses about psychometric functions

[Michael Hanke]

Package: wnpp
Severity: wishlist
Owner: Michael Hanke <[EMAIL PROTECTED]>


* Package name: psignifit
  Version : 2.5.6
  Upstream Author : Jeremy Hill <[EMAIL PROTECTED]>
* URL : http://www.bootstrap-software.org/psignifit
* License : GPL
  Description : Fitting and testing hypotheses about psychometric functions

Psignifit allows fitting of psychometric functions to datasets while
maintaining full control over a large number of parameters. Data 
can either be read from text files or passed through a pipe.
..
Psignifit performs the calculation of confidence intervals as well as
goodness-of-fit tests.
..
This is the command line version.
..
Psignifit was written be Jeremy Hill.
..
See http://www.bootstrap-software.org for more information.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)
Kernel: Linux 2.6.8-11-amd64-k8
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: Interest in packaging GNU Shishi and GNU Generic Security Service?

[Simon Josefsson]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Simon Josefsson <[EMAIL PROTECTED]> writes:
>
>> Hi.  I'd like to get in contact with someone who would be interested in
>> creating and supporting Debian packages for my Kerberos 5
>> implementation, and its related GSS-API library.  Web pages are
>> available at:
>
>> http://www.gnu.org/software/shishi/
>> http://www.gnu.org/software/gss/
>
>> Shishi and GSS can be used by GNU SASL, GNU Mailutils, Fetchmail, Curl
>> and maybe other projects.
>
> I *might* be interested in this, although I'm fairly busy at the moment.
> But I certainly have a strong interest in good Kerberos implementations
> and have a lot of experience with the existing packages.
>
> I'd be very interested in making sure that it can co-exist with MIT
> Kerberos on the same system, since I can't really switch away from MIT
> Kerberos for my own personal use, but I'd want to have it installed to be
> able to easily test.
>
> Certainly, if multiple people are interested in working on this, I'd be
> glad to be part of a maintainer team.

Having you as a co-maintainer would be great.

I expect the initial packaging to be simple, it is just a './configure
&& make install' package.  Part of the 'make install' procedure should
be duplicated in the apt install scripts, for the KDC side, but that
part is not important.  I think it is more important to simply get the
library and binaries packaged.  How to better co-exist with MIT and
Heimdal is something that will need to be figured out along the way.

If there is interest in the idea, improving the GSS library to be able
to dlopen the MIT or Heimdal GSS libraries is an idea I have been
playing with.  Then Debian packages (like gsasl, fetchmail, curl,
mailutils, etc, that support GSS) would only have to be linked with
GNU GSS, and the user can, during run-time through a configuration
file, decide which actual implementation should be used.  GNU GSS
would then merely be a shim between MIT, Heimdal or Shishi.  Then
enabling GSS in more packages would be simpler, without having a
strong dependency on just one of MIT, Heimdal or Shishi.

Thanks,
Simon


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

Re: Any reason why libmotif3 vanished for Sparc

[Andreas Tille]

On Tue, 30 Aug 2005, Petter Reinholdtsen wrote:


Try using lesstif instead.  It is a motif clone.  I recommend
installing lesstif2-dev instead of the motif development package, and
try again.

I tried and failed - but thanks for the hint.

And before you ask: I failed to find a reasonable bug report to the
lesstif authors, because the failure was hard to describe and only
reproducable in the quite complex program arb, which is just missing
several controls in the GUI under some circumstances.  So it compiles
fine with lesstif but I can't bother our users to find out why they are
not able to manage the GUI.

Kind regards and thanks for the hint anyway

   Andreas.

--
http://fam-tille.de


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

Re: Unnecessary "Conflicts" with imap-server packages

[Brian May]

> "Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes:

Hamish> These problems should be solved by discussion and
Hamish> generation of a policy. IMHO it would be better to have a
Hamish> consistent approach that didn't solve every problem (or
Hamish> had some other flaw) than to have each individual
Hamish> developer generate their own scheme.

I agree.

Would it be feasible to have something like "update-alternatives", but
instead of managing files in the file system, it allocates port
numbers?

That way every service that listens on port, for example 143, will be
registered, but only one will be "active" at one time.

When a service is activated, then this means installing the inetd line
if it is an inetd based daemon or activating an /etc/init.d/* script
(by renaming the appropriate links) and starting it.

When a service is deactivated, the reverse happens.

Or perhaps a running some configurable script for each
activation/deactivation might be better, that way a package could
request deactivation mean "remove listen config option on this
port". Might be useful for packages like apache which can (and
sometimes do) listen on other ports.
-- 
Brian May <[EMAIL PROTECTED]>


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

Bug#325696: ITP: arno-iptables-firewall -- Single- and multi-homed firewall script with DSL/ADSL support

[Michael Hanke]

Package: wnpp
Severity: wishlist
Owner: Michael Hanke <[EMAIL PROTECTED]>


* Package name: arno-iptables-firewall
  Version : 1.8.4
  Upstream Author : Arno van Amersfoort <[EMAIL PROTECTED]>
* URL : http://rocky.eld.leidenuniv.nl/
* License : GPL
  Description : Single- and multi-homed firewall script with DSL/ADSL 
support

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (x86_64)
Kernel: Linux 2.6.8-11-amd64-k8
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: Version tracking in the BTS

[Frans Pop]

On Monday 29 August 2005 21:59, Anthony Towns wrote:
> On Mon, Aug 29, 2005 at 08:50:24PM +0200, Frans Pop wrote:
> > Also I don't think that "Patched" as a description for tag 'patch' is
> > correct. The bug has not been patched, there just is a _proposed_
> > patch available. There is no certainty that the patch is either
> > correct or will be accepted by the maintainer.
>
> If it's known to be incorrect or the maintainer's not going to accept
> it, the patch tag isn't appropriate:
>
> A patch or some other easy procedure for fixing the bug is included
> in the bug logs. If there's a patch, but it doesn't resolve the bug
> adequately or causes some other problems, this tag should not be
> used.

Thanks for the clarification. The reality however is that a lot of patches 
(of varying quality) are submitted to the BTS by others than the 
maintainer and may linger for quite a while before they are properly 
reviewed by the maintainer.
Having those bugs classified as "patched" IMO gives the wrong impression 
to casual readers (read non-developers) as it indicates that the problem 
has already been fixed.
I personally read "patched" as synonymous to "patch has been applied", 
which is just not true.

In an perfect world a maintainer would review each patch as it is 
submitted and remove the tag if the patch is not good. Reality is 
different, although I hope the recent enhancements to the BTS may help to 
get it used better.


pgpytY0uVH2HB.pgp
Description: PGP signature

Re: Bug#325696: ITP: arno-iptables-firewall -- Single- and multi-homed firewall script with DSL/ADSL support

[Andreas Tille]

On Tue, 30 Aug 2005, Michael Hanke wrote:


Package: wnpp
Severity: wishlist
Owner: Michael Hanke <[EMAIL PROTECTED]>


* Package name: arno-iptables-firewall
 Version : 1.8.4
 Upstream Author : Arno van Amersfoort <[EMAIL PROTECTED]>
* URL : http://rocky.eld.leidenuniv.nl/
* License : GPL
 Description : Single- and multi-homed firewall script with DSL/ADSL support


Please add the long description.


From an other posting I know that you are seeking for a sponsor.  If I were

you I would mention this at this place. ;-)

Kind regards

Andreas.
--
http://fam-tille.de


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

Bug#325703: ITP: libpod-index-perl -- Index and search PODs using X<> entries.

[Florian Ragwitz]

Package: wnpp
Severity: wishlist
Owner: Florian Ragwitz <[EMAIL PROTECTED]>

* Package name: libpod-index-perl
  Version : 0.12
  Upstream Author : Ivan Tubert-Brohman <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~itub/Pod-Index/
* License : Perl (Artistic/GPL)
  Description : Index and search PODs using X<> entries.

The Pod-Index distribution includes various modules for indexing and
searching POD that is appropriately marked with X<> POD codes.
.
The little-known (or at least little-used) X<> formatting code is described in
perlpod:
.
  "X" -- an index entry
This is ignored by most formatters, but some may use it for build-
ing indexes.  It always renders as empty-string.  Example: "X"

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: Version tracking in the BTS

[Hamish Moffatt]

On Tue, Aug 30, 2005 at 05:59:17AM +1000, Anthony Towns wrote:
> The idea is that a maintainer can divide bugs by the actions needed:
> 
> * patch: apply the patch, build, test, upload
> * moreinfo: no action -- waiting for more info
> * wontfix: no action -- won't fix anyway
> * unclassified: reproduce, analyse, come up with solutions
> * confirmed: analyse, come up with solutions
> 
> Bugs tagged "help", "unreproducible", and "upstream" aren't separated
> out from unclassified at the moment; maybe "confirmed" shouldn't be
> split from unclassified.

IMHO it's useful to split out confirmed. For packages with large bug
lists, splitting confirmed from still-be-to-be-analysed reports is
a big improvement.

thanks,
Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: a place for a package directory in root

[Steve Langasek]

On Mon, Aug 29, 2005 at 09:25:22PM +0100, Roger Leigh wrote:
> sean finney <[EMAIL PROTECTED]> writes:

> > On Sun, Aug 28, 2005 at 09:26:16PM +0100, Roger Leigh wrote:
> >> sean finney <[EMAIL PROTECTED]> writes:

> >> Some packages chose to place random junk in there (e.g. resolvconf).
> >> This is wrong.  This location is for (and *only* for) file-backed
> >> shared memory storage, otherwise there is potential for namespace
> >> clashes, and it's totally disgusting.

> >> The fact that it's useful for other things should be an indication
> >> that we need another tmpfs mount, mounted elsewhere, rather than
> >> abusing a location intended for a specific, unrelated, use.

> > so it's a choice between abusing a pre-existing location but standards
> > specified for another use, or using a non-existing location with no
> > standards whatsover.  can't say i really like either option.  more
> > specifically because both are not addressed in policy/fhs, i'd be worried
> > about an in-flow of non-standard, first-come-first-serve namespace
> > usage.

> In this case, it looks like we should standardise on something like
> /run.  Has this been brought up with the FHS/LSB folks?  This sounds
> like something other distributions will also need to tackle, so if it
> gets standardised, so much the better.

It has not; I had intended to do so, but there was some resistance to
teh idea on debian-devel and the use cases disappeared into /dev/shm, so
I occupied myself with other things.

-- 
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/


signature.asc
Description: Digital signature

Re: Bug#325696: ITP: arno-iptables-firewall -- Single- and multi-homed firewall script with DSL/ADSL support

[Michael Hanke]

Am Dienstag, 30. August 2005 11:36 schrieb Andreas Tille:
> On Tue, 30 Aug 2005, Michael Hanke wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Michael Hanke <[EMAIL PROTECTED]>
> >
> >
> > * Package name: arno-iptables-firewall
> >  Version : 1.8.4
> >  Upstream Author : Arno van Amersfoort <[EMAIL PROTECTED]>
> > * URL : http://rocky.eld.leidenuniv.nl/
> > * License : GPL
> >  Description : Single- and multi-homed firewall script with DSL/ADSL
> > support
>
> Please add the long description.

 This is a firewall configuration script which is extremly easy to 
 understand and can be setup in a few minutes. Some features are:
  * Very secure stateful filtering firewall
  * Both kernel 2.4 & 2.6 support
  * It can be used for both single- and multi(eg. dual)-homed boxes
  * Masquerading (NAT) and SNAT support
  * Multiple external (internet) interfaces
  * Support multiroute NAT & SNAT (load balancing over multiple (internet)
interfaces)
  * Port forwarding (NAT)
  * Support MAC address filtering
  * Support for DSL/ADSL modems
  * Support for PPPoE, PPPoA and bridging modem setups
  * Support for static and ISP assigned (DHCP) IPs
  * Support for (transparent) proxies
  * Full support for DMZ's and DMZ-2-LAN forwarding. You can also use
it to isolate your eg. wireless LAN
  * (Nmap)(stealth) portscan detection
  * Protection against SYN-flooding (DoS attacks)
  * Protection against ICMP-flooding (DoS attacks)
  * Extensive user-definable logging with rate limiting to prevent log
flooding
  * Includes options to optimize your throughput
  * User definable open ports, closed ports, trusted hosts, blocked 
hosts etc.
  * Log & protection options are both highly customizable
  * Support for custom iptables rules in a separate file
  * Main focus on TCP/UDP/ICMP but additional support for *ALL* 
IP protocols
  * It works with Freeswan IPSEC (VPN) & SSH Sentinel 
(http://www.freeswan.org) (+virtual IP's)
  * It works with PoPTop PPTP (http://www.poptop.org)
  * It works with UPnP
  * DRDOS protection/detection (experimental)
 .
 See the website at http://rocky.eld.leidenuniv.nl/ for more 
 information (including a quickstart guide and the FAQ).

>
> >From an other posting I know that you are seeking for a sponsor.  If I
> > were
>
> you I would mention this at this place. ;-)
>

You're right. I still need a sponsor for this package. I posted a request to 
debian-mentors, but recieved no reply. See
http://lists.debian.org/debian-mentors/2005/08/msg00411.html

I uploaded the current version of the package to http://mentors.debian.net for 
inspection.


Regards,

Michael


-- 
GPG key:  1024D/3144BE0F Michael Hanke
http://apsy.gse.uni-magdeburg.de/hanke
ICQ: 48230050


pgpI0cUTfeg4x.pgp
Description: PGP signature

long long support on all archs?

[Ondrej Sury]

Hi,

does all archs in debian have support for long long datatype?

I want to apply 64bit quotas for cyrus22-imapd and I have to choose
between patch which has checks for long long support and patch which
doesn't have this check and use long long by default.

Ondrej.
-- 
Ondrej Sury <[EMAIL PROTECTED]>


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

Bug#325709: ITP: xmms2 -- XMMS2 is a redesign of the XMMS music player

[Florian Ragwitz]

Package: wnpp
Severity: wishlist
Owner: Florian Ragwitz <[EMAIL PROTECTED]>

* Package name: xmms2
  Version : 2.0.1DR2.1
* URL : xmms2.xmms.org
* License : GPL
  Description : XMMS2 is a redesign of the XMMS music player

XMMS2 is a redesign of the XMMS music player. It features a
client-server model, allowing multiple (even simultaneous!) user
interfaces, both textual and graphical. All common audio formats are
supported using plugins. On top of this, there is a flexible media
library to organize your music.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.2
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: a place for a package directory in root

[Adeodato Simó]

* Joerg Sommer [Mon, 29 Aug 2005 12:51:16 +]:

> > Do it and get enough things to use it. Then there is no stopping you.

> Well, I add /run/ to the directories of my package and mount a tmpfs
> there on startup. But I leave it mounted after exit, because I don't know
> if someone else use it.

> Any objections?

  Only, if you implement this in your package, which is an init
  replacement, what about other packages that may need this in the
  future (or that are currently using /dev/shm when we'd rather they
  didn't)? As the standard init does not mount it, they can't count on
  /run being available, so either they do it themselves, or we get the
  standard init to provide /run as well.

  Thoughts about the latter?

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
A lie can go round the world before the truth has got its boots on.
-- Terry Pratchett


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

Re: long long support on all archs?

[Richard Atterer]

On Tue, Aug 30, 2005 at 01:25:09PM +0200, Ondrej Sury wrote:
> does all archs in debian have support for long long datatype?

Yes, AFAIK, but...

> I want to apply 64bit quotas for cyrus22-imapd and I have to choose
> between patch which has checks for long long support and patch which
> doesn't have this check and use long long by default.

...I recommend you use int64_t from  instead of long long, this
is more portable.

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯


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

Re: arch, svn, cvs

[Martin Langhoff]

On 8/20/05, Florian Weimer <[EMAIL PROTECTED]> wrote:
> > Compared to SVN from the view of somebody who is acquainted with CVS,
> > arch sucks badly. I tend to agree with most of the things that Florian
> > Weimer lists on http://www.enyo.de/fw/software/arch/design-issues.html

To which I'd respond that Arch fills a very different niche, closer to DARCS.

But I'm leaving the Arch (tla/baz/bzr) boat too - patch-oriented SCMs
were fun, but very disappointing. There is a central design flaw in
pure patch tracking, and neither Arch nor DARCS do anything about it:
no matter how much you track patches merged, you need to be able to
identify convergence. GIT does this so well by being
identity-oriented, that you can do a ton of patch trading on top (via
email, StGIT, quilt, whatever) and things still make sense after
merging and remerging ad infinitum.

I'm running my Arch repos through this git-archimport-script:

http://marc.theaimsgroup.com/?l=git&m=112539589428505&w=2

cheers,


martin

Re: Unnecessary "Conflicts" with imap-server packages

[Stig Sandbeck Mathisen]

On Aug 30, 2005, at 10:31, Brian May wrote:


Would it be feasible to have something like "update-alternatives", but
instead of managing files in the file system, it allocates port
numbers?

That way every service that listens on port, for example 143, will be
registered, but only one will be "active" at one time.


Please bear in mind that a single computer also can have a lot of IP  
addresses.  For example, I can have apache2 on one address, and squid  
reverse proxy on another, both listening on the same port.


--
SSM - Stig Sandbeck Mathisen <[EMAIL PROTECTED]> - http://fnord.no
 Trust the Computer, the Computer is your Friend


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

Re: arch, svn, cvs

[martin f krafft]

also sprach Martin Langhoff <[EMAIL PROTECTED]> [2005.08.30.1404 +0200]:
> But I'm leaving the Arch (tla/baz/bzr) boat too - patch-oriented SCMs
> were fun, but very disappointing. There is a central design flaw in
> pure patch tracking, and neither Arch nor DARCS do anything about it:
> no matter how much you track patches merged, you need to be able to
> identify convergence. GIT does this so well by being
> identity-oriented, that you can do a ton of patch trading on top (via
> email, StGIT, quilt, whatever) and things still make sense after
> merging and remerging ad infinitum.

How does git aide you in identifying the differences in changes
between two trees?

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
micro$oft windoze: proof that p. t. barnum was correct.


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

Re: long long support on all archs?

[Henrique de Moraes Holschuh]

On Tue, 30 Aug 2005, Richard Atterer wrote:
> On Tue, Aug 30, 2005 at 01:25:09PM +0200, Ondrej Sury wrote:
> > does all archs in debian have support for long long datatype?
> 
> Yes, AFAIK, but...
> 
> > I want to apply 64bit quotas for cyrus22-imapd and I have to choose
> > between patch which has checks for long long support and patch which
> > doesn't have this check and use long long by default.
> 
> ...I recommend you use int64_t from  instead of long long, this
> is more portable.

Well, if you do, please submit a patch upstream to switch all such usage in
cyrus accordingly.  I feel it would be easier to just add the proper
autoconf tests and bang out with an error (unsupported architecture) if long
long is not available or less than signed 64-bits (i.e. 63 bits) wide.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: Documentation of alioth?

[Branden Robinson / Debian Project Leader]

On Mon, Aug 29, 2005 at 06:56:56PM +0200, Raphaël Hertzog wrote:
> Le lundi 29 août 2005 à 11:42 -0500, Branden Robinson / Debian Project
> Leader a écrit :
> > Eh?  What exactly did I say?
> 
>  wiggy: if anyone from d-a is responding to any of the offers
> they're getting, they're not CCing me.
>  And we all know how much good it will do if I cheerfully
> accept hardware that d-a refuses to touch.

Oh, that.  :)

> > > It looks like the actual problem is more lack of donors and the fact
> > > that Branden is not willing to spend money on it.
> > 
> > Actually, I was contacted just very recently by a potential hardware donor
> > that should have some pretty reasonable iron at its disposal.
> > 
> > I don't rule out cash expenditures on hardware in general, but when we're
> > seeking entire machines, I'd rather exhaust donation opportunties first.
> 
> I have no problem with that but we should also avoid waiting for ever
> when the donor doesn't come.
> 
> I hope the issue will be solved until the end of the year. :-)

It's not my intention to wait *that* long.  I know of several outstanding
offers of hardware.  Not all may be a perfect fit, but I'd be surprised if
all of them were unsatisfactory.

-- 
G. Branden Robinson
Debian Project Leader
[EMAIL PROTECTED]
http://people.debian.org/~branden/


signature.asc
Description: Digital signature

Re: Unnecessary "Conflicts" with imap-server packages

[Daniel Burrows]

On Tuesday 30 August 2005 04:49 am, Stig Sandbeck Mathisen wrote:
> On Aug 30, 2005, at 10:31, Brian May wrote:
> > Would it be feasible to have something like "update-alternatives", but
> > instead of managing files in the file system, it allocates port
> > numbers?
> >
> > That way every service that listens on port, for example 143, will be
> > registered, but only one will be "active" at one time.
>
> Please bear in mind that a single computer also can have a lot of IP  
> addresses.  For example, I can have apache2 on one address, and squid  
> reverse proxy on another, both listening on the same port.

  As I understand Brian's idea, this would just be a way of allowing daemons 
to cohabitat in their default configuration.  The administrator would be free 
to override the defaults in any way he wanted.

  Daniel

-- 
/--- Daniel Burrows <[EMAIL PROTECTED]> --\
|   "But what *does* kill me bloody well leaves me dead!"   |
| -- Terry Pratchett, _Carpe Jugulum_   |
\ The Turtle Moves! -- http://www.lspace.org ---/


pgpZ3FCMUuyJI.pgp
Description: PGP signature

Re: Interest in packaging GNU Shishi and GNU Generic Security Service?

[J. Bruce Fields]

On Tue, Aug 30, 2005 at 09:32:58AM +0200, Simon Josefsson wrote:
> I expect the initial packaging to be simple, it is just a './configure
> && make install' package.  Part of the 'make install' procedure should
> be duplicated in the apt install scripts, for the KDC side, but that
> part is not important.  I think it is more important to simply get the
> library and binaries packaged.  How to better co-exist with MIT and
> Heimdal is something that will need to be figured out along the way.
> 
> If there is interest in the idea, improving the GSS library to be able
> to dlopen the MIT or Heimdal GSS libraries is an idea I have been
> playing with.  Then Debian packages (like gsasl, fetchmail, curl,
> mailutils, etc, that support GSS) would only have to be linked with
> GNU GSS, and the user can, during run-time through a configuration
> file, decide which actual implementation should be used.  GNU GSS
> would then merely be a shim between MIT, Heimdal or Shishi.  Then
> enabling GSS in more packages would be simpler, without having a
> strong dependency on just one of MIT, Heimdal or Shishi.

Have you looked at the libgssapi package at
http://www.citi.umich.edu/projects/nfsv4/linux/ ?

Currently we're just using this for the NFS rpcsec_gss implementation,
but we split it out into a separate library thinking it might be used as
you describe above.

--b.


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

Re: More pbuilder use!

[Manoj Srivastava]

On Wed, 24 Aug 2005 06:15:08 +1000, Paul TBBle Hampson <[EMAIL PROTECTED]> 
said: 

> On Tue, Aug 23, 2005 at 01:52:22PM -0300, Humberto Massa Guimarães wrote:
>> ** Bastian Blank ::

>>> You have a linux kernel ready, which allows chroot as normal user?
>>> Please share it with us.
>> It's called QEMU :-)

> Or pbuilder-uml, once someone gets onto the user-mode-linunx package
> (and kernel-patch-uml) and brings them back into shape so that the
> pbuilder-uml package can be re-enabled.

I build in SELinux UML's.  And, since kernel-package now
 supports building uml images, there is no need to have a single
 user-mode-linux package -- you can have multiple linux-uml packages
 of different versions installed.

Someone just needs to change thepbuilder-uml dependencies to
 accept kernel-uml packages instead.

manoj
-- 
America, how can I write a holy litany in your silly mood? Allen
Ginsberg
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: Is dpkg --compare-versions canonical?

[Manoj Srivastava]

On Tue, 23 Aug 2005 23:03:05 +0200, Andreas Barth <[EMAIL PROTECTED]> said: 

> * Russ Allbery ([EMAIL PROTECTED]) [050823 22:58]:
>> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>> > It is out of date since it does not explain ~ yet. Maybe, if you
>> > have the time and since you just looked at the matter closely
>> > anyway, you could draw up a few lines and send a patch?

>> I'm certainly willing to do so, but I thought that policy wasn't
>> ready to change yet.  Wasn't it waiting on implementation of that
>> feature in dak, which is currently using ~ internally for something
>> else?

> There is no reason to not update policy right now, as long as we add
> a footnote that ~ cannot be used in uploads until dak is fixed.

There is no tearing hurry to modify policy either. I would
 rather not add provisions into policy that are not yet useable, and
 add a temporal footnote preventing that use.This is just another case
 of innovations getting ahead of policy, and then policy changes to
 reflect reality.

manoj
-- 
UNIX is hot.  It's more than hot.  It's steaming.  It's quicksilver
lightning with a laserbeam kicker.  -- Michael Jay Tucker
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: Interest in packaging GNU Shishi and GNU Generic Security Service?

[Russ Allbery]

Simon Josefsson <[EMAIL PROTECTED]> writes:

> Having you as a co-maintainer would be great.

> I expect the initial packaging to be simple, it is just a './configure
> && make install' package.  Part of the 'make install' procedure should
> be duplicated in the apt install scripts, for the KDC side, but that
> part is not important.  I think it is more important to simply get the
> library and binaries packaged.  How to better co-exist with MIT and
> Heimdal is something that will need to be figured out along the way.

There is an open bug against MIT Kerberos (#213316) asking that it use the
alternatives system.  Originally this was for Java packages, which
thankfully have stopped using alternatives to manage their broken version
of kinit, but it's still appealing to coexist with Heimdal.  I don't want
to add it only in MIT Kerberos, but if the Heimdal folks are also
interested, I think it would be worthwhile.

I don't know if Shishi conflicts with any binary names in Heimdal or MIT
Kerberos; I haven't checked yet.  If so, alternatives looks even more
appealing.

The dev packages for Heimdal and MIT Kerberos conflict and that can't
really be fixed.  Whether Shishi would also conflict is an interesting
question.  I expect that the GSSAPI dev package would.

Are you implementing the same API as MIT Kerberos, the same API as
Heimdal, or something else yet again?

> If there is interest in the idea, improving the GSS library to be able
> to dlopen the MIT or Heimdal GSS libraries is an idea I have been
> playing with.  Then Debian packages (like gsasl, fetchmail, curl,
> mailutils, etc, that support GSS) would only have to be linked with GNU
> GSS, and the user can, during run-time through a configuration file,
> decide which actual implementation should be used.  GNU GSS would then
> merely be a shim between MIT, Heimdal or Shishi.  Then enabling GSS in
> more packages would be simpler, without having a strong dependency on
> just one of MIT, Heimdal or Shishi.

Cyrus SASL is a particularly interesting case, since lots and lots of
things depend on it.  (gsasl hasn't gotten much penetration yet, so far as
I know.)

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: Interest in packaging GNU Shishi and GNU Generic Security Service?

[Russ Allbery]

J Bruce Fields <[EMAIL PROTECTED]> writes:

> Have you looked at the libgssapi package at
> http://www.citi.umich.edu/projects/nfsv4/linux/ ?

> Currently we're just using this for the NFS rpcsec_gss implementation,
> but we split it out into a separate library thinking it might be used as
> you describe above.

Does the NFS v4 userland work with MIT Kerberos 1.4?  (I have 1.4.2
packages nearly done, and am just waiting on glibc to unblock the world so
that the current security fix in sid can get into etch for m68k before I
upload a major new version.)

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: Version tracking in the BTS

[Russ Allbery]

Frans Pop <[EMAIL PROTECTED]> writes:

> Having those bugs classified as "patched" IMO gives the wrong impression
> to casual readers (read non-developers) as it indicates that the problem
> has already been fixed.

> I personally read "patched" as synonymous to "patch has been applied",
> which is just not true.

Something like "patch available" would sound a lot better to me than
"patched," although it's longer.  That's then still true even if the patch
is bad and just hasn't been triaged yet.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: Version tracking in the BTS

[Russ Allbery]

Hamish Moffatt <[EMAIL PROTECTED]> writes:

> IMHO it's useful to split out confirmed. For packages with large bug
> lists, splitting confirmed from still-be-to-be-analysed reports is a big
> improvement.

I think the new classification is very useful for packages with lots of
bugs.  It makes the bug list much more manageable.  Thank you!

Unfortunately, for a package with a moderate number of bugs (10-30), it
adds a lot of clutter without a lot of clarity.  Because of that, it would
be great if there were some option down in the settings section that would
let one turn off this section splitting again.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

Re: arch, svn, cvs

[George Danchev]

On Tuesday 30 August 2005 15:32, martin f krafft wrote:
> also sprach Martin Langhoff <[EMAIL PROTECTED]> [2005.08.30.1404 
+0200]:
> > But I'm leaving the Arch (tla/baz/bzr) boat too - patch-oriented SCMs
> > were fun, but very disappointing. There is a central design flaw in
> > pure patch tracking, and neither Arch nor DARCS do anything about it:
> > no matter how much you track patches merged, you need to be able to
> > identify convergence. GIT does this so well by being
> > identity-oriented, that you can do a ton of patch trading on top (via
> > email, StGIT, quilt, whatever) and things still make sense after
> > merging and remerging ad infinitum.
>
> How does git aide you in identifying the differences in changes
> between two trees?

You can have any other's work as different branches (also as separate local 
repositories and just diff between), then use a nice graphical tool 'gitk 
--all' to show you both of these branches and their histories (well the 
lowlevel 'git-diff-*' tools are called which you can use manually), then try 
to merge using 'git resolve b1 b2' [1]. Here is a more advanced example of 
merging [2] as well as seeing whatchanged and where. Merging is the man here.

[1] http://www.kernel.org/pub/software/scm/git/docs/tutorial.html
[2] 
http://www.kernel.org/pub/software/scm/git/docs/howto/using-topic-branches.txt

-- 
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: Interest in packaging GNU Shishi and GNU Generic Security Service?

[Simon Josefsson]

"J. Bruce Fields" <[EMAIL PROTECTED]> writes:

> On Tue, Aug 30, 2005 at 09:32:58AM +0200, Simon Josefsson wrote:
>> I expect the initial packaging to be simple, it is just a './configure
>> && make install' package.  Part of the 'make install' procedure should
>> be duplicated in the apt install scripts, for the KDC side, but that
>> part is not important.  I think it is more important to simply get the
>> library and binaries packaged.  How to better co-exist with MIT and
>> Heimdal is something that will need to be figured out along the way.
>> 
>> If there is interest in the idea, improving the GSS library to be able
>> to dlopen the MIT or Heimdal GSS libraries is an idea I have been
>> playing with.  Then Debian packages (like gsasl, fetchmail, curl,
>> mailutils, etc, that support GSS) would only have to be linked with
>> GNU GSS, and the user can, during run-time through a configuration
>> file, decide which actual implementation should be used.  GNU GSS
>> would then merely be a shim between MIT, Heimdal or Shishi.  Then
>> enabling GSS in more packages would be simpler, without having a
>> strong dependency on just one of MIT, Heimdal or Shishi.
>
> Have you looked at the libgssapi package at
> http://www.citi.umich.edu/projects/nfsv4/linux/ ?
>
> Currently we're just using this for the NFS rpcsec_gss implementation,
> but we split it out into a separate library thinking it might be used as
> you describe above.

I've seen it now, although it wasn't available when I created my GSS
implementation back in 2003.  Certainly co-operation would be good,
and it looks like we have similar goals.  But GSS is a GNU project so
it would require the normal copyright assignment procedure.

Thanks,
Simon


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

Re: Interest in packaging GNU Shishi and GNU Generic Security Service?

[Simon Josefsson]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Simon Josefsson <[EMAIL PROTECTED]> writes:
>
>> Having you as a co-maintainer would be great.
>
>> I expect the initial packaging to be simple, it is just a './configure
>> && make install' package.  Part of the 'make install' procedure should
>> be duplicated in the apt install scripts, for the KDC side, but that
>> part is not important.  I think it is more important to simply get the
>> library and binaries packaged.  How to better co-exist with MIT and
>> Heimdal is something that will need to be figured out along the way.
>
> There is an open bug against MIT Kerberos (#213316) asking that it use the
> alternatives system.  Originally this was for Java packages, which
> thankfully have stopped using alternatives to manage their broken version
> of kinit, but it's still appealing to coexist with Heimdal.  I don't want
> to add it only in MIT Kerberos, but if the Heimdal folks are also
> interested, I think it would be worthwhile.
>
> I don't know if Shishi conflicts with any binary names in Heimdal or MIT
> Kerberos; I haven't checked yet.  If so, alternatives looks even more
> appealing.
>
> The dev packages for Heimdal and MIT Kerberos conflict and that can't
> really be fixed.  Whether Shishi would also conflict is an interesting
> question.  I expect that the GSSAPI dev package would.
>
> Are you implementing the same API as MIT Kerberos, the same API as
> Heimdal, or something else yet again?

Shishi can co-exist with either of MIT or Heimdal.  It doesn't use a
similar API at all.  The library has a clean name space (shishi_*).
The tools doesn't conflict with any (to me) known tools.

I don't think the GSSAPI dev package would conflict; it places header
files in $prefix/include/gss/ and the library is called libgss to
avoid conflicting.  However, as it implement the standard GSS API, the
namespace do conflict, so you can't link directly to more than one
GSS-library at the same time.

I'm carefully avoiding conflicting with any existing Kerberos
implementation, but I'm considering adding functions to read the
MIT/Heimdal configuration file, to simplify things for the user.  I'm
not sure more compatibility than that is useful.

Thanks,
Simon


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

Re: Version tracking in the BTS

[Javier Fernández-Sanguino Peña]

On Tue, Aug 30, 2005 at 10:45:47AM -0700, Russ Allbery wrote:
> Frans Pop <[EMAIL PROTECTED]> writes:
> 
> > Having those bugs classified as "patched" IMO gives the wrong impression
> > to casual readers (read non-developers) as it indicates that the problem
> > has already been fixed.
> 
> > I personally read "patched" as synonymous to "patch has been applied",
> > which is just not true.
> 
> Something like "patch available" would sound a lot better to me than
> "patched," although it's longer.  That's then still true even if the patch
> is bad and just hasn't been triaged yet.

Shorter: "with patch" (which could be moved to "with good patch" if the tag
+patch and +confirmed where used? "patched" looks more like it should be used
when +patch and +pending have been used)

Regards

Javier


signature.asc
Description: Digital signature

Re: Bug#325709: ITP: xmms2 -- XMMS2 is a redesign of the XMMS music player

[Peter Samuelson]

[Florian Ragwitz]
> XMMS2 is a redesign of the XMMS music player. It features a
> client-server model, allowing multiple (even simultaneous!) user
> interfaces, both textual and graphical.

Gee, and Beep Media Player is going through a similar redesign.  Once
that's finished and packaged, we'll have four xmmses.


signature.asc
Description: Digital signature

Re: Version tracking in the BTS

[martin f krafft]

also sprach Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> [2005.08.30.2111 
+0200]:
> Shorter: "with patch" (which could be moved to "with good patch" if the tag
> +patch and +confirmed where used?

Confirmed is a tag used when the maintainer can reproduce the bug,
not when the patch is confirmed.

> "patched" looks more like it should be used when +patch and
> +pending have been used)

Pending makes no suggestion whether the patch was used, or another
solution found.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"the 'volatile' keyword
 is implemented syntactically
 but not semantically"
  -- documentation of m$ visual c, around 1992


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

Re: Version tracking in the BTS

[Helmut Wollmersdorfer]

Frans Pop wrote:

On Monday 29 August 2005 21:59, Anthony Towns wrote:



On Mon, Aug 29, 2005 at 08:50:24PM +0200, Frans Pop wrote:



   A patch or some other easy procedure for fixing the bug is included
   in the bug logs. If there's a patch, but it doesn't resolve the bug
   adequately or causes some other problems, this tag should not be
   used.

[...]
In an perfect world a maintainer would review each patch as it is 
submitted and remove the tag if the patch is not good. 


In common sense a patch is a proposed solution for a bug, independent 
from the author (bug submitter, maintainer, upstream or somebody else).


Each sort of proposed solution needs an approval (e.g. regression test), 
if it removes the bug. If not, the bug cannot be closed as 'solved'. 
Thus I do not understand, why to remove the 'patch' tag.


Helmut Wollmersdorfer


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

Re: arch, svn, cvs

[Robert Collins]

On Wed, 2005-08-31 at 00:04 +1200, Martin Langhoff wrote:
> On 8/20/05, Florian Weimer <[EMAIL PROTECTED]> wrote:
> > > Compared to SVN from the view of somebody who is acquainted with CVS,
> > > arch sucks badly. I tend to agree with most of the things that Florian
> > > Weimer lists on http://www.enyo.de/fw/software/arch/design-issues.html
> 
> To which I'd respond that Arch fills a very different niche, closer to DARCS.
> 
> But I'm leaving the Arch (tla/baz/bzr) boat too - patch-oriented SCMs
> were fun, but very disappointing. There is a central design flaw in
> pure patch tracking, and neither Arch nor DARCS do anything about it:
> no matter how much you track patches merged, you need to be able to
> identify convergence. GIT does this so well by being
> identity-oriented, that you can do a ton of patch trading on top (via
> email, StGIT, quilt, whatever) and things still make sense after
> merging and remerging ad infinitum.

for the record, to avoid other folk getting confused - bzr isn't a
'patch orientated SCM'. bzr's design incorporates elements from all of
the VCS systems around when the project was started (and updated since
then) - its not derived from GNU Arch any more or less than its derived
from monotone or subversion.

Cheers,
Rob

-- 
GPG key available at: .


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

Re: arch, svn, cvs

[Martin Langhoff]

On 8/31/05, George Danchev <[EMAIL PROTECTED]> wrote:
> > How does git aide you in identifying the differences in changes
> > between two trees?

George's got it right. In practice, I normally use gitk --all, or use
cogito thus:

   cg-log -r onebranch:otherbranch 
   cg-diff -r onebranch:otherbranch

Another interesting trick is that you can use git-format-script
onebranch otherbranch and it'll export each patch as an email
(separate files or mbox file) with commit msg and diff. Nothing
earth-shattering, but quite useful.

When you send these, and they get applied, git internals recognize it.
If it was changed when it was being applied, it'll conflict as you'd
expect.

cheers,


martin

Re: arch, svn, cvs

[martin f krafft]

also sprach Robert Collins <[EMAIL PROTECTED]> [2005.08.30.2346 +0200]:
> for the record, to avoid other folk getting confused - bzr isn't
> a 'patch orientated SCM'. bzr's design incorporates elements from
> all of the VCS systems around when the project was started (and
> updated since then) - its not derived from GNU Arch any more or
> less than its derived from monotone or subversion.

Could you please elaborate on this?

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"perhaps debian is concerned more about technical excellence rather
 than ease of use by breaking software. in the former we may excel.
 in the latter we have to concede the field to microsoft. guess
 where i want to go today?"
 -- manoj srivastava


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

Re: Version tracking in the BTS

[Russ Allbery]

Helmut Wollmersdorfer <[EMAIL PROTECTED]> writes:
> Frans Pop wrote:

>> In an perfect world a maintainer would review each patch as it is
>> submitted and remove the tag if the patch is not good.

> In common sense a patch is a proposed solution for a bug, independent
> from the author (bug submitter, maintainer, upstream or somebody else).

> Each sort of proposed solution needs an approval (e.g. regression test),
> if it removes the bug. If not, the bug cannot be closed as
> 'solved'. Thus I do not understand, why to remove the 'patch' tag.

Because if a bug is tagged with patch, other people looking over the bug
logs and wanting to be helpful (like me) will skip over the bug on the
assumption that it's already being dealt with.  So if the maintainer isn't
happy with the solution, they should remove the patch tag so that others
know that no solution has yet been found.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


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

mesag3 <-> xlibmesa-gl / libgl1-mesa-dri <-> xlibmesa-dri / libglu1-mesa <-> libglu1-xorg

[Michael Biebl]

Hi all,

It seems that mesa (6.3.2) as well as xorg (6.8.2) both provide a GL/GLU
implemetation. IIRC the xorg GL/GLU code is based on (older) mesa code.
Why this duplication of code and which of this two implementations is
the preferred one? Could I replace the xorg packages with the mesa
packages without ill effects resp. without loss of functionality?
I noticed that Ubuntu renamed mesag3->libglu1-mesa and
xlibmesa-gl->libgl1-xorg. Is this an attempt to smooth the transition
from the xorg packages to the mesa ones and in the course of the X
modularisation to get completely rid of the GL/GLU code in xorg (and the
libgl*-xorg packages) and use mesa directly as an external library?
If there is such a transition how will it take place?

Could someone with a deeper insight enlighten me?

Cheers,
Michael
-- 

E-Mail: [EMAIL PROTECTED]
WWW: http://www.teco.edu/

TecO (Telecooperation Office) Vincenz-Priessnitz-Str.1
University of Karlsruhe 76131 Karlsruhe, Germany



signature.asc
Description: OpenPGP digital signature

Re: Version tracking in the BTS

[Thomas Bushnell BSG]

martin f krafft <[EMAIL PROTECTED]> writes:

> also sprach Thomas Bushnell BSG <[EMAIL PROTECTED]> [2005.08.30.0729 +0200]:
>> How about adding documentation to the bugs.debian.org webpage?
>
> How about a patch? Writing the documentation yourself has the added
> benefit that you won't need it in the future anymore.

1) That's not true: I'll forget.  Writing it doesn't mean I won't
   forget it.

2) I don't know all the changes that have been made. 

3) There is a bad habit of making announcements on the announcement
   mailing list by people who skip the *more* important job of keeping
   the actual documentation up to day.

4) I'm busy trying to do my own job, rather than managing others' too.

The bugs.debian.org changes are superb and wonderful.  But you can't
chide someone for not knowing about them when the documentation isn't
up to day.


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

FTPmasters (again)

[Thomas Bushnell BSG]

So the FTP masters always get fought with these long flame wars (you
all know the ones I need).  Sadly, threads with titles about the FTP
masters are usually obnoxious flames.

Well, they worked hard to get sarge out, cleared up a big backlog, and
did all kinds of other wonderful stuff.

I recently had a NEW package, and it went through in a short time,
without any problems, and all indications are that NEW queue handling
has been speedy and efficient.

The ftp.debian.org bug entry is short, and things there are processed
speedily and efficiently.

And amidst it all, Anthony Towns got credit for having done lots of
the work with the new bugs.debian.org.

So, to the FTP masters, kudos, thanks, and woo hoo!

Thomas


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

Re: arch, svn, cvs

[Martin Langhoff]

On 8/31/05, Robert Collins <[EMAIL PROTECTED]> wrote:
> for the record, to avoid other folk getting confused - bzr isn't a
> 'patch orientated SCM'. bzr's design incorporates elements from all of
> the VCS systems around when the project was started (and updated since
> then) - its not derived from GNU Arch any more or less than its derived
> from monotone or subversion.

Fair enough... except that it is being promised as the natural upgrade
path for tla/baz users. I don't claim to understand the architectural
decisions in bzr, but it is a pretty serious constraint. It forces bzr
to support the core assumptions of the Arch model.

cheers,


martin

Re: Bug#325709: ITP: xmms2 -- XMMS2 is a redesign of the XMMS music player

[Laszlo Boszormenyi]

On Tue, 2005-08-30 at 14:31 -0500, Peter Samuelson wrote:
> [Florian Ragwitz]
> > XMMS2 is a redesign of the XMMS music player. It features a
> > client-server model, allowing multiple (even simultaneous!) user
> > interfaces, both textual and graphical.
> 
> Gee, and Beep Media Player is going through a similar redesign.
 Me wonder. What? Where? Google...

>   Once
> that's finished and packaged, we'll have four xmmses.
 I think old ones can be dropped after a while with transitional
packages.

Cheers,
Laszlo/GCS


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

Re: arch, svn, cvs

[Robert Collins]

On Wed, 2005-08-31 at 15:25 +1200, Martin Langhoff wrote:
> On 8/31/05, Robert Collins <[EMAIL PROTECTED]> wrote:
> > for the record, to avoid other folk getting confused - bzr isn't a
> > 'patch orientated SCM'. bzr's design incorporates elements from all of
> > the VCS systems around when the project was started (and updated since
> > then) - its not derived from GNU Arch any more or less than its derived
> > from monotone or subversion.
> 
> Fair enough... except that it is being promised as the natural upgrade
> path for tla/baz users. I don't claim to understand the architectural
> decisions in bzr, but it is a pretty serious constraint. It forces bzr
> to support the core assumptions of the Arch model.

Not at all. I'll reply to madduck with more stuff on the design
internals tomorrow. But as for being forced to support the core
assumptions of the arch model - bah.

bzr will support upgrades by converting the data from the arch archives
to individual bzr branches. These branches are not able to be converted
back to Arch archives - its a one way trapdoor. The presence of the
trapdoor is what lets Bazaar-NG not support the core assumptions of the
Arch model.

Aaron Bentley has already written a baz2bzr tool and I'll be knocking
the edges of that in the next month and a half.

Rob

-- 
GPG key available at: .


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

Re: Re: Which CD is a package on?

[Filipus Klutiero]

While I was going to add this to #debian's "cd contents" factoid, which 
used to also only mention jigdo, I noticed that someone had added an 
effective solution.


(00:58:29) *cheal:* cd contents
(00:58:29) *dpkg:* To find out what is on what cd, download the .jigdo 
template, and zless fooimage.jigdo. In the [Parts] section you will see 
the list of packages that are contained in the cd. stew has created a 
searchable index of the sarge cds: http://vireo.org/~stew/jigdo 



stew is a regular on #debian. I just tested the interface quickly, and 
it's not bad. While the interface doesn't point to the code used, I 
guess he would accept to give anyone his code if asked by email. Perhaps 
a DD will want to use the code instead of starting from scratch.
In any case, I think work on this issue would have a high use/effort 
ratio ;)

It will be great if building an index can be part of the CD build process.


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

Re: Interest in packaging GNU Shishi and GNU Generic Security Service?

[Steve Langasek]

On Tue, Aug 30, 2005 at 08:01:41PM +0200, Simon Josefsson wrote:
> Shishi can co-exist with either of MIT or Heimdal.  It doesn't use a
> similar API at all.  The library has a clean name space (shishi_*).
> The tools doesn't conflict with any (to me) known tools.

> I don't think the GSSAPI dev package would conflict; it places header
> files in $prefix/include/gss/ and the library is called libgss to
> avoid conflicting.  However, as it implement the standard GSS API, the
> namespace do conflict, so you can't link directly to more than one
> GSS-library at the same time.

Please add support for ELF symbol versioning, so that the usual
namespace problems can be avoided.

I notice from

that this lib is distributed under the terms of the GPL only, so I have
my doubts that it's particularly useful for Debian to adopt it.  Is
there any particular reason that GNU shishi is not made available under
the LGPL?

-- 
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/


signature.asc
Description: Digital signature