Pozdrav!

[Robert]

Imate priliku da zaradite na internetu - ali stvarno. Definitivno najbolji 
nacini da zardite pomocu ovog neverovatnog medija.

Pogledajte i dajte mi samo 10 sekundi sanse...

www.e-goldbusiness.eu

Da li cete iskoristiti ovu fenomenalnu priliku u zivotu ili ne, zavis samo od 
Vas.


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

Pozdrav!

[Robert]

Imate priliku da zaradite na internetu - ali stvarno. Definitivno najbolji 
nacini da zardite pomocu ovog neverovatnog medija.

Pogledajte i dajte mi samo 10 sekundi sanse...

www.e-goldbusiness.eu

Da li cete iskoristiti ovu fenomenalnu priliku u zivotu ili ne, zavis samo od 
Vas.


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

Bug#775123: (no subject)

[Robert]

Subject: general: Thinkpad will not wake since Debian 7.8 upgrade, must hard 
boot computer.
Package: general
Severity: important

Dear Maintainer,

 What led up to the situation? I upgraded to Deb 7.8 during normal update
 What exactly did you do (or not do) that was effective (or
 ineffective)? Have to reboot to use computer.


-- System Information:
Debian Release: 7.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2015091935.4649.8958.reportbug@debian

Re: an idea for next generation APT archive caching

[Robert Collins]

On Sat, 2004-10-23 at 12:57 -0500, Manoj Srivastava wrote:
> On Fri, 22 Oct 2004 23:04:32 -0700, Matt Zimmerman <[EMAIL PROTECTED]> said: 
> 
> > On Wed, Oct 20, 2004 at 02:11:44AM +0200, martin f krafft wrote:
> >> Here's an idea I just had about apt-proxy/apt-cacher NG. Maybe this
> >> could be interesting, maybe it's just crap. Your call.
> 
> > My position on special-purpose proxy caches for APT is that
> > general-purpose proxy caches (like squid) seem to work fine for me.
> > What advantages do they have for others?
> 
>   Optimization?  With a special purpose proxies I can control
>  how the cache gets updated. For example, I want to keep two versions
>  of packages I use around -- the current, and the previous one, no
>  matter how old. Hard to do with Squid, which does not know these two
>  files ar4e different versi9ons of the same package. 

It can be taught that. A custom cache replacement policy, for one cache
dir, for example.

Rob

-- 
GPG key available at: .


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

Bug#279551: ITP: zsync -- A client-side implementation of the rsync algorithm

[Robert Lemmen]

Package: wnpp
Severity: wishlist

* Package name: zsync
  Version : 0.0.4
  Upstream Author : Colin Phipps <[EMAIL PROTECTED]>
* URL : http://zsync.moria.org.uk/
* License : GPLv2
  Description : A client-side implementation of the rsync algorithm

 This package allows updating of files from a remote web server without 
 requiring a full download or a special remote server application.

the description will be a bit more elaborate, talking it over with 
upstream. there will also be a libzsync and a libzsync-dev package to
use it in other programs (apt for example ;)

cu  robert

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.9
Locale: LANG=C, [EMAIL PROTECTED]

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Re: Synching mirrors and clients (was: Re: apt-proxy v2 and rsync)

[Robert Lemmen]

On Thu, Nov 04, 2004 at 06:35:40PM +0100, Kurt Roeckx wrote:
> > Now if you feel advantous, repack as many package on the source mirror
> > with gzip --rsyncable and notice the difference.
> 
> Exactly how is this going to help?  I can only see this as being
> useful when the files change.  Files should never change.  You
> get a completly new file.  Unless you can somehow tell to use the
> old file as base, this is not going to help.

there was a patch by paul russell floating around to build a heuristic 
into rsync to allow it to figure out from the name which file might be 
similar and use this as the file to sync against. this should work 
pretty fine for debian packages, especially with --rsyncable

cu  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Bug#281002: ITP: gpib -- kernel modules, libraries and language bindings for GPIB (IEEE 488) hardware

[Robert Jordens]

Package: wnpp
Severity: wishlist

  Package name: gpib
  Version : 3.2.01
  Upstream Author : Frank Mori Hess <[EMAIL PROTECTED]> et al.
  URL : http://linux-gpib.sourceforge.net/
  License : GPL
  Description : kernel modules, libraries and language bindings for GPIB 
(IEEE 488) hardware

The Linux GPIB Package is a support package for GPIB (IEEE 488)
hardware. The package contains kernel driver modules, and a C user-space
library with Guile, Perl, PHP, Python and TCL bindings. The API of the C
library is intended to be compatible with National Instrument's GPIB
library.

The General Purpose Instrumentation Bus (GPIB) is a short-range digital
communications cable standard  connecting electronic test and
measurement devices to control devices. Developed by HP in 1970
(and then called HP-IB) it has been standardized in 1978 by the Institute of
Electrical and Electronics Engineers as the IEEE Standard Digital 
Interface for Programmable Instrumentation, IEEE-488-1978 (now 488.1).

IEEE-488 allows up to 15 intelligent devices to share a single bus by
daisy-chaining, with the slowest device participating in the control and
data transfer handshakes to determine the speed of the transaction. The
maximum data rate is about one megabit per second. Paraphrasing the 1989
HP Test & Measurement Catalog: HP-IB has a party-line structure wherein
all devices on the bus are connected in parallel. The 16 signal lines
within the passive interconnecting HP-IB cable are grouped into three
clusters according to their functions: Data Bus, Data Byte Transfer
Control Bus, and General Interface Management Bus.


-- 
Life is like an egg stain on your chin -- you can lick it, but it still
won't go away.


signature.asc
Description: Digital signature

Re: ITP: lapispuzzle.app -- almost a clone of Street Puzzle Fighter

[Robert Collins]

On Mon, 2004-12-06 at 19:18 +0100, Florian Weimer wrote:
> * Gürkan Sengün:
> 
> > * Package name: lapispuzzle.app
> >   Version : 0.9.1
> >   Upstream Author : Banlu Kemiyatorn <[EMAIL PROTECTED]>
> > * URL : http://home.gna.org/garma/lapispuzzle/index.html
> > * License : GNU GPL
> >   Description : almost a clone of Street Puzzle Fighter
> >  Lapis Puzzle is a game that is almost a clone of Street Puzzle
> >  Fighter (TM). If you can't figure out the rule, press A on start
> >  and learn from machine vs. machine mode. 
> 
> If "Street Puzzle Fighter" is a trademark, you shouldn't use it to
> advertise a competing product.

Why not? Happens all the time.

Rob

-- 
GPG key available at: .


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

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Robert Millan]

On Thu, Dec 02, 2004 at 08:03:42AM +, Helen Faulkner wrote:
> 
> Yes, you are being absurd.  Since you are presumably not understanding the 
> point, let me explain more clearly:
> 
> Pornography is widely regarded as being demeaning and insulting to women.

The female body is beautiful.  Why would drawing/displaying a picture of a
woman be insulting to anyone?

-- 
 .''`.   Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S)
: :' :
`. `'http://www.debian.org/ports/kfreebsd-gnu
  `-

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Robert Millan]

On Tue, Dec 07, 2004 at 01:06:11PM +0900, Clemens Schwaighofer wrote:
> > 
> > True, the Koran just invites to kill your ennemy bloodily, that's very
> > different...
> 
> Thats wrong, thats just an interpretion.

I wonder how could text be written such that the question wether it invites
to kill someone bloodily is open to interpretation.

-- 
 .''`.   Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S)
: :' :
`. `'http://www.debian.org/ports/kfreebsd-gnu
  `-

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Robert Millan]

On Fri, Dec 03, 2004 at 03:45:23AM +0100, Tollef Fog Heen wrote:
> * John Hasler 
> 
> | William Ballard writes:
> | > The Bible should be in Debian.  But the Koran, the Torah, and the Vishnu
> | > texts (name escapes me at the moment) should all be in there too.
> | 
> | Debian is not Project Gutenberg.  Debian is about _software_.
> 
> But the recent GR clarified that data is also software.

To be exact, it stated that we don't care wether data is software, as long as
it's free.

-- 
 .''`.   Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S)
: :' :
`. `'http://www.debian.org/ports/kfreebsd-gnu
  `-

Re: Bug#285681: ITP: libxbox-dev -- Libxbox-dev provides the headers for libxbox0 and the libxbox.so symlink

[Robert Millan]

On Tue, Dec 14, 2004 at 11:49:55PM +, David Pye wrote:
> 
> Ah. So that's what I did wrong, maybe.
> 
> The two packages build from the same source.  Does that mean a single ITP is 
> necessary?  I have not raised ITPs before, so was not sure exactly.

That's it.  With a few rare exceptions (that don't apply here), we file
exactly one ITP per source.

> One question this raises in my mind:
> 
> suppose I have a single source tar.gz, that I want to build into four debian 
> binary packages, with different names (obviously).  If this should require 
> only one ITP, which package name should the ITP be made for?

Debian source packages also have a name.  We normaly use that for the ITP.
For simple 1:1 packages the source name is usualy the same as the binary name,
but that's absolutely not a requisite.

For example, the "xfree86" source package provides a gazillon of binary
packages but there's no "xfree86" binary package as such (And soon won't be
any "xfree86" at all anyway ;).

-- 
 .''`.   Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S)
: :' :
`. `'http://www.debian.org/ports/kfreebsd-gnu
  `-

gaim-dev packages heading to experimental

[Robert McQueen]

I've just uploaded gaim 1:1.1.1-2 to experimental, which introduces a 
new arch-independent gaim-data package containing all of the /usr/share 
stuff, and more interestingly to those who have been waiting and ITPing 
various Gaim plugins, a gaim-dev package containing the includes and .pc 
file necessary to compile them on a Debian system.

The gaim-dev package includes a dh_gaim utility which (thanks to Gaim's 
new upstream versioning policy) plugin maintainers should use to add 
correctly versioned dependencies on the Gaim package. Please read 
/usr/share/doc/gaim-dev/README.Debian.dev for more details on this.

Also appearing for the first time is the gevolution plugin which 
synchronises your Gaim buddy list to your Evolution address book. Huge 
thanks go to my trusty co-maintainer Ari Pollak for doing most of the 
legwork on this split up, and to Tollef Fog Heen for writing the dh_gaim 
utility for us.

While they're being pondered upon by the FTP masters, the source and 
i386 packages are available here:
 deb http://people.debian.org/~robot101/gaim experimental main
 deb-src http://people.debian.org/~robot101/gaim experimental main

If any DDs would like to do builds on other architectures, or publish 
plugin packages which they have produced whilst they await FTP master 
attention, I can also add these to this repository upon request.

Regards,
Rob

Re: RunDinstallHourly

[Robert Lemmen]

On Wed, Jan 05, 2005 at 07:12:34AM -0500, Joey Hess wrote:
> All of the benefits I've thought of from running dinstall more often
> really only apply to unstable package churn issues. Running britney more
> often sounds relatively orthagonal actually, though it does sound useful
> for those annoying transitions.

not really important right now, but anyway: britney's time-complexity in
regards to the number of packages she has to work on is really bad, son
in the long run it might pay off to run britney more often and on a
smaller number of packages each time.

cu  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Re: New stable version after Sarge

[Robert Lemmen]

On Wed, Jan 05, 2005 at 12:30:52PM -0500, Marc Sherman wrote:
> >That makes me wonder.  I know that there are tools like cron-apt that
> >will perform apt-related tasks through cron jobs.  Is there a way to
> >make it (or another tool) download the changelogs and email you any
> >new ones?
> 
> I just filed a wishlist on cron-apt about that same thing this morning:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288763

doesn't apt-listchanges do that?

cu  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Re: Debian mirror scripts

[Robert Lemmen]

On Mon, Feb 14, 2005 at 11:05:56AM +1100, Brian May wrote:
> zsync looks suspiciously like it might have similar patent issues
> which killed the rproxy project.
> 
> Then again I am no expert; Please tell me I am wrong...

i'm not an expert either, but the zsync maintainer and i talked to a lot
of people about this issue. and while you can never be sure about
patents i am very confident that zsync is unproblematic. 

cu  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Moria, as in the Author of

[Robert Koeneke]

Not sure why people are looking for me, but I received an
e-mail containing a conversation thread claiming I am “unreachable”. 
Last I checked I was pretty easy to reach through [EMAIL PROTECTED].

 

Moria is a game I wrote some 20 years ago.  Hard to believe
anyone would still be playing it.  

 

Anyway, if someone is trying to reach me please pass along
my e-mail address.  If you don’t know what this e-mail is about then
perhaps it was a prank on me so delete it.

 

 

RE: Please make Moria free (was: Moria, as in the Author of)

[Robert Koeneke]

Ok, I am working on getting the correct GPL statement put together so this
game on all the games based on it don't have any restrictions to
distribution.  It was never my intention to make it hard to share, just to
make certain my name stayed with the game and future variants of it.

Sheesh, I should have gone into game design I guess.  I had no idea people
were still playing these games.  Did anyone ever add the Moria V5.0 new
features to the game?  Liquids (pools, streams, lava, etc), orbs, and
recipes for building magic weapons?  There were other things but that's the
stuff I remember off-hand.

In case you can't tell, I am no longer a part of the coding community.  I
moved up the corporate chain to the point of all I do is design enterprise
systems; no one lets me touch code anymore.

Enjoy.

Robert Alan Koeneke
Enterprise Architect

-Original Message-
From: Erik Schanze [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 16, 2005 12:15 PM
To: debian-devel@lists.debian.org
Cc: Clint Adams; Jeroen van Wolffelaar; Robert Koeneke; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Please make Moria free (was: Moria, as in the Author of)

Hi all!

Clint Adams <[EMAIL PROTECTED]>:
> > Do you think moria still has a place in Debian? Or do you gather it
> > might be better removed?
>
> A better question is whether Mr. Koeneke is willing to relicense his
> code under a free software license so that moria and angband and
> derivatives can finally be free.
>
That would be nice and increase the chance that anybody adopt the Debian 
package, I think.


Kindly regards,
Erik


-- 
 www.ErikSchanze.de *
 Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB *
  * Linux-Info-Tag in Dresden, am 29. Oktober 2005  *
 Info: http://www.linux-info-tag.de *



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

Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

[Robert Lemmen]

On Mon, Feb 21, 2005 at 07:25:02AM -0600, Peter Samuelson wrote:
> zsync already reaches inside a gzip file and effectively rsyncs the
> uncompressed version.  No reason it couldn't be made a bit smarter so
> as to look inside the components of a .deb ar file.  This being a
> fairly interesting use case for zsync, I expect it's already being
> considered, if not implemented.

at least considered ;)

seriously, if zsync stabilizes (which will take a while) it would
provide us with a way (together with some other stuff) to sync our
mirrors while taking only a fraction of the bandwidth currently needed.
this can't be bad. but it would mean we have to store .zsync files
besides the debs (+ ~1% size) and talk the mirror admins into running an
update script that is way more complex than two-phase rsync and needs a
wee bit more processing power on their side. anyway, it's too early to
speculate about stuff like that...

cu  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Re: NoX idea

[Robert Carboneau]

Joel Aelwyn wrote:
It also looks like /proc/self/cmdline is more universal, if anyone did
need to do something of the sort.
But that's just the process's command line, isn't it? I thought they 
were looking for the kernel command line.

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

Bug#298899: ITP: gourmet -- a recipe manager

[Robert Lemmen]

Package: wnpp
Severity: wishlist
Owner: Robert Lemmen <[EMAIL PROTECTED]>


* Package name: gourmet
  Version : 0.8.0
  Upstream Author : [EMAIL PROTECTED]
* URL : https://sourceforge.net/projects/grecipe-manager/
* License : GPL
  Description : a recipe manager
  
Gourmet Recipe Manager is a recipe-organizer for GNOME that generates
shopping lists and allows rapid searching of recipes. It imports
mealmaster & mastercook files and exports webpages & other formats

short and long description will be reworked together with upstream

cu  robert

-- System Information:
Debian Release: 3.1
  APT prefers experimental
  APT policy: (600, 'experimental'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.11.2
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Bug#299186: RFP: tetribot -- multiserver capable AI bot for tetrinet

[Robert Millan]

Package: wnpp
Severity: wishlist

* Package name: tetribot
  Version : 0.38-rc17
  Upstream Author : Christopher Yeoh, johnathan d., Andrew Quinn
* URL : http://sourceforge.net/projects/tetribot/
* License : GPL
  Description : multiserver capable AI bot for tetrinet

 The Projects aim is to create a 100% autonomous tetrinet client, offering 
 multiserver capabilities, and ao good playground to develop some nice tetris
 ai.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: kfreebsd-i386 (i686)
Kernel: GNU/kFreeBSD 5.3-5
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Robert Millan]

On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote:
> 
> To be eligible for inclusion in the archive at all, even in the
> (unstable-only) SCC archive, ftpmasters have specified the following
> architecture requirements:
> 
> [...]
> 
> - binary packages must be built from the unmodified Debian source
>   (required, among other reasons, for license compliance)

Is this a simple sanity requirement (i.e. no hacked crap being uploaded to the
archive), or does it imply that all packages in base (or base + build-essential)
need to be buildable from unmodified source?

> - the port must demonstrate that they have at least 50 users

How do you demonstrate that?  Via popularity-contest?

Thanks.

-- 
 .''`.   Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S)
: :' :
`. `'http://www.debian.org/ports/kfreebsd-gnu
  `-


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Robert Lemmen]

On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote:
> Therefore, we're planning on not releasing most of the minor architectures
> starting with etch.  They will be released with sarge, with all that
> implies (including security support until sarge is archived), but they
> would no longer be included in testing.
> [...]

i feel very,very bad about this, but perhaps it's what is needed. i have two
*big* concerns though:

- maintainers will start to downgrade or ignore bugs that are
  arch-specififc if that arch is not in "the" archive. we should have at
  least the requirement that a package must be functional in "the"
  archive + scc to be fit for testing (apart from really arch-specific
  packages of course)
- there must be a way for a scc arch to get a stable release. why don't
  we either keep testing for scc archs but not do releases, so the
  porters can do their own stable releases of their arch or have
  per-arch testing? (the latter might lead to a source package explosion
  i think)

cu  robert  

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Robert Millan]

On Mon, Mar 14, 2005 at 11:26:07AM +0100, Andreas Barth wrote:
> * Sven Luther ([EMAIL PROTECTED]) [050314 11:20]:
> > On Mon, Mar 14, 2005 at 10:39:24AM +0100, Robert Millan wrote:
> > > On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote:
> > > > - the port must demonstrate that they have at least 50 users
> 
> > > How do you demonstrate that?  Via popularity-contest?
>  
> > But then, popularity-contest installation per default was dropped for
> > debian-installer rc3, so ...
> 
> We don't say "it needs 50 entries in popularity-contest", but just: 50
> users. How this is demonstrated, may be different. Enough traffic on the
> porter list might also be enough - or enough bug reports coming from
> that arch. Or whatever. I don't expect that to be the blocking critieria
> for any arch.

I believe that kfreebsd-gnu matches all the mentioned requirements [1] except
this one.  There are quite many bug reports for this system (hundreds) but
most of them come from me ;).  If you could be more specific, that'd be much
appreciated.

[1] Of course, we don't have the DD signatures yet, but there are more than 5
DDs working on this so there's no problem collecting them.

-- 
 .''`.   Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S)
: :' :
`. `'http://www.debian.org/ports/kfreebsd-gnu
  `-


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

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Robert Lemmen]

On Mon, Mar 14, 2005 at 11:00:22PM +1100, Hamish Moffatt wrote:
> Ingo, obviously you are pissed off. But really, is there much benefit in
> making *releases* for the SCC architectures? 

yes, there is. because people want it. just like they want stable
releases for i386. the only difference is that there are less people...

if we have to treat some arch as a "second class citizen" in order to
get our releases out in a timely manner, whcih is what the proposers
claim, that's fine with me. but then there must be a way for the people
interested in the port to work towards having a stable and officially
supported release. in the current state i seriously doubt that one could
get a minor architecture, say sh, into the archive again no matter how
much work you spend on it. simply because some people don't want it
there. 

and if this it's needed for timely releases, why is it the only thing
that is said about changes in the release process. if people think that
this is the only thing needed to make our releases work, they are most
probably wrong. 

summing up: if we need the scc in order to make good releases, fine. but
then we also need to make sure that we do the releases and make sure
that an arch can come back.

cu  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Re: Bits (Nybbles?) from the Vancouver release team meeting

[Robert Lemmen]

On Sun, Mar 13, 2005 at 08:45:09PM -0800, Steve Langasek wrote:
> - the Debian System Administrators (DSA) must be willing to support
>   debian.org machine(s) of that architecture
>
> - the Release Team can veto the architecture's inclusion if they have
>   overwhelming concerns regarding the architecture's impact on the
>   release quality or the release cycle length

i find these two rather disturbing, as they don't really say under which
circumstances these decisions should eb made. so i would really like to
hear under which circumstances the DSA people are willing to add a
machine, and what an overwhelming concern on the side of the release
team would be. especially whether "we already have enough architectures"
and "we don't think it's important enough even though it satisfies the
other criteria" are "overwhelming concerns"

cu  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Re: Automated testing - design and interfaces

[Robert Collins]

On Thu, 2005-11-17 at 14:36 -0800, Steve Langasek wrote:
> [let's get this over to a technical list like it was supposed to be ;)]

> > Following your exit status based approach you could add to stanzas
> > something like:
> 
> >   Expected-Status: 0
> 
> > I found the above requirement the very minimum for a test interface.
> > What follows is optional (IMHO).
> 
> FWIW, I don't see that there's a clear advantage to having the test harness
> *expect* non-zero exit values (or non-empty output as you also suggested).
> It may make it easier to write tests by putting more of the logic in the
> test harness, but in exchange it makes it harder to debug a test failure
> because the debugger has to figure out how "correct" and "incorrect" are
> defined for each test, instead of just getting into the meat of seeing why
> the test returned non-zero.  Likewise, expecting successful tests to be
> silent means that you can rely on any output being error output that can be
> used for debugging a test failure.

Right. Splitting it into two bits ...

with respect to exit code, there is generally only one way to succeed,
but many ways to fail. So reserving 0 for 'test succeeded' in ALL cases,
makes writing front ends, or running the tests interactively much
easier. Its certainly possible to provide a $lang function that can
invert the relationship for you, for 'expected failure' results. One of
the things about expected failures is their granularity: is a test
expected to fail because 'file FOO is missing', or because 'something
went wrong'. The former test is best written as an explicit check, where
you invert the sense in the test script. Its best because this means
that when the behaviour of the failing logic alters - for better or
worse - you get flagged by the test that it has changed. Whereas a
handwaving 'somethings broken' style expected failure really does not
help code maintenance at all. So while it can be useful in the test
interface to have an explicit code for 'expected failure', I think it is
actually best to just write the test to catch the precise failure, and
report success. 

As for silence, yes, noise is generally not helpful, although long
running test suites can usefully give *some* feedback (a . per 100 tests
say) to remind people its still running.

Rob

-- 
GPG key available at: .


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

Re: Automated testing - design and interfaces

[Robert Collins]

On Wed, 2005-11-23 at 18:16 +1000, Anthony Towns wrote:
> On Mon, Nov 21, 2005 at 06:22:37PM +, Ian Jackson wrote:
> > > Note that it's often better to have a single script run many tests, so
> > > you probably want to allow tests to pass back some summary information,
> > > or include the last ten lines of its output or similar. Something like:
> > >   foo FAIL:
> > > FAILURE: testcase 231
> > > FAILURE: testcase 289
> > > FAILURE: testcase 314
> > > 3/512 test cases failed
> > This is no good because we want the test environment to be able to
> > tell which tests failed, so the test cases have to be enumerated in
> > the test metadata file.

Replying to two messages here ...
I don't think we have to enumerate the tests in advance. Sure the test
runner needs to be able to identify and [possibly] categorise the tests,
but explicit enumeration is quite orthogonal. A number of python
unittest runners will scan directories and classes for their tests, and
the report from users is consistently that this is easier to use.

> Uh, having to have 1000 scripts, or even just 1000 entries in a metadata
> file, just to run 1000 tests is a showstopper imho. Heck, identifying
> testcases by number mightn't be particularly desirable in some instances,
> if a clearer alternative like, say, "test case failed: add 1, add 2,
> del 1, ch 2" is possible.

A very nice feature in the xUnit world is that tests can be identified
by either their path (inside the language namespace) or by a comment
written by the author. At runtime you can choose which to see. I dont
think we need the ability for runtime selection, but having a heuristic
that works and is overridable would be nice.

I.e. by default you might get
tests/layout/documentation_in_usr_share_doc.sh: PASS

But inside that test you could say:
test_name Documentation is installed in /usr/share/doc

and the output becomes
Documentation is installed in /usr/share/doc: PASS

I've written a project that is somewhat related to this:
http://www.robertcollins.net/unittest/subunit/

Its a python implementation of a cross process test running protocol.
This lets a sub process run 0 to many tests, identify them and provide
pass/fail/error status and traceback or other diagnostics. As the driver
is python its not appropriate here, but I think the basic
protocol/concept might be useful.

> > You can't check that the binary works _when the .deb is installed_
> > without installing it.
> 
> That's okay. You can't check that the binary works _on the user's system_
> without installing it on the user's system either. For Debian's purposes,
> being able to run the tests with minimal setup seems crucial.

Yup


> It would probably be quite useful to be able to write tests like:
> 
>   for mta in exim4 smail sendmail qmail; do
>  install $mta
>  # actual test
>  uninstall $mta
>   done
> 
> too, to ensure that packages that depend on one of a number of packages
> actually work with all of them.

Yes, that would be excellent.

Rob

-- 
GPG key available at: .


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

Re: Alternate proposal for Declassification of debian-private archives

[Robert Collins]

On Thu, 2005-12-01 at 08:32 -0600, Manoj Srivastava wrote:
> Hi,
> 
> 
...
> - the author and other individuals quoted in messages being reviewed
>   will be contacted, and allowed between four and eight weeks
>   to comment;

I think the default behaviour should be to keep the post private, not to
open it up. That is, if the author and other individuals do not reply,
the message is kept hidden.

The primary reason for this is that the existing messages were sent to
debian-private with an expectation of privacy. Folk that have changed
address or become otherwise not-immediately available may still care,
and the principle of least surprise should apply.

We can however change the expectations for new messages being sent to
debian-private, and in 3 years *they* would become public by default.

Rob

-- 
GPG key available at: .


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

Re: Alternate proposal for Declassification of debian-private archives

[Robert Collins]

On Fri, 2005-12-02 at 12:35 +1000, Anthony Towns wrote:
> (Followups to -vote)
> 
> On Fri, Dec 02, 2005 at 08:30:37AM +1100, Robert Collins wrote:
> > The primary reason for this is that the existing messages were sent to
> > debian-private with an expectation of privacy.
> 
> As Matthew pointed out in [0] this expectation of privacy isn't really
> that strong, fundamentally because -private is open to anyone who joins
> Debian, and Debian's open to anyone joining it.
> 
> [0] http://lists.debian.org/debian-vote/2005/11/msg00033.html

Part of beccoming a member is agreeing to uphold the policies of Debian
- such as the privacy of closed lists. (I don't recall exactly where I
read that, but I do recall reading it).

Current population is what 6 Billion?
Active members ~800 ?

I think there is a freaking huge difference between 'anyone who shows
the interest, effort, sanity and reliability needed to pass NM can read
my posts' and 'Jack The Ripper in outer mongolia can read them.'

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.


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

Re: Trying to reach consensus - Yet Another Alternate Proposal to Declassification of debian-private

[Robert Collins]

On Thu, 2005-12-08 at 00:08 +0100, Gaudenz Steinlin wrote:
> On Wed, Dec 07, 2005 at 02:47:07PM -0300, Daniel Ruoso wrote:
> > So, my conclusion is that it would be nice to have two types of
> > publications:
> > 
> > 1) Selected Readers
> > 2) Selected Content
> > 
> > The first type of publication could embrace the entire content of
> > debian-private, but restrictions will be applied for those who want to
> > read, basically, the need of identification of the reader and the
> > agreement to a NDA on the same terms applied to every debian developer
> > about the privacy of the mailing list.
> > 
> 
> One of the main goals of the original GR was to make the archives
> available for research. How will you be able to publish the results 
> of such research if you agreed to an NDA. One of the main principles
> of scientific research is to make your results reproducible by others.  
> This is impossible if you base your research on data which is only
> available under an NDA.

Its quite possible to publish research conducted under an NDA without
compromising that NDA: but one is constrained in the quotes and
disclosure you can make.

As for being reproducible by others, the suggested process for getting
access seems to be so trivial any researcher with access to the internet
will be able to complete it fairly easily. It also is not under onerous
terms (such as MS's kerberos extensions were) so entering into the NDA
should not limit or pose an unreasonable burden on anyone.

Rob

-- 
GPG key available at: .


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

Re: apt PARALLELISM

[Robert Lemmen]

On Wed, Dec 14, 2005 at 01:23:17PM +0100, Martijn van Oosterhout wrote:
> ISTM the easiest would be for apt to lookup the hostname itself and
> treat the single entry as a list of entires, one for each possible
> address the hostname can resolve to. If one fails, try the next.

apt already does that as far as i understand it

cu  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Bug#344417: ITP: freebsd6-buildutils -- Utilities for building FreeBSD 6.x sources

[Robert Millan]

Package: wnpp
Severity: wishlist
Owner: Robert Millan <[EMAIL PROTECTED]>

* Package name: freebsd6-buildutils
  Version : 6.0
* URL : http://www.freebsd.org/
* License : BSD
  Description : Utilities for building FreeBSD 6.x sources

 This package contains the FreeBSD 6.x counterparts of some standard build
 utilities (make, yacc, lex ..)
 .
 They have some specific modifications needed to be able to build FreeBSD 6.x
 sources.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-k7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL 
set to C)


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

Bug#344419: ITP: kfreebsd-6 -- kernel of FreeBSD 6.x

[Robert Millan]

Package: wnpp
Severity: wishlist
Owner: Robert Millan <[EMAIL PROTECTED]>

* Package name: kfreebsd-6
  Version : 6.0
* URL : http://www.freebsd.org/
* License : BSD
  Description : kernel of FreeBSD 6.x

kfreebsd-source-6.0:

  Description: source code for kernel of FreeBSD 6.0 with Debian patches
  This package provides the source code for kernel of FreeBSD 6.0, base of
  a GNU/kFreeBSD system.

Description for the other, kfreebsd-i386-specific binary packages is analogous
to the ones in kfreebsd-5 debian/control file.

Preliminar packages available at svn://svn.debian.org/glibc-bsd/trunk/kfreebsd-6

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-k7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL 
set to C)


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

Re: New make is breaking several packages

[Robert Luberda]

On Tue, 20 Dec 2005, Daniel Schepler wrote:

Hi,

> Yes, a Makefile with
> all:
>   echo 'foo'\
>   'bar'
> 
> will pass to the shell:
> (old make) echo 'foo''bar'
> (new make) echo 'foo'\
> 'bar'
> 
> And both will echo a single word.

Unfortunatelly that's not true: the sarge version of make
prints two words ;( 
Has anybody any other ideas how to write a Makefile that will
work in the same way with both sarge and sid make?

Best Regards,
robert


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

Re: Bug#344417: ITP: freebsd6-buildutils -- Utilities for building FreeBSD 6.x sources

[Robert Millan]

On Tue, Jan 03, 2006 at 12:42:22PM +0100, Josselin Mouette wrote:
> Le jeudi 22 d?cembre 2005 ? 16:51 +0100, Robert Millan a ?crit :
> >  This package contains the FreeBSD 6.x counterparts of some standard build
> >  utilities (make, yacc, lex ..)
> >  .
> >  They have some specific modifications needed to be able to build FreeBSD 
> > 6.x
> >  sources.
> 
> Maybe it's a dumb question, but isn't there a way to patch these tools
> and/or the freebsd sources so that we can build them with the standard
> tools in Debian?

Yes but:

  - In big packages (like kFreeBSD), it's a huge work.
  - Upstream is extremely unlikely to accept patches for that.

-- 
Robert Millan


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

Re: Getting rid of circular dependencies, stage 3

[Robert Lemmen]

On Thu, Jan 12, 2006 at 09:12:27PM +0400, Stepan Golosunov wrote:
> > Looking at them, I fail to see why debconf-i18n has to depend on
> > debconf.
> 
> Because /usr/share/doc/debconf-i18n is a symlink?

perhaps the link should be the other way round. for example the most
common package split would be something like:
foo --depends--> foo-common
if you want one doc dir for it, then of course the real directory has to
be in foo-common, and the link in foo.

cu  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Re: pbuilder: cowdancer/cowbuilder status update

[Robert Collins]

On Fri, 2006-01-13 at 07:27 +0900, Junichi Uekawa wrote:
> Hi,
> 
> This is an update on using userland COW method with pbuilder.
> 
> cowdancer is a tool that allows you to "cp -al" (hardlink) a tree, and
> break the hardlink when a write-open to a file is performed. The
> adventurous part of cowdancer COW implementation is that it's trying
> to do this from within userland only.
> 
> cowbuilder doesn't really exist yet; it's a name for pbuilder ported
> to fully use cowdancer. cowdancer is under development, and Debian
> package exists in unstable. It seems like it's getting nearly there
> with the feature set. With version 0.8, performance is improved
> against a large tree (I profiled against building the kernel), and
> with version 0.9, I fixed a bug which you could not replace /lib/ld.so
> while cowdancer was running.

Are you aware of fl-cow, which is a LD_PRELOAD userspace COW tool ?

Rob

-- 
GPG key available at: .


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

Re: pbuilder: cowdancer/cowbuilder status update

[Robert Collins]

On Fri, 2006-01-13 at 08:42 +0900, Junichi Uekawa wrote:
> Hi,
> 
> > > This is an update on using userland COW method with pbuilder.
> > > 
> > > cowdancer is a tool that allows you to "cp -al" (hardlink) a tree, and
> > > break the hardlink when a write-open to a file is performed. The
> > > adventurous part of cowdancer COW implementation is that it's trying
> > > to do this from within userland only.
> > > 
> > > cowbuilder doesn't really exist yet; it's a name for pbuilder ported
> > > to fully use cowdancer. cowdancer is under development, and Debian
> > > package exists in unstable. It seems like it's getting nearly there
> > > with the feature set. With version 0.8, performance is improved
> > > against a large tree (I profiled against building the kernel), and
> > > with version 0.9, I fixed a bug which you could not replace /lib/ld.so
> > > while cowdancer was running.
> > 
> > Are you aware of fl-cow, which is a LD_PRELOAD userspace COW tool ?
> 
> It seems to be the tool with a same kind of goal. If I knew it
> existed, I might have started from it. However, it only supports
> 'open', so it will have problems when used with pbuilder; for example,
> file permissions are shared between files with same i-nodes.  The
> scope of implementation between the two applications is a bit
> different.
...
> Considering the difference, it might be better to improve desciprtions
> of both packages.
> 
> 
> 
> Another difference I noticed is that fl-cow takes a list of
> directories to protect in FL_COW, and seems to copy files
> unconditionally on 'open'.
> 
> cowdancer caches a list of i-nodes so that it won't try to break
> hardlinks more than once. (cow-shell does this much work).

Nice. I'm not sure both tools need to be in debian. How mature is
cowdancer - can it replace fl-cow at this point? (fl-cows primary use is
to be told 'these paths may contain hardlinked files, please unhardlink
any of them on write').

Rob

-- 
GPG key available at: .


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

Re: [ad-hominem construct deleted]

[Robert Collins]

On Mon, 2006-01-16 at 19:21 -0500, Joey Hess wrote:
> > but I agree with it.  I would also say that Debian's upstreams are, in the
> > same sense, Debian developers. 
> 
> I think that we probably have hundreds of upstreams who would react with
> everything from disbelief to anger if Debian claimed that as a blanket
> statement.

And yet most upstreams can get pretty much arbitrary code into Debian,
just by committing it?. How many DD's read the -entire- diff on major
version upgrades from upstream. And not just read, audit.

Rob

-- 
GPG key available at: .


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

Re: Andrew Suffield

[Robert Collins]

On Wed, 2006-01-18 at 20:44 +, Dallam Wych wrote:
> On Sun, Jan 15, 2006 at 05:09:03PM -0600, Joe Wreschnig wrote:
> > On Sun, 2006-01-15 at 06:28 -0500, sean finney wrote:
> > > On Sun, Jan 15, 2006 at 11:58:51AM +0100, Adrian von Bidder wrote:
> > > > Do you think your constant bitching is funny?  Do you think it achieves 
> > > > anything?
> > > > 
> > > > There are other DDs who are also involved in intense debates and 
> > > > flamewars 
> > > > very often, but you're the only one  where I constantly get the 
> > > > impression 
> > > > that you're just being childish, insulting and annoying for the sake of 
> > > > it.
> > > 
> > > ...says someone who just publicly ostracized a fellow dd
> > > on a public mailing list.  personal opinions of the matter aside,
> > > debian-devel is not the place for ridiculing other developers, no
> > > matter how justified you feel you may be. 
> > > 
> > > please post follow-ups to -private.
> > 
> > I said this on -private, and I'll say it here -- why is it appropriate
> > to be an ass on -private, but not on -devel? It's not appropriate
> > anywhere. That goes for Adrian, and Andrew, and everyone. It also leads
> > to situations like the present, where it looks like we're doing nothing
> > to reprimand offensive behavior, because most conversation is happening
> > on -private, while the original, offensive message is sitting on d-d-a.
> > 
> > If you are upset by how Andrew acted, talk to him rationally, regardless
> > of whether it's public or private.
> > 
> > If you are *very* upset by how Andrew acted, there is an appropriate and
> > agreed-to policy for expelling developers. Roger Leigh has mentioned his
> > interest in seeing this through; contact him.
> > -- 
> > Joe Wreschnig <[EMAIL PROTECTED]>
> 
> I imagine that the ubuntu people, which include those on canonicals
> payroll that are posting to this list, are really finding this kind of discord
> within the Debian community quite comical and amusing.

No more or less comical or amusing than I found it before Canonical was
started. Which is to say, neither comical nor amusing.

Rob

-- 
GPG key available at: .


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

Re: when and why did python(-minimal) become essential?

[Robert Collins]

On Sat, 2006-01-28 at 19:27 +0100, Josselin Mouette wrote:
> Le samedi 28 janvier 2006 à 19:18 +0100, Wouter Verhelst a écrit :
> > > This is only a feature for perl maniacs. A language that requires a
> > > specific coding style is better, because it makes possible for anyone
> > > knowing the language to hack easily python code he doesn't know about.
> > 
> > Hah. A language that does not require a specific coding style is better,
> > because it allows me to work as is the most efficient for me.
> 
> Which is globally counterproductive. When you're in a project, you have
> to deal with the fact other people are working on it as well. That's why
> large projects like Linux or GNOME require a specific coding style for
> their contributions. For python-based projects, this isn't even
> necessary, as most if not all python programmers already use the same
> coding style.



Have a look inside the standard library sometime, if you want to get a
feeling for just how many styles of programming python programmers use. 

Rob

-- 
GPG key available at: .


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

working together - executive career site

[Robert Odhams]

Hello there,
 
I noticed that your site points to an executive career site.

You can generate an additional stream of income for you just by linking 
to another executive career site.

ExecutiveTrumpet is a resume distribution service exclusively for 
($75k+) executives and it provides around $37.60 to you per successful 
referral. We give you a unique link to place on your site and we do the 
rest.

You receive 40% commission. The average amount per transaction is 
$37.60. If you refer just ten visitors who purchase every week the 
amount you will receive per year is $19,552.
 
We convert a lot of executive candidates into buyers of our services as 
we have a results or refund policy, and this of course increases 
commission generated for you.

For more information on generating a stream of income just by linking, 
do take a look at http://www.executivetrumpet.com/partner.htm   

I think that this is a strong opportunity for your company (and ours) 
to increase profits with little effort on your part.

After visiting the site, do email or call me if you have any questions.
 

Thank you and best regards,
 
Robert Odhams
Founder & Marketing Director
 
ExecutiveTrumpet.com
115 East 57th Street
11th Floor
New York, NY 10022
Phone: 212-531-6230
Fax: 212-531-6130


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

Re: Bug#352073: ITP: gerwin -- CASE tool for edit data model

[Robert Lemmen]

On Thu, Feb 09, 2006 at 12:06:25AM -0200, Fernando Ike de Oliveira wrote:
> * Package name: gerwin

please note that gerwin has been renamed to ferret to avoid legal
problems (erwin trademark).

cu  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

ndiswrapper in main (was: Bug#353277: should be in contrib)

[Robert Millan]

On Fri, Feb 17, 2006 at 07:49:10AM -0800, Debian Bug Tracking System wrote:
> On Fri, 2006-02-17 at 11:22 +0100, Robert Millan wrote:
> > Package: ndiswrapper
> > Severity: serious
> > 
> > This package should be in contrib, not main.
> 
> 
> We've had this discussion.  We're not having it again.  Check the lists
> (google for 'ndiswrapper', 'debian', and 'contrib').

I think you mean the discussion started by:

  http://lists.debian.org/debian-devel/2005/01/msg00375.html

After reading it's still not clear to me why ndiswrapper isn't affected by
Policy 2.2.2.

First, I couldn't find any reference to a "GPLed NDIS driver" in ndiswrapper's
website, like Michael Poole asserts:

  http://lists.debian.org/debian-devel/2005/01/msg00381.html

I would tend to agree that if there's at least one non-POC free driver, without
any free, native equivalent, then ndiswrapper is not targetted exclussively at
using non-free software.

However, it seems Goswin has a point, which he didn't explain.  He sent a
message saying that in IRC they reached a different conclussion, and nobody
replied to him:

  http://lists.debian.org/debian-devel/2005/01/msg00963.html

I'm adding CC to Michael, Goswin and debian-devel.

-- 
Robert Millan


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

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Robert Millan]

On Fri, Feb 17, 2006 at 12:40:10PM -0500, Andres Salomon wrote:
> On Fri, 2006-02-17 at 18:00 +0100, Robert Millan wrote:
> [...]
> > 
> > First, I couldn't find any reference to a "GPLed NDIS driver" in 
> > ndiswrapper's
> > website, like Michael Poole asserts:
> > 
> >   http://lists.debian.org/debian-devel/2005/01/msg00381.html
> > 
> 
> I assume he was talking about the CIPE driver; it's linked right from
> the main ndiswrapper page.

I see.  From http://cipe-win32.sourceforge.net/ :

  "CIPE-Win32 is a port of Olaf Titz's CIPE package from Linux to Windows NT."

I think this is the cipe-source package in debian.  If this driver is already
available, there's no much point in using it via ndiswrapper.

Is there any other free ndis driver?

-- 
Robert Millan


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

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Robert Millan]

On Fri, Feb 17, 2006 at 08:14:38PM -0500, Michael Poole wrote:
> 
> Then please work to revise [Removed false premise fallacy]

Last time your argument was that free NDIS drivers exist, so the situation is
analogous to wine.  Nobody bothered to check, but it turns out that only one
free driver exists, and it's pretty pointless since it's a port of something we
already have.

Ok, quoting:

Social Contract:

  "We will never make the system require the use of a non-free component."

Policy:

"2.2.2 The contrib section

[...]
Examples of packages which would be included in contrib are:

*  [...]
*  wrapper packages or other sorts of free accessories for non-free 
programs.
"

> Without something to work on, an assembler is just as useless as
> ndiswrapper.  Which package(s) in main depend on nasm?

You can check that yourself.  I guess a few dozens.

> Why not file a
> bug report against it, demanding that it be moved to contrib?

Because it's free software that processes asm input, and there is a significant
amount of useful, free i386 asm that makes nasm necessary ?

I'll ask again:  Is the purpose of ndiswrapper running non-free drivers?  If it
isn't, show me a free, non-toy, non-POC driver that would prove otherwise.

(That is a rhetorical question.  Lack of any answer will probably help you
understand why contrib exists.)

-- 
Robert Millan


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

Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)

[Robert Millan]

On Sat, Feb 18, 2006 at 12:49:48PM +0100, Wouter Verhelst wrote:
> On Sat, Feb 18, 2006 at 09:40:26AM +0100, Robert Millan wrote:
> > I'll ask again:  Is the purpose of ndiswrapper running non-free drivers?  
> > If it
> > isn't, show me a free, non-toy, non-POC driver that would prove otherwise.
> 
> Does the lack of a free driver which can be used with ndiswrapper mean
> that it is impossible to use ndiswrapper with such a free driver, should
> one eventually be written?

You can apply this argument to every single package in contrib.  

  "If a free driver/datafile/whatever existed, it would be possible to run Foo
  without requiring non-free stuff, therefore it belongs to main"

Is your point that contrib should therefore be empty and has no reason for
existance?

If not, please explain me the difference between ndiswrapper and all the other
packages that belong to contrib and already are in.

-- 
Robert Millan


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

Re: Bug#353277: ndiswrapper in main

[Robert Millan]

On Sat, Feb 18, 2006 at 05:36:37PM +0100, Mike Hommey wrote:
> On Sat, Feb 18, 2006 at 05:04:54PM +0100, Goswin von Brederlow
> > The availability to do this is enough even if there are other
> > (possibly better) ways to do the same. One free driver _in_ Debian and
> > the package should stay in main.
> > 
> > But does the cipe-source build or ship the windows driver for use with
> > ndiswraper? I doubt that.
> > 
> > Which means you need some software (even if it is free) from outside
> > Debian for ndiswraper. That makes it contrib imho.
> 
> Are there any free MSWord files in main ? No ? Then please move
> antiword and similar tools to contrib.

You're turning this into non-sense.  An NDIS wrapper is OBVIOUSLY for the
exclussive purpose of using non-free Windows drivers.  It is so obvious
because nobody has written [1] free GPLed NDIS drivers.  EVER.  It has nothing
to do with Wine and MSWord [2].

So, stop throwing unrelated points to this matter.  Just fix the bug.  Move this
to contrib, with all the other warez wrappers.

[1] Written, not ported.  I know someone ported that CIPE thing from Linux to
Windows, but the sole idea of porting something to Windows in order to emulate
it from Linux makes me laugh.

-- 
Robert Millan


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

Re: Bug#353277: ndiswrapper in main

[Robert Millan]

On Sat, Feb 18, 2006 at 05:17:11PM +, Brett Parker wrote:
> On Sat, Feb 18, 2006 at 05:36:37PM +0100, Mike Hommey wrote:
> > On Sat, Feb 18, 2006 at 05:04:54PM +0100, Goswin von Brederlow
> > > The availability to do this is enough even if there are other
> > > (possibly better) ways to do the same. One free driver _in_ Debian and
> > > the package should stay in main.
> > > 
> > > But does the cipe-source build or ship the windows driver for use with
> > > ndiswraper? I doubt that.
> > > 
> > > Which means you need some software (even if it is free) from outside
> > > Debian for ndiswraper. That makes it contrib imho.
> > 
> > Are there any free MSWord files in main ? No ? Then please move
> > antiword and similar tools to contrib.
> 
> *points at abiword and openoffice.org*

$ apt-file search ".doc" | grep "\.doc\(\|\.gz\)" | wc -l

Nevertheless, if you think abiword and openoffice.org should be moved then go
for it.  Just don't use them as excuse to turn warez wrappers into "generic"
driver interfaces.

-- 
Robert Millan


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

Re: Bug#353277: ndiswrapper in main

[Robert Millan]

On Sun, Feb 19, 2006 at 01:45:24PM -0500, Andres Salomon wrote:
> > Please also stop insulting ndiswrapper users and developers by calling
> > it a "warez wrapper".

Actualy, since such "ndis drivers" are often provided with very restrictive
licensing, or with no licensing at all, I have my doubts that inserting them
into Linux kernel is a legal activity.

This is of no concern to Debian though, but makes the name "warez" very
appropiate.

-- 
Robert Millan


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

Re: Bug#353277: ndiswrapper in main

[Robert Millan]

reopen 353278
reassign 353278 tech-ctte
reopen 353277
reassign 353277 tech-ctte
merge 353278 353277
thanks

Hi,

I requested that ndiswrapper and ndiswrapper-modules-i386 be moved to contrib.

My reasons are:

  - The sole purpose of these packages is allowing the use of non-free Windows
  drivers.

  - There are no free Windows drivers for this interface, except a port of a
  Linux driver to Windows (cipe), which is only used on native Windows
  platform (since it is pointless to emulate it from Linux, where the original
  cipe is already available).

The maintainer refuses to move it unless you rule a formal decision or a
consensus is reached.  I think the latter is impossible, and therefore I ask you
to consider the issue.

Thank you.

On Sun, Feb 19, 2006 at 01:45:24PM -0500, Andres Salomon wrote:
> On Sun, 2006-02-19 at 11:34 +0100, Marco d'Itri wrote:
> > On Feb 19, Robert Millan <[EMAIL PROTECTED]> wrote:
> > 
> > > Nevertheless, if you think abiword and openoffice.org should be moved 
> > > then go
> > > for it.  Just don't use them as excuse to turn warez wrappers into 
> > > "generic"
> > > driver interfaces.
> > No excuses are needed, the definition of contrib is enough and
> > ndiswrapper has been uploaded to main using the same criteria which have
> > been used in the past for emulators. Stop rewriting history.
> > Please also stop insulting ndiswrapper users and developers by calling
> > it a "warez wrapper".
> > 
> 
> And for fuck's sake, stop filling up my inbox w/ this crap.  I'm not
> doing a thing unless either a) you people come to a consensus on the
> issue (which you have not in the past threads, and probably never will),
> or b) a governing body like the ctte tells me that it should be in
> contrib.  Otherwise, it's staying right where it is.  Honestly, I could
> care less whether it's in contrib or main, but it was a decision that
> was made long ago, and I see no reason to make the change.

-- 
Robert Millan


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

Re: PROPOSAL: debian/control file to include new License: field

[Robert Collins]

On Tue, 2006-02-21 at 03:54 -0500, Kevin Mark wrote:
> On Tue, Feb 21, 2006 at 02:35:52AM -0600, Peter Samuelson wrote:
> > 
> > [Kevin Mark]
> > > would it provide any automation or easier processing for the NEW
> > > queue(ftpmasters)?
> > 
> > I doubt it.  They don't take the maintainer's word for stuff like that,
> > as I understand it - they double-check the copyright and license
> > declarations in the source code.
> You mean they check ever single time $RANDOM_PACKAGE enter NEW and don't
> assume its correct until someone raises an objections? 

Yes. Legal compliance is /not/ tractable in the same way that software
bugs are.

Rob

-- 
GPG key available at: .


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

Re: New packages.debian.org

[Robert Lemmen]

On Mon, Mar 06, 2006 at 06:29:29PM +0100, Martin Schulze wrote:
> The Debian project happily announces the re-availability of the
> packages.debian.org service on a new machine.  The system has been
> [...]


really cool and thanks to schlund and partner, but the links to the
changelogs and the copyright file at the bottom of each packages page
don't work. probbaly just something really minor...

cu  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Re: Ethernet Card Driver

[Robert Stone]

On Sun, 21 Dec 1997, Sinisa Pajevic wrote:
: 
: I have installed debian linux on my PC (Pentium, MMX) and it works, but I
: am not able to use my network card. I have EtherExpress Pro/100 PCI card
: and I have used your driver for this card (Intel EtherExpress Pro 100). 
: However, the driver was written for the processor i82557 while my
: processor is i82865. I am assuming that this is causing problems and would
: like to know if there is a driver available for this processor, or any
: other version later than i82557 that might be compatible with it.
:  
try the driver at http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
I've had to use that driver exclusively with the eepro100 pci cards here.

thanks,
    Robert


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

netcat update & intentions

[Robert Woodcock]

After getting in touch with Michael Shields <[EMAIL PROTECTED]>, the
current maintainer of netcat, I've decided to make a non-maintainer
release of netcat with the version 1.10-3.1. It should let us close all
the distribution-specific bug reports for that package:

 * #5304: missing man page
 * #6647: netcat has no manpage
 * #9489: Package is still in old source format.
 * #9785: netcat: Documentation
 * #11530: /usr/doc/netcat
 * #11716: libc6
 * #13194: netcat: /usr/doc/netcat is file, not directory

It does not fix bug #10486, "nc doesn't understand ports in /etc/services
that have a '-' in them".

This package was done from scratch with source from ftp.avian.org, instead
of updating Michael's package. To make a non-maintainer release I have 
ripped the description and a few other fields from the control files
of the previous package. I've taken the liberty of cutting and pasting a
manpage together and compiling with -DTELNET. I also put the examples and
scripts in /usr/doc/netcat/ in their own directories. /usr/doc/netcat is
now /usr/doc/netcat/README. There's now a changelog and changelog.Debian.
It's libc6 now.

Since this is my first Debian package, I'd appreciate a little peer
review. Install it, try it out, check that it runs on your system, unpack
the .tar.gz and patch, then see if it builds, etc...

Because I'm not an official debian developer (...gonna have to fix that :)
it has been uploaded to chiark. Word is it's sitting in master's incoming
directory awaiting further processing, so all you official developers can
get it there. If I'm connected, you can also snag it from my machine (on a
pitiful 28.8) at ftp://rcw.oz.net/pub/debian/. If you know your way around
chiark it should also be in alldone/ temporarily.

That should be enough to allow inclusion in hamm.

Also, netcat is conflicting with another package, nedit. The nedit client
(nedit does client/server apparently) is also called 'nc'. Does anyone
have any suggestions on what to do here?
--
Robert Woodcock - [EMAIL PROTECTED]
All I want is a warm bed and a kind word and unlimited power.
-- Ashleigh Brilliant


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: 2 versions of netcat

[Robert Woodcock]

On Sat, 10 Jan 1998, Joey Hess wrote:
> I just noticed that 2 versions of netcat are in incoming. Last night, I
> didn't realize this, and assumming that netcat was libc and noboday was
> working on it, I decided to fix it, and uploaded version 1.10-4. (I'm not
> the maintainer either, but I assummed the package was orphaned, so didn't do
> a non-maintainer release.). Oops, you got there first, way back in december!

Since [EMAIL PROTECTED] hasn't gotten back to me yet, and the
packages I've uploaded have been rejected because I haven't been
registered yet, you might as well ignore 1.10-3.1.

Michael Shields, the current maintainer, doesn't really have the time
to keep it up to date, so if you wanna take it (or if I could get
registered, *nudge nudge wink wink* :>) that'd be great.

> I see some overlap in the changelogs. Your version has:

[...]

Heh, maybe I should be more verbose in my changelogs. :) I'm slowly
getting the hang of this - I didn't notice that bugs resolved should
be mentioned in the changelog. 

There's actually quite a bit of overlap.

[...]

> I've now taken it upon myself to resolve this by releasing 1.10-5, which
> merges the man pages (mine was longer, but yours was better in places; the
> diff of the 2 is amusing :-), and compiles with -DTELNET.

Heh, that works. I wrote the man page almost entirely by cutting and
pasting stuff from the upstream README. :)

Can you send this to me via e-mail? I don't have an account on master yet.

Also I've been hearing that there's a namespace conflict between nc
(netcat) and nc (nedit-client). Any ideas on this one? I think it'd be
easier to rename the latter because it's not a backend tool and thus not
likely to be used in scripts. (And of course because it wouldn't affect
me. :)
--
Robert Woodcock - [EMAIL PROTECTED]
All I want is a warm bed and a kind word and unlimited power.
-- Ashleigh Brilliant


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Why isn't /bin/sh managed with alternatives?

[Robert Woodcock]

On Sun, April 5, Shaleh <[EMAIL PROTECTED]> wrote:
> My assumption is that /bin/sh is VERY important to the system.  All
> server scripts use it.  A dangling symlink could be hazardous.  Also,
> some systems initially mount only certain directories.  And /etc is
> sometimes on a different partition entirely.  /bin should stand on its
> own.

*NO* dynamically linked binary (this includes /sbin/init and /bin/sh) will
run without /etc/ld.so.cache:

mercury:~$ strace init
execve("/sbin/init", ["init"], [/* 27 vars */]) = 0
brk(0)  = 0x804dde8
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)  = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=9333, ...}) = 0
mmap(0, 9333, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4000c000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3

For the curious, it retrieved that "/lib/libc.so.6" string from
ld.so.cache.

By the way, is ash any faster at sh script processing than bash?
If we made ash the default /bin/sh, would it speed the bootup process any?

Another idea I got on IRC was providing a --background flag to
start-stop-daemon so that daemons could be started in parallel - this
might have quite an effect on SMP systems, and DNS misconfigs would be
more treatable if sendmail started in the background instead of waiting a 
few minutes timing out on stuff before anything else could run.

Or we could just use & to do it.
--
Robert Woodcock - [EMAIL PROTECTED]
All I want is a warm bed and a kind word and unlimited power.
-- Ashleigh Brilliant


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

CERT bind alert.

[Robert Woodcock]

Henry Hollenberg <[EMAIL PROTECTED]> wrote:
> Has anyone assesed the impact of the bind exploit announced by CERT
> today.

> I'm using bind_4.9.6-1.deb, so would be curious as to where I stood,
> what the fixes were.

> Thanks

>Henry Hollenberg [EMAIL PROTECTED]

Ya know what sucks?

I worked my butt off to get it patched and packaged up, made the .deb's,
got them uploaded a few places:

ftp://ftp.linpeople.org/pub/Software/Bind/bind_8.1.1-7.1_i386.deb
http://www.oz.net/~rcw/bind_8.1.1-7.1_i386.deb

And then I was in the middle of composing a message to this list with a
big scary subject like "SECURITY FIX:" which forced me to quote the CERT
advisory (causing me to *read* it :)...

>Date: Wed, 8 Apr 1998 17:45:08 -0400
>From: CERT Advisory 
>To: cert-advisory@coal.cert.org
>Subject: CERT Advisory CA-98.05 - bind_problems
>Reply-To: [EMAIL PROTECTED]
>Organization: CERT(sm) Coordination Center -  +1 412-268-7090
>
>-BEGIN PGP SIGNED MESSAGE-
>
>=
>CERT* Advisory CA-98.05
>Original issue date: April 08, 1998
>
>Topic: Multiple Vulnerabilities in BIND
>1. Inverse Query Buffer Overrun in BIND 4.9 and BIND 8 Releases
>2. Denial-of-Service Vulnerabilities in BIND 4.9 and BIND 8 Releases
>3. Denial-of-Service Vulnerability in BIND 8 Releases
[...]
>II.  Impact
>
> Topic 1: A remote intruder can gain root-level access to your name server.
>
> Topics 2 and 3: A remote intruder is able to disrupt normal operation of
> your name server.
[...]
>*
>Topic 1: Inverse Query Buffer Overrun in BIND 4.9 and BIND 8 Releases
>*
>
>1.A. Description
>
> BIND 4.9 releases prior to BIND 4.9.7 and BIND 8 releases prior to 8.1.2
> do not properly bounds check a memory copy when responding to an inverse
> query request. An improperly or maliciously formatted inverse query on a
> TCP stream can crash the server or allow an attacker to gain root
> privileges.
>
>1.B. Determining if your system is vulnerable
>
> The inverse query feature is disabled by default, so only the systems
> that have been explicitly configured to allow it are vulnerable.
>
> BIND 8
>Look at the "options" block in the configuration file (typically
>/etc/named.conf). If there is a "fake-iquery yes;" line, then the
>server is vulnerable.

So, you can't get root on the existing package unless you enabled the
fake-iquery option.

Well that right there ticked me off enough to make me cancel the
message, give up and go to sleep and let Johnie Ingram package up 8.1.2.
(which was designated beta last I heard...)
--
Robert Woodcock - [EMAIL PROTECTED]
All I want is a warm bed and a kind word and unlimited power.
-- Ashleigh Brilliant


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

Re: Debian Bug#20445 disagree

[Robert Woodcock]

On Thursday, April 9, 1998, Brian White <[EMAIL PROTECTED]>
> I think that if somebody can get the 2.2 kernel source off of CD, build
> the kernel (hopefully as a debian package) and install it, they have the
> knowledge and the ability to download packages from the network using
> one of the many possibilities of dpkg, dselect, dftp, or another.
> 
> What we lose is including packages that break either during installation or
> when run on a stock Hamm system.  Since we are shipping a "hamm" CD, I
> believe that that CD should be as problem free as possible.  If people
> start mixing things from different CDs, they have to realize things may
> not work "out of the box".

I must have missed the part of this conversation that had the facts in
it... Exactly what 2.1.x-kernel-ready packages currently in hamm break
parts of a 2.0.x system?

For example, if modutils 2.1.71 works perfectly fine with 2.0.x kernels,
and there are no outstanding bug reports against it related to that (a
quick glance says there aren't), then there's no reason to go back to the
2.0.0 version.

2.0.x is our release priority - however I think having hamm ready
for 2.2 kernels *without causing problems for 2.0.x users* is a good idea.
Debian does have a bit of a reputation for packaging all the latest and
greatest stuff.

The original bug report mentioned these packages:

ax25-utils
smbfsx
ncpfsx
vold
pciutils
romfs
ipportfw
bridgex

* Juan Cespedes mentioned that romfs works with 2.0.x with the
  included patches. In any case it does not hinder 2.0.x functionality.
  *crosses off list*
* ax25-utils doesn't hinder 2.0.x functionality, and patches are
  available. *crosses off list*
* pciutils doesn't hinder 2.0.x functionality. *crosses off list*
* vold doesn't hinder 2.0.x functionality. *crosses off list*
* ipportfw doesn't hinder 2.0.x functionality and has a supplied 2.0.x
  patch. *crosses off list*
* bridgex doesn't hinder 2.0.x functionality and has a supplied 2.0.x
  patch. *crosses off list*

That leaves us with smbfs/smbfsx and ncpfs/ncpfsx. Can someone verify that
these packages coexist or that smbfsx/ncpfsx works with 2.0.x?

I personally think non-interactively printing a message during
installation like "Warning - this package requires a 2.1. or later
kernel to function." would be more than adequate.
--
Robert Woodcock - [EMAIL PROTECTED]
All I want is a warm bed and a kind word and unlimited power.
-- Ashleigh Brilliant


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

A little ircii /dcc tweak I'd like to see the default...

[Robert Woodcock]

I'd like to see this patch become the default:

--- ircii-4.4/source/dcc.c~ Thu Dec 25 17:36:09 1997
+++ ircii-4.4/source/dcc.c  Sat Apr 18 19:22:43 1998
@@ -940,16 +940,6 @@
return;
}
 #endif /* S_IFDER */
-   if (scanstr(FileBuf, "/etc/"))
-   {
-   yell("Send request rejected");
-   return;
-   }
-   if ((int) strlen(FileBuf) >= 7 && 0 == strcmp(FileBuf + strlen(FileBuf) 
- 7, "/passwd"))
-   {
-   yell("Send request rejected");
-   return;
-   }
filesize = stat_buf.st_size;
Client = dcc_searchlist(FileBuf, user, DCC_FILEOFFER, 1, filename);
if ((Client->file = open(Client->description, O_RDONLY | O_BINARY)) == 
-1)

Yes, what that does is check your /dcc commands to see if they have /etc
or /passwd in them, and if they do, print a message "Send request
rejected".

Pretty much the only reason it's there is so clueless users can't be
tricked into sending people /etc/passwd files.

This makes sense on a large system with lotsa newbies on it.

It does *not* make sense when you're just trying to exchange XF86Config's
or what-have-you over IRC to try to help get something to work for
someone.

My thoughts on this are that large systems without shadow passwords with
shell accounts with ircii installed are:

1. very few and far between.

2. probably not running debian.

3. have hundreds of other security holes because of #2, making this one
   irrelevant.

4. have admins who usually wouldn't get debianized source anyway, or if
   they did, they'd be clueful enough to "fix" it.

I'd love to hear people's opinions on this.
--
Robert Woodcock - [EMAIL PROTECTED]
All I want is a warm bed and a kind word and unlimited power.
-- Ashleigh Brilliant


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

Re: A little ircii /dcc tweak I'd like to see the default...

[Robert Woodcock]

On Sun, 19 Apr 1998 16:23:58 +, Rev. Joseph Carter wrote:
>On Sat, Apr 18, 1998 at 07:29:19PM -0700, Robert Woodcock wrote:
>> I'd like to see this patch become the default:
[...]
>> Yes, what that does is check your /dcc commands to see if they have
>> /etc or /passwd in them, and if they do, print a message "Send request
>> rejected".
>
> Ick, no.  If an admin is not running shadow passwds, that's their fault.
> Don't cripple the user needing help with a file in /etc.

Hmmm, I guess I didn't make that very clear. I was not advocating putting
that code *in* the ircii sources, I was advocating taking it *out*.

(As for copying it to /tmp first, yeah, that *will* work, but why should
we put users through the pain for no reason at all? In fact, I was able
to defeat it by symlinking ~/argh to /etc and /dcc'ing ~/argh/whatever.)
--
Robert Woodcock - [EMAIL PROTECTED]
All I want is a warm bed and a kind word and unlimited power.
-- Ashleigh Brilliant


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

DFMR

[Robert Edmonds]

Anyone wishing to be on the DFMR (Deb Freshmeat Repository) team
should email [EMAIL PROTECTED] with the subject DFMR.

I understand Freshmeat has _one_ person managing the RPM
repository...

--
Robert S. Edmonds
Debian Developer (http://www.debian.org)
mailto:[EMAIL PROTECTED]
http://edmonds.home.ml.org


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

freshmeat

[Robert Edmonds]

freshmeat now has a deb repository.

i have been busy all morning as a freshmeat staff member pulling
down packages onto the freshmeat server and updating their
appindex records. (scoop recently implemented the ability to
provide a link to a deb directory on freshmeat) i updated 81
appindex records and their debs are stored on freshmeat's ftp
server. (there are more than 81 .debs there, however, because
some are split, e.g. gimp, amanda, vnc)

if you maintain a package that is in freshmeat's appindex and
your package is the latest version, and the link to the .deb is
not on freshmeat, please email [EMAIL PROTECTED]
and where the package is in debian as well as freshmeat.

--
Robert S. Edmonds
-
Debian developerhttp://www.debian.org
Freshmeat staff member   http://freshmeat.net
[EMAIL PROTECTED] / http://www.smart1.net/edmonds
-


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

Re: Intent to package: uedit

[Robert Woodcock]

On Wed, 29 Apr 1998, Igor Grobman wrote:
> O my god!! This is true.  I downloaded it, and the README is pretty much
> what James has written.  I tried starting it, and it managed to kill
> exmh, but not all of X exiting with "Setup Eror: Unable to Initialize
> Program".  What a pity, it failed to kill X :).

> Um... I suddenly have a strange desire to destroy someone or something.

Well, after making a user to test this out with:

mercury:/home/rcw/Uedit_0.9c$ strace ./Uedit
execve("./Uedit", ["./Uedit"], [/* 24 vars */]) = 0
brk(0)  = 0x19000
ioctl(0, KDSETMODE, 0)  = 0
ioctl(0, VT_WAITACTIVE, 0)  = -1 ENXIO (Device not configured)
ioctl(0, VT_SETMODE, 0x18ef8)   = 0
ioctl(0, VT_RELDISP, 0) = -1 EINVAL (Invalid argument)
sigaction(SIGUSR1, {SIG_IGN}, {SIG_DFL}) = 0
open("/dev/mem", O_RDWR)= -1 EACCES (Permission denied)
fstat(1, {st_mode=S_ISGID|010, st_size=0, ...}) = 0
brk(0x1c000)= 0x1c000
brk(0x1d000)= 0x1d000
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
write(1, "Setup Error: Unable To Initializ"..., 42Setup Error: Unable To
Initialize Program
) = 42
_exit(0)= ?

Yeah, that's right, an editor that opens /dev/mem.

I'm also wondering why, in 1998, this guy is releasing a.out binaries,
without source. It's just like, you know, so... *retro!*
:)

Sick. Disgusting. Wrong.
--
Robert Woodcock - [EMAIL PROTECTED]
All I want is a warm bed and a kind word and unlimited power.
-- Ashleigh Brilliant


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

Debian volunteers needed for Atlanta Linux Showcase

[Robert Edmonds]

Volunteers are needed for October's ALS. I already have several possible
people that can man the booth. We need people around, or close to the
Atlanta area to be able to help man the booth (bring your screamer box,
etc.) and also less obvious donations. Redhat will be there with its
ubiquitious free CDs. We need LSL or someone to donate a couple hundred
CDs (attendance to ALS is expected to be 1000 or so), preferably a CD
manufacturer who can press them cheaply. We also need literature,
brochures, etc. we can pass out to people.

As ALS will be held on October 23 and 24, we'll hope to be passing out
*hamm* CDs... ;)

--
Robert S. Edmonds
-
Debian developerhttp://www.debian.org
Freshmeat staff member   http://freshmeat.net
[EMAIL PROTECTED] / http://www.smart1.net/edmonds
-


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

libsilc package policy violations (bug #273871)

[Robert McQueen]

Tamas SZERB wrote:
> once upon a time, I closed this bug. then the submitter reopened it,
> so currently I don't give it a f*ck. Our opinion are different, so if
> you feel any ambition to get the both sides together, feel free to
> volunteer. :)

This package's violation of Debian policy on the packaging of shared
library packages is a fact, not an opinion. You have given no sound
reasons why this package is not correctly versioned, or given any
indication that you understand the issues at hand, such as how it is
expected to retain compatibility with existing packages when the API or
ABI undergoes changes (indeed, as it has just done upstream).

In your favour, you have correctly not closed this bug because it is not
fixed. Unfortunately this release critical bug is preventing the
propogation of any SILC-based software into testing, and hence Debian's
iminent sarge release. This is not a good situation for our users, and I
would like to be able to enable Gaim's SILC plugin. Hence I suggest one
of the following courses of action:

a) you correct the package issues yourself in the ways we have outlined
in the bug; or

b) you admit to not understanding the issues involved in packaging a
shared library, and orphan or put this package up for adoption forthwith; or

c) you do nothing (or close this bug without fixing it, whereupon I will
reopen it) and I refer a this bug to the technical committee for them to
ruminate upon over the course of several months, essentially
guaranteeing that no SILC-based software will be released with sarge

I'm sorry to issue an ultimatum like this, but you have clearly
indicated you are not willing to fix the package - indeed, far worse,
you have stated that you don't care that it's broken - and everyone I
have sought advice from on this issue agrees that you are in the wrong here.

Regards,
Rob



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

Re: Bug#305753: general: 38 packages still use 'Origin: debian'

[Robert Lemmen]

On Tue, Apr 26, 2005 at 11:39:38AM +0200, Thijs Kinkhorst wrote:
> So to conclude, there's no reason for that mass bug filing apart from your
> "feeling" that it "looks funny". Since it poses no real problem at all, I
> don't even see a lintian-test being warranted for this. This should indeed
> be closed unless you can come up with some real reason why this should be
> changed.

of course this should not be rushed, and isn't really critical at all.
but cruft *is* a bug, and things should be cleaned up.

cu  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Re: Linda warnings

[Robert Collins]

On Mon, 2005-05-30 at 03:33 -0400, Eric Dorland wrote:
> * Tollef Fog Heen ([EMAIL PROTECTED]) wrote:
>  
> > Because we want to test for buildability.  We want to make it possible
> > to change any part of the program and barring real errors, it should
> > still build.  That upstream writes crap configure.in/.ac and
> > Makefile.ams is not an excuse, it's just a bug which should be fixed.
> 
> Well I don't disagree. But either we test every auto* using package
> this way, or we don't. The auto* tools are designed specifically so
> that they are not build dependencies. So making it a build dependency
> seems like a kludge. Now if we wanted to make it a general policy to
> test whether auto* regeneration works then I have less problem with
> that, but it would be a lot more work, for very little benefit that I
> can see.   

The auto* tools are only /not/ a build dependency when one does not
change the code. They are explicitly a build dependency for developers.

We and the buildds do *not count* as end users - we are patching the
code in most cases.

So either you don't patch the package, or you be willing to require the
relevant auto* be installed.

Rob

-- 
GPG key available at: .


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Robert Collins]

On Wed, 2005-06-01 at 00:06 -0500, John Goerzen wrote:

> BTW, the baz folks could get some very neat ideas from darcs.  The
> "offline mode comes free" way of working is very nice, and the
> branching being easier than Arch is nice, too.

We have .. we're about 3 releases (~3 months) away from a full
pull-style checkout that will bring all the history and be branchable
via a simple cp.

This is part of our convergence with the bzr design, as bzr proves each
point we're bringing it into baz - quite successfully so far.

Cheers,
Rob

-- 
GPG key available at: .


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

Re: Bits from GNU/kFreeBSD maintainer

[Robert Millan]

On Thu, Jun 02, 2005 at 04:39:25PM +0200, Aurelien Jarno wrote:
> >   - Maintaining the kernel package (kfreebsd5-source [3] and kfreebsd5 [4]).
> > This basicaly involves packaging new upstream releases and appliing
> > security patches from upstream when due to.
> 
> I am interested in this two packages. BTW, do you have some tips to give
> concerning the packaging of the FreeBSD kernel.

They're yours, then.

I can't think of any tips right now, but if you have questions feel free to
ask.

> > Well, that's all.  Thanks for reading.  Feel free to contact me if you need
> > assistance with adopting stuff related to GNU/kFreeBSD or my packages.
> Are you planning to follow a little the development of the port?

I might follow it, but I don't plan to be involved in the development.  I will,
however, try to be helpful with you or anyone who wants to work on it, and
answer the necessary questions or the like.

> If it
> is not the case, it would be nice to provide us the necessary
> information to continue developping the port. I am thinking of:
> - Access to the alioth project as administrator

Done.

> - Way to contact the gnuab administrator

Our contact is Guillem Jover <[EMAIL PROTECTED]>


Good luck, and thanks for your interest!

-- 
 .''`.   Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S)
: :' :
`. `'http://www.debian.org/ports/kfreebsd-gnu
  `-


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

Re: Canonical and Debian

[Robert Lemmen]

On Tue, Jun 07, 2005 at 02:12:04AM -0700, Steve Langasek wrote:
> - sparc: one buildd which is not consistently able to keep up with the
>   volume of incoming packages; no backup buildd, no additional porter
>   machine.

how powerfull would a machine need to be to be of any help here? would
an ultra 10 or a netra x1 be sufficient?

cu  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Re: Is Ubuntu a debian derivative or is it a fork?

[Robert Collins]

On Tue, 2005-06-07 at 09:48 -0500, John Goerzen wrote:

> IMHO, it's a bug if it doesn't work efficiently without specialized
> assistance from shell completions.

Yup. I deliberately use baz without shell completions for just this
reason. If something annoys me, it gets fixed;).

Cheers,
Rob

-- 
GPG key available at: .


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

Re: Canonical and Debian

[Robert Lemmen]

On Tue, Jun 07, 2005 at 09:38:51PM -0400, Stephen Frost wrote:
> Personally, I'd think it could probably help..  Though at the same time,
> we should probably consider all the options which are made available in
> case there's something that wouldn't require much additional effort to
> maintain but would have more room for growth.

ok, if the u10 is needed for something reasonable usefull (buildd,
porter machine) i'd ship it to where it's needed (within europe, for the
rest of the world i'd have to check shipping prices first). i can't host
the machine myself, as i'm no DD and therefore not trusted enough, but
i'd like an ordinary user account on the machine, as i need it for work
every now and then. just holler when you know where and when it is
needed...

cu  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Robert Collins]

On Thu, 2005-06-09 at 09:25 +1000, Matthew Palmer wrote:
> On Thu, Jun 09, 2005 at 01:13:16AM +0200, Javier Fernández-Sanguino Peña 
> wrote:
> > to find their own (sometimes flawed) solution to a very common problem. 
> 
> Years using Linux: 10.
> 
> Times I've absolutely needed an X-less boot when an XDM was installed: 0.
> 
> How common was that problem you were trying to solve, again?

Its not frequency but impact. In, oh, 94, I had a linux box that started
hard locking when the *DM started. Having a X-less, networked startup
config in lilo was a life saver.

The cost of having a networked, X-less rc level is pretty darn low. Why
do you not want one ?

Rob

-- 
GPG key available at: .


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

Thunderbird & Firefox

[Robert Wolfe]

Hi all!  Could someone tell me if Thunderbird and / or Firefox are available 
for download via apt-get?


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

Re: SElinux and GNU/kFreeBSD or GNU/Hurd

[Robert Millan]

On Wed, Jun 15, 2005 at 04:19:42PM +0200, Aurelien Jarno wrote:
> 
> * debian/rules
>   Add the following lines:
> DEB_HOST_GNU_SYSTEM   ?= $(shell dpkg-architecture 
> -qDEB_HOST_GNU_SYSTEM)
> ifeq ($(DEB_HOST_GNU_SYSTEM),linux)
>   selinux := --with-selinux
> endif

AFAIK with the new dpkg, $(DEB_HOST_GNU_SYSTEM) now contains "linux-gnu".

-- 
Robert Millan


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

Re: Greylisting for @debian.org email, please

[Robert Wolfe]

On Sun, 19 Jun 2005, Marco d'Itri wrote:


On Jun 18, Glenn Maynard <[EMAIL PROTECTED]> wrote:


Email is realtime.  I receive mails much more quickly than five minutes
on average; within seconds, typically, even for round-trips to many
mailing lists.  Reducing that to minutes on average is beyond unacceptable.

What I like of you is your reasonableness and common sense.


Email can also be "non-realtime" in the case of those that still use the 
old clunky, but still effective, UUCP method of mail delivery (I use this 
method on my dialup-based BBS that I still run).



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

Re: Greylisting for @debian.org email, please

[Robert Wolfe]

On Sat, 18 Jun 2005, Thomas Bushnell BSG wrote:


Indeed, I have been sending my mail with UUCP since more than 10 years
and I am not going to stop soon.


That's fine.  What people are asking for is best effort delivery, and
eventual delivery of all valid messages.  Your proposal (and your
practice?) violate both of those.


Clarify.

As long as the email gets out via UUCP and comes in via UUCP without 
problems, I do not see HOW his practice and proposal violate "best effort 
delivery."  Then again, it would seem that not everyone has the same 
definition of "best effort," now would they?



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

mass bug filing for libjack dependant packages

[Robert Jordens]

Hello!

I uploaded a new release of jack-audio-connection-kit to unstable. The
following source packages have been built against libjack0.80.0-dev and
must now be rebuilt against libjack0.100.0-dev due to incompatible API
changes. I plan to file important bugs and then upgrade them to
something RC after a few weeks. Is that OK?

Robert.



jack-audio-connection-kit xmms-jack timidity timemachine terminatorx
tapiir supercollider snd rezound qjackctl puredata muse fluidsynth
alsa-plugins alsa-lib ardour ladcca jack-tools horgand gst-plugins galan
freqtweak fluidsynth ecawave ecasound2.2 ecamegapedal cheesetracker
bitscope ardour alsaplayer jack-audio-connection-kit gst-plugins0.8
zynaddsubfx xmms-jackasyn xmms-jack timidity timemachine terminatorx
tapiir supercollider stk spiralsynthmodular specimen snd rosegarden4
rezound qjackctl puredata muse meterbridge fluidsynth alsa-plugins
alsa-lib ardour ladcca koffice jamin jackeq jack-tools jack-rack
hydrogen horgand galan freqtweak ecawave ecasound2.2 ecasound
ecamegapedal creox cheesetracker brutefir bitscope ardour ams alsaplayer
bio2jack jack-audio-connection-kit gst-plugins0.8 bio2jack thinksynth
arts xmms-jack hydrogen alsaplayer zynaddsubfx xmms-jackasyn xmms-jack
timidity timemachine terminatorx tapiir supercollider stk
spiralsynthmodular specimen sooperlooper snd seq24 rosegarden4 rezound
qjackctl puredata kdeaddons kdemultimedia muse meterbridge linphone
kdebase libjackasyn jack-audio-connection-kit fluidsynth alsa-plugins
alsa-lib kdemultimedia arts allegro4.1 ladcca kdenetwork kdeartwork
kdemultimedia koffice kdeaddons knights kdelibs kdemultimedia k3b
kdemultimedia jamin jackeq jack-audio-connection-kit jack-tools
jack-rack hydrogen horgand gst-plugins0.8 galan freqtweak ecawave
ecasound2.2 ecasound ecamegapedal creox cheesetracker brutefir bitscope
basket kdemultimedia ardour amsynth ams alsaplayer kdemultimedia



-- 
Thus spake the master programmer:
"Let the programmers be many and the managers few -- then all will
be productive."
-- Geoffrey James, "The Tao of Programming"


signature.asc
Description: Digital signature

Re: Accepted jack-audio-connection-kit 0.100.0-2 (powerpc source)

[Robert Jordens]

 everyone to stop uploading before I
upload and tell them to upload after all arches have been built
jack-audio-connection-kit.

>   And finally, this is IMHO a sufficiently big transition that
>   debian-release should have been contacted in advance, for guidance and
>   advice too. Perhaps the answer would have been "Sure, go ahead right
>   now", but it could also have been "We're sorting out the bits for the
>   C++ transition, let's hold this a few weeks, ok? Sorry for the
>   inconvenience." Or even (this is not your case, and I'm only
>   mentioning as a worst-case scenario): "Dude, you just f*cked up our
>   timeline for the C++ transition".

Sure. The number has grown a lot since the last API change.
BTW: I fear that there will be more of these new JACK releases.


> LIST OF PACKAGES

Thanks for that!


[Tue, 28 Jun 2005] Hamish Moffatt wrote:
> On Mon, Jun 27, 2005 at 04:10:42PM +0200, Robert Jordens wrote:
> > I uploaded a new release of jack-audio-connection-kit to unstable. The
> > following source packages have been built against libjack0.80.0-dev and
> > must now be rebuilt against libjack0.100.0-dev due to incompatible API
> > changes. I plan to file important bugs and then upgrade them to
> > something RC after a few weeks. Is that OK?
> 
> Couldn't you keep the old library in the archive for a while?
> Is a mass forced upgrade necessary? Beneficial?

Not beneficial but necessary since there is jackd which works only with
exactly one libjack and conflicts with all others. So having two libraries
installed would force users to remove jackd breaking all jack setups.
So I can't keep the old library. I could have just singled out those
packages that use the changed parts of the API but that would have broken
inter-distribution compatibility and would not have been consistent
either.

Robert.

-- 
Factorials were someone's attempt to make math LOOK exciting.


signature.asc
Description: Digital signature

Looking for a Maintainer

[Robert Felber]

Hello debians,

I am not using debian and can thus not build and maintain debian packages.
Thus I am looking for someone, who audits and maintains policyd-weight - 
a policy daemon in perl for postfix. 
The master site is http://robtone.mine.nu/postfix/

I am a FreeBSD contributor and maintaining this port for FBSD and would like
to make it accessible for others too - via their packet-management.


-- 
Robert Felber (EDV-Leitung)
Autohaus Erich Kuttendreier 
Drosselweg 21
81827 Muenchen

Tel: +49 (0) 89 / 453 12-86
Fax: +49 (0) 89 / 453 12-80

PGP: 896CF30B
PGP-Fingerprint: A43A A57E ECF4 F80F FDFC  285A 0A7F B077 896C F30B


pgpBd8VE3LgUX.pgp
Description: PGP signature

Re: HashKnownHosts

[Robert Collins]

On Sun, 2005-07-03 at 18:36 +0200, Martijn van Oosterhout wrote:

> One case I can think of is where you regularly ssh into a machine with
> a dynamic IP address. Maybe with or without a dyndns name. Depending
> on the size of the ISP and how often the address changes the
> known_hosts files could increase without bound.

Theres a ~/.ssh/config option for that. HostsKeyAlias or something.

Rob

-- 
GPG key available at: .


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

Bug#317973: ITP: alps-full1 -- Algorithms and Libraries for Physics Simulations

[Robert Jordens]

Package: wnpp
Severity: wishlist
Owner: Robert Jordens <[EMAIL PROTECTED]>

* Package name: alps-full1
  Version : 1.2.2
  Upstream Author : Matthias Troyer et al.
* URL : http://alps.comp-phys.org/
* License : custom non-free (see below)
  Description : Algorithms and Libraries for Physics Simulations

The ALPS project (Algorithms and Libraries for Physics Simulations) is an open
source effort aiming at providing high-end simulation codes for strongly
correlated quantum mechanical systems as well as C++ libraries for simplifying
the development of such code. ALPS strives to increase software reuse in the
physics community.

alps-full1 is the full version of the ALPS libraries. The reduced
version is alps-light1 and under the boost license. see Bug#316621


License:

ALPS LIBRARY LICENSE version 1.1
Copyright (C) 2003-2005 Ian McCulloch.  Everyone is permitted to copy and
distribute this license document.

This License applies to any software containing a notice placed by the copyright
holder saying that it may be distributed under the terms of the ALPS Library
License version 1.1.  Such software is herein referred to as the "Library".
This license grants permission to use, reproduce, display, distribute, execute
and transmit the Library, and to prepare derivative works of the Library, and to
permit others to do so for non-commercial academic use, all subject to the
following conditions:

1. In any scientific publication based wholly or in part on the Library, the use
of the Library must be acknowledged and the publications listed in the
accompanying CITATIONS.txt document must be cited.

2. You may copy and distribute verbatim copies of the Library in the form that
you received it, as long as all copyright notices and references to this license
and warranty disclaimer are kept intact, and all recipients also receive a copy
of this license, warranty disclaimer and CITATIONS.txt document.

3. You may modify your copy or copies of the Library, thus forming a work based
on the Library, and use, copy or distribute such modified works under the terms
of sections 1 and 2 above, provided that you also meet all of these conditions:

a. You must cause the modified files to carry prominent notices stating
that you changed the files and the date of any change.

b. All citations listed in the CITATIONS.txt document that refer to
sections of the Library that exist in the modified work must be
preserved irrespective of the extent of the modification.

c. You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Library or any part
thereof, to be licensed as a whole at no charge to all third parties
under terms compatible with this License.

4. This Software, or modifications under section 3 above, may be distributed in
object code or executable form, provided that you meet all of these conditions:

a. This complete License, warranty disclaimer and accompanying
CITATIONS.txt document is included.

a. The executable program is accompanied with the complete
machine-readable source code to the Library as used in the executable,
which must be distributed under the terms of sections 2 and 3 above.
Alternatively, you may provide instructions for obtaining the source
code at no cost (for example, a hyper-text link).

5. A program that contains no derivative of any portion of the Library, but is
designed to work with the Library by being compiled or linked with it, is not
a derivative work of the Library, and therefore falls outside the scope of this
License.

However, linking such a work with the Library creates an executable that is a
derivative of the Library (because it contains portions of the Library).  The
executable is therefore covered by this License.  Section 4 states terms for
distribution of such executables.

6. You must cause executable programs that utilize this Library to print or
display, when started in the most basic way, a prominent announcement including
a copyright notice and citation requirements as listed in the accompanying
CITATIONS.txt document.  If the executable program utilizes the Library in a
modified form (under section 3 above), then the announcement must state this.
Exception: if the announcement would not normally be visible to the user, or
the announcement would interfere with normal operations of the executable
application, then the executable program is not required to print an
announcement.

THIS SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT.  IN NO EVENT
SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE FOR
DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OT

Bug#317980: ITP: alps-applications1 -- Algorithms and Libraries for Physics Simulations

[Robert Jordens]

Package: wnpp
Severity: wishlist
Owner: Robert Jordens <[EMAIL PROTECTED]>

* Package name: alps-applications1
  Version : 1.2.2
  Upstream Author : Matthias Troyer et al.
* URL : http://alps.comp-phys.org/
* License : custom non-free cite-me/non-commercial (see below)
  Description : Algorithms and Libraries for Physics Simulations

The ALPS project (Algorithms and Libraries for Physics Simulations) is
an open source effort aiming at providing high-end simulation codes for
strongly correlated quantum mechanical systems as well as C++ libraries
for simplifying the development of such code. ALPS strives to increase
software reuse in the physics community.

 This package contains the applications (under the
 non-commercial/cite-me license):
  *  Classical Monte Carlo
o The application spinmc simulates classical spin systems
  using local and cluster updates.
  * Quantum Monte Carlo (QMC)
o The loop algorithm for quantum spin systems with inversion
  symmetry using loop-cluster updates (from ALPS/looper Library).
o Stochastic series expansion (SSE) using the directed-loop algorithm
  for general quantum spin systems in magnetic fields or bosonic
  models.
o The worm code for continuous time simulations of quantum spin
  and bosonic models based on the path integral representations.
o The quantum Wang-Landau code for simulations of isotropic spin-1/2
  models based on the Wang-Landau sampling scheme.
  * Exact diagonalization
o A full diagonalization program for generic quantum lattice models
o An exact diagonalization program for boson and spin quantum lattice
  models
  * Density matrix renormalization group (DMRG)
o "Particle in a box" program


License:

ALPS APPLICATION LICENSE version 1.0
Copyright (C) 2003-2004 Ian McCulloch.  Everyone is permitted to copy and
distribute this license document.

This License applies to any software containing a notice placed by the copyright
holder saying that it may be distributed under the terms of the ALPS Application
License version 1.0.  Such software is herein referred to as the "Software".

The Software covered by this License may use portions or the whole of the
ALPS Library.  The ALPS Library is an independent work covered by its own
license.  This License is designed so that by complying with this License you
are automatically in compliance with the ALPS Library License for the Library
components of this Software.  However that the ALPS Library License may provide
for additional rights with respect to the Library portions of this Software,
which do not apply to this Software as a whole.

This license grants permission to use, reproduce, display, distribute, execute
and transmit the Software, and to prepare derivative works of the Software, and 
to
permit others to do so for non-commercial academic use, all subject to the
following conditions:

1. In any scientific publication based wholly or in part on the Software, the
use of the Software must be acknowledged and the publications listed in the
accompanying CITATIONS.txt document must be cited.

2. You may copy and distribute verbatim copies of the Software in the form that
you received it, as long as all copyright notices and references to this
license and warranty disclaimer are kept intact, and all recipients also receive
a copy of this license and warranty disclaimer.

3. You may modify your copy or copies of the Software, thus forming a work
based on the Software, and use, copy or distribute such modified works under
the terms of sections 1 and 2 above, provided that you also meet all of these
conditions:

a. You must cause the modified files to carry prominent notices stating
that you changed the files and the date of any change.

b. All citations listed in the CITATIONS.txt document that refer to
sections of the Software that exist in the modified work must be
preserved irrespective of the extent of the modification.

c. You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Software or any part
thereof, to be licensed as a whole at no charge to all third parties
under terms compatible with this License.

d. You must cause all executable programs derived from this Software to
print or display, when started in the most basic way, a prominent
announcement including a copyright notice, citation requirements as
listed in the accompanying CITATIONS.txt document, and a notice stating
the date and scope of the modifications.
Exception: if the announcement would not normally be visible to the
user, or the announcement would interfere with normal operations of the
executable application, then the executable program
is not required to print an announcement.

Whether this exception cov

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Robert Collins]

On Tue, 2006-08-01 at 19:44 +0100, martin f krafft wrote:
> also sprach Adeodato Simó <[EMAIL PROTECTED]> [2006.08.01.1936 +0100]:
> > Forgot to add that it can be even _identical_ to subversion, in the
> > sense that you don't have to commit locally, and then push. Just make a
> > "checkout" (refer to the bzr docs), and every commit you make will go to
> > the main repo first, and if that succeeds, will be commited locally as
> > well.
> 
> This is what upstream calls "bound branches", btw.

Well, we call them 'checkouts' :). bound branches is somewhat of an
internal description.

We implemented checkouts to be a precise workflow match for what you get
from SVN/CVS - a branch shared between developers with the system
ensuring you have merged everything. If you have a situation where a
shared branch is what you want, and you like bzr in other respects... I
would recommend trying checkouts.

Rob

-- 
GPG key available at: .


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

Re: Centralized darcs (was Re: centralized bzr)

[Robert Collins]

On Tue, 2006-08-01 at 14:55 -0500, John Goerzen wrote:
> On Tue, Aug 01, 2006 at 08:31:37PM +0200, Adeodato Simó wrote:
> > Right, bzr is great when you have a designed person to integrate
> > contributor's changes after review.
> > 
> > But if you have a set of equal developers, bzr can be also used in a
> > very similar way to Subversion, where all commits go to a central
> > repository, and nobody has to collect them. It's just a matter of
> > setting up a directory somewhere with the appropriate write permissions,
> > and say "This is our canonical archive, the uploader will include what
> > it's in there, nothing more, nothing less".
> 
> I would say that this goes for darcs as well, but even more.
> 
> Darcs has a nice way of pushing patches via e-mail, with GPG signatures
> even.  These can be processed in an automated way on the server,
> verified against, for instance, the Debian keyring, and then applied to
> the repository.
> 
> I think it would work even nicer.

Its somewhat indirect though. bzr has an equivalent system too (called
pqm) which accepts GPG-signed merge requests and applies them to the
repository. FWIW.

Rob
-- 
GPG key available at: .


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

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Robert Collins]

On Wed, 2006-08-02 at 22:29 +0200, Christoph Haas wrote:
> 
> That's in fact an issue that made me feel sceptical about bzr, darcs
> and 
> mercury. All of them require a shell account or some scripting through
> a 
> special mail address to commit changes. And it's not only the recent 
> kernel vulnerability that makes me a happy repository user over
> WebDAV 
> (hoping it's less vulnerable). And it works over a proxy, too.

Well, I dont know darcs well enough to argue there, but neither bzr nor
mercurial require a shell account nor scripting. bzr requires sftp
access *which can be granted without granting shell access*. mercurial
has a http cgi script that can be used to push commits.

bzr is also working on a high performance server at the moment, which
will operate over either a socketpair - i.e. tunnelling via ssh (which
can still be done without granting shell access), or over plain http via
an apache rewrite rule.

HTH,
Rob
-- 
GPG key available at: .


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

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Robert Collins]

On Thu, 2006-08-03 at 08:27 -0300, Otavio Salvador wrote:
> Robert Collins <[EMAIL PROTECTED]> writes:
> 
> > bzr is also working on a high performance server at the moment, which
> > will operate over either a socketpair - i.e. tunnelling via ssh (which
> > can still be done without granting shell access), or over plain http via
> > an apache rewrite rule.
> 
> Is it already working? How we can try?

typo - I meant 'bzr developers are also'...

Its partially functional at this point - we have it passing all the
transport selftests, which means it can be used [by the brave!] as an
alternative to sftp for read-write access, but it no faster. The
higher-level semantic operations are coming along nicely - we hope to
have it in 0.10 due out 4th september.

Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.


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

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Robert Collins]

On Fri, 2006-08-04 at 09:56 +1000, Brian May wrote:


> For documentation on checkouts and bound branches, see
> 
> http://bazaar-vcs.org/CheckoutTutorial
> 
> http://bazaar-vcs.org/BzrUsingBoundBranches
> 
> However, I am not convinced the following paragraph in the first
> page is correct:
> 
> "Getting a checkout is generally faster than making a copy of a
> branch. The catch though is that whenever the checkout needs to look
> at the RCS data it will do so by accessing the branch. This holds true
> even if the branch is on some distant network that you accessed over
> the internet."

Yes, thats bogus. Getting a heavyweight checkout is identical to getting
a new branch. Getting a lightweight one *may* be cheaper, depending on
how much history is needed to reconstruct file versions.

> To me, this sounds like it might be talking about a "lightweight
> checkout", as I believe a checkout is a complete copy of the branch,
> and network access is only required for commits or updates. "Bound
> branches in bzr take the place of remote 'checkouts' in systems like
> CVS or SVN and we refer to them as 'checkouts'. (bzr also supports
> "lightweight checkouts", which are like local checkouts, and aren't
> branches at all.)"
>
> Can anyone confirm/deny?

A checkout --lightweight over the net is currently not a good thing to
do. When the smart server is released, that will be about the same
performance as traditional client-server vcs's like CVS or SVN. 

> 
> My central dislike of bzr is bugs like:
> 
> http://bugs.debian.org/380412
> https://launchpad.net/products/bzr/+bug/54253
> 
> ...which unfortunately makes it unusable for some of my applications.

Are you doing conversions from SVN? Current bzr uses 20MB of ram to do a
native branch operation in similar circumstances. (bug report gets
fixed, new at 11 :)). 

0.9RC1 is out, and 0.9 will be out Monday/Tuesdau. As soon as that lands
in debian the bug should be closed. 

Rob

-- 
GPG key available at: .


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

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Robert Collins]

On Sat, 2006-08-05 at 10:58 +1000, Brian May wrote:
> >>>>> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
> 
> Robert> Are you doing conversions from SVN? Current bzr uses 20MB
> Robert> of ram to do a native branch operation in similar
> Robert> circumstances. (bug report gets fixed, new at 11 :)).
> 
> No, this was a conversion from baz. Might be the same bug though,
> hopefully.

Its likely to be a different bug - the conversion approach used for
svn/baz is very different. That said, conversion from $any system is
going to use more memory than native bzr operations, simply because of
the overhead of having two data structures in memory at once. If you do
a conversion from baz though, once converted you should have no
troubles.

Also, please do file bugs on the conversion logic if it fails to operate
for you.

Cheers,
Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.


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

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Robert Collins]

On Sun, 2006-08-06 at 12:01 +1000, Brian May wrote:
> 
> Curiously though, the problems continue even after the archive appears
> to be converted successfully - if I do a diff operation, it reports
> all files as deleted, but if I try to revert it, it slows to a
> grinding halt. 

Could you please run 'bzr upgrade' while using bzr 0.9rc1. If my guess
at your situation is right this will take a while to run, but correct
your performance issues.

-Rob
-- 
GPG key available at: .


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

Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)

[Robert Collins]

On Sat, 2006-08-12 at 15:59 +1000, Brian May wrote:
> >>>>> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
> 
> Robert> On Sun, 2006-08-06 at 12:01 +1000, Brian May wrote:
> >>  Curiously though, the problems continue even after the archive
> >> appears to be converted successfully - if I do a diff
> >> operation, it reports all files as deleted, but if I try to
> >> revert it, it slows to a grinding halt.
> 
> Robert> Could you please run 'bzr upgrade' while using bzr
> Robert> 0.9rc1. If my guess at your situation is right this will
> Robert> take a while to run, but correct your performance issues.
> 
> Are there any Debian packages of 0.9rc1 available?

0.9 has been released, I believe 'dato is working on an upload now.

Cheers,
Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.


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

Re: dh_python and python policy analysis

[Robert Collins]

On Sun, 2006-08-13 at 19:56 -0500, Manoj Srivastava wrote:
>Here there are two cases. Either module foo can't be written at all
>for version 2.6, or it the same functionality can be provided with


This is a little simplistic.

The parser changes fairly routinely in python versions. This means that
a version conditional is not sufficient to provide compatability with
older pythons - the module will not parse.

The usual thing done for cross version support is to write in the older
version of python, or in extreme cases (i.e. where performance really
hurts) have two separate modules _foo_2_5 and _foo_2_6 and conditionally
do
'from _foo_2_5 import *' etc.

-Rob
-- 
GPG key available at: .


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

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

[Robert Collins]

On Sat, 2006-09-23 at 04:21 -0500, Manoj Srivastava wrote:


> 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

config-manager supports reading a config straight out of the VCS:
http://arch.debian.org/arch/private/srivasta/archive-2003/dists--debian--0/flex/flex-2.5.31.config

(for instance).

URI's accept parameters:
http://arch.debian.org/arch/private/srivasta/archive-2003;gpg-keyid=0x40612c84/dists--debian--0/flex/flex-2.5.31.config

(again, this is a for instance).

-Rob
-- 
GPG key available at: .


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

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

[Robert Collins]

On Tue, 2006-09-26 at 14:16 -0500, Manoj Srivastava wrote:
> On Sun, 24 Sep 2006 17:40:54 +1000, Robert Collins
> <[EMAIL PROTECTED]> said:  
> 
> > config-manager supports reading a config straight out of the VCS: 
> > http://arch.debian.org/arch/private/srivasta/archive-2003/dists--debian--0/flex/flex-2.5.31.config
> 
> But that would involve checking out the category which
>  contains the configs, or putting up the config file on a web page
>  (separately from the repository), and ensuring that the web page is
>  kept in sync, unless I am mistaken,

Yes. Storing the configs in version control is usually a good idea,
because that lets you have a versioned record of the exact composition
of the combined trees. (i.e. the debian subtree @ revision 42, the flex
source tree @ revision 12)

> > URI's accept parameters:
> > http://arch.debian.org/arch/private/srivasta/archive-2003;gpg-keyid=0x40612c84/dists--debian--0/flex/flex-2.5.31.config
> 
> Hmm.  Very interesting. 
>The path may consist of a sequence of path segments separated by a
>single slash "/" character.  Within a path segment, the characters
>"/", ";", "=", and "?" are reserved.  Each path segment may include a
>sequence of parameters, indicated by the semicolon ";" character.
>The parameters are not significant to the parsing of relative
>references.

yup. Not widely used today, but extremely :).

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.


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

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

[Robert Collins]

On Thu, 2006-10-05 at 17:49 +0200, Stefano Zacchiroli wrote:
> 
> Ok, then please propose a patch for:
> 
>   http://svn.debian.org/wsvn/qa/trunk/pts/www/bin/common.py?op=file
> 
> I think it would be quicker for you to propose it, than for me to
> actually find out the pedigree of bzr wrt tla/arch/... :) 

There is no pedigree of bzr wrt tla/arch.

'baz' is a fork of tla. 'baz' and 'tla' are both implementations of
'arch'.

'bzr' is a wholly different codebase/protocol/system.

-Rob
-- 
GPG key available at: .


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

Re: "Arch: all" package FTBFS due to test needing network access - RC?

[Robert Collins]

On Tue, 2006-10-31 at 23:16 -0800, Steve Langasek wrote:
> On Wed, Nov 01, 2006 at 08:02:22AM +0100, Lucas Nussbaum wrote:
> > While I fully agree with you on all points, I think that this should be
> > discussed post-etch with the general question of "in which environment
> > are packages supposed to build ?". There are other similar issue, like:
> > - should packages allow to build as root ? (aegis, bazaar, subversion
> >   don't)
> 
> This question is misphrased; the real question is, "should we require that
> all packages be buildable as root?"  And I don't see any reason the answer
> to this question is "yes".

If anything, I'd like to see a requirement that packages build as
non-root - for the 'run the packages build rules' aspect. 

I can also note why bazaar wont build as root: its test suite includes a
test for the ability to handle read only directories correctly. As root,
anything is writable, so this test fails.

Rob
-- 
GPG key available at: .


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

HELLO

[Robert Page]

Greetings, 
 
I am Barr. Robert C. Page. I am reaching you to handle an investment 
portfolio. 
 
I am reaching you to assist in repatriating the funds and property left 
behind by my late client before it will be confiscated by government 
and declared unserviceable by the bank where the huge deposits were 
lodged. 
He died intestate and every attempt to trace any member of his family 
has proved abortive and unsuccessful. 
 
Do note that who you are does not matter and you will be better 
informed when I hear from you. 
 
I want you to respond by sending: 
 
1. Your full names 
2. Tel & fax numbers 
3. Complete Address 
 
Send the above information and I will furnish you with more information 
about the estate and process of transfer to you. 
 
Yours Faithfully, 
 
Barrister Robert C. Page esq. 
London, U.K. 
 
 
N.B: 
Please respond with your full names, address, phone and fax numbers for 
the immediate start up of this transaction. Do note that who you are 
does not matter and you will be better informed when I hear from you.