Read this before purchasing penis enlarge products!

[Ed]

Dude check out this sweet site!
http://www.toonu.net/ss/





As soon as you trust yourself, you will know how to live. 
Because I have loved life, I shall have no sorrow to die. 
Everything is in a state of flux, including the status quo.  
Do not consider painful what is good for you.
Phonograph, n. An irritating toy that restores life to dead noises.  




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

Re: User feedback -post installation and after-week survey?

[ed]

On Mon, 28 Aug 2006 10:31:02 +0200
"Mgr. Peter Tuharsky" <[EMAIL PROTECTED]> wrote:

> Howabout some form -user could be navigated to some basic webpage
> where  he could answer some simple questions? Not too many questions
> (optimally  5-8?), preferably pre-answered (by some selection box), of
> course with  possibility to add non-default answer for us to be able
> to extend the  possible answers cathegories..
> 
> If user wished to add more feedback, he could have an option, at the
> end  of the basic form, of some "more feedback, if U wish" extended
> form.
> 
> Sample questions: "What have been the most difficult part of 
> installation for You" (disk partitioning, language selection,...),
> "What  have caused it (unsufficient help, nonintuitive, too technical
> questions).
> 
> User should be asked, whether will he participate on some short 
> "survey-after-week-of-using-Debian". If he agreed (let's joke: agreed
> or  not ;oD
> he will be asked automatically after week, by opening some simple and 
> polite application or applet on his desktop, about his impression of 
> Debian. If proceed, again could open some web form or so. Again, what 
> pleases him now (amount of software, ease of setup, everything just 
> works, desktop design, etc...) and what he dislikes (cannot connect my
> cellular phone, Infra not working, Xsane demands root privilegues but 
> complains if he is given them, etc)
> 
> These questions could be structured in the way, that user could pair 
> them. For example, he has a question. In left selection rollup-button
> he  could select WHAT and in second he could select WHY. Example:
> What is the worst problem for You with Debian?
> 
> Printer setup
> Localisation
> Removable devices support
> Instant messaging
> Multimedia
> ...
> 
> 
> Insufficient helper
> Lack of applications
> Lack of functionality
> ...
> 
> 
> And so on. Is something like that being worked on?

I have no idea.
 
> As I look at this concept, I feel one half of problems should be 
> identified even in the very process of creating questions and possible
> answers for the initial and after-week survey :-)
> 
> Well, I'm starting to like the idea so I try to open a new thread ;o)

Although this is a nice idea, the problem with these questionnaires is
that the answers are in a bucket and the accurate answer is not
available for this person.

I think the biggest hurdle that the user faces is the possibility that
they might have to learn something about their computer along the way.
This probably taints their expectation of the system as a whole.

The more savvy computer users are probably system admins who are way too
busy to take the time to fill out a bug report, let alone a 'how does
this distro please you' form.

It's a nice idea, but I wouldn't put too much on the results. A shorter
simple question like 'If you could change one thing, and one thing only,
what would that be' open question might be more reliable.

As for the applet idea, that would annoy me no end, they pop up at the
most inconvenient times.

-- 
Regards, Ed  :: http://www.usenix.org.uk
just another perl person
God didn't create the world; he just locked Mr T in a garage with an 
old Chevy and a box of tools. 


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

getifaddr

[ed]

I wrote a network byte monitor in BSD, thinking that it would port
directly to GNU with a few minor changes. However, I've found that the
if_addr structure does not contain a link to the if_data struct on GNU
stdlib.

What function calls should I make to get this similar data in GNU land?

-- 
Regards, Ed  :: http://www.s5h.net
proud bash person
:%s/Open Source/Free Software/g  :: Free DNS available


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

Re: the planet is gone...

[ed]

On Wed, 12 Jul 2006 13:51:26 +0200
Wolfgang Lonien <[EMAIL PROTECTED]> wrote:

> np - is there a status page somewhere for the Debian boxes, so next
> time ppl could look it up themselves?
> 
> I would volunteer to make one, but I'm no DD...

We might need a status page for the status page box ...

-- 
Regards, Ed  :: http://www.gnunix.net
proud python hacker
Visual Basic, much like generic beer and America's Funniest Home 
Videos is an enabling technology for stupid people. 


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

Re: Please help test Snort 2.3.0 (experimental) packages

[Ed Shornock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Javier Fernández-Sanguino Peña wrote:
| Hi everyone,
|
| I've recently uploaded (to experimental only) new Snort 2.3.0
| packages (based on the release made by the Snort team last January
| 25th).
Does this include snort-pgsql? I don't see for experimental (unless
the mirrors haven't all been updated yet).  I do see snort and
snort-mysql though...
| # apt-get install -t experimental snort-pgsql Reading Package
| Lists... Done Building Dependency Tree... Done snort-pgsql is
| already the newest version.
| # apt-cache policy snort-pgsql snort-pgsql: Installed: 2.2.0-9
| Candidate: 2.2.0-9 Version Table: *** 2.2.0-9 0 650
| http://ftp.nl.debian.org unstable/main Packages 600
| http://mirror.ox.ac.uk testing/main Packages 100
| /var/lib/dpkg/status
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCCkdn3IV9jHsBFhMRAqKbAJ9zhVU2iBSfMtOws4++7ZTew5k2GACggQME
sVVxiyD/o8GQUteuBwik9l8=
=faGV
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Meta pkgs in debian

[Ed Sweetman]

Ok, i'm not subscribed here so please cc me any responses directly.

Before I propose my suggestion I want to outline my issues with how meta 
pkgs are done currently. 

Meta pkgs by my own definition here are pkgs which have no payload of 
their own, but have their "Depends" field loaded with various selected 
pkgs, that dpkg and the like will ask or automatically retrieve and 
install when the meta pkg is installed.


The problem #1: Because meta pkgs use the Depends field to do their job, 
they are removed from the system whenever one of the pkgs they "Depend" 
on is removed. 

The problem #2: Meta pkgs in debian are one way.  Removing a meta pkg 
doesn't remove or even check for the pkgs it installed to see if they 
are no longer dependent on anything or ask the user if they want to 
remove them.  Because of problem #1, removing a meta pkg isn't even 
possible if you remove one of the pkgs it installed, because according 
to the system, the meta pkg is already uninstalled.



My proposed solution is to make meta pkgs use the Suggests field instead 
of the Depends field to cause frontends (dselect and i believe aptitude 
already support this) to either automatically or ask the user to install 
the pkgs the meta pkg is supposed to encompass.  This makes just as much 
sense when reading the control file as "Depends" does, and it doesn't 
really break the purpose of the Suggests field, no more than using the 
Depends field for meta pkgs does.   But, we get around the removal of 
the Meta pkg, when a pkg that was installed by it is removed, problem.  
Other than using the suggests field, nothing else changes, the only real 
userspace change you might want to make is to give apt-get the ability 
to install suggested pkgs (which isn't a totally bad idea regardless). 
(--suggest for example) 

The second problem is more controversial, and a bit complex, but not 
already solved mostly.  

Solution #1 : apt-get has very limited removal ability compared to 
something like debfoster.  The patch to debfoster would be to look at 
the pkg list field for the requested program to be removed and look at 
it's Depends and Suggests and create a list of those pkgs that are no 
longer being depended on, and allow the user to remove those it finds, 
automatically or not via a switch. 

Solution #2 : if we really want apt-get to remove meta pkg (it can't the 
current way it's done anyway), we can use our new argument (--suggest) 
with remove to tell apt-get to remove the pkgs in the "Suggests" 
field.   This isn't a necessary solution though, apt-get can't remove 
meta pkgs now anyway, so changing meta pkgs to "Suggests" wont affect 
apt-get in any way for remove. 

I personally would only consider debfoster for removing meta pkgs, since 
it requires some complexity for finding what's being depended on and 
already has flags for not selected non-libs and such.  Patching it would 
be much simpler than giving debfoster's features to apt-get (something 
that would be partly required to properly remove meta pkgs).



What this means : 
1.We can remove pkgs that a meta pkg installs, without removing the meta 
pkg (so we can later use debfoster to remove the rest, without 
remembering them all).
2. By using the Suggests field in the control file for the meta pkg, we 
already have out of box support for meta pkgs by dselect and aptitude.  
apt-get wouldn't be that hard to patch.
3. By using the Suggests field, non-aware pkg frontends wont break, 
there is no need to have them all updated at the same time, nor is there 
any problem with mixed old style and new style meta pkgs.  Using 
suggests wont be mutually exclusive with using Depends for meta pkgs, it 
just provides a way to remove pkgs it lists and still be able to remove 
the rest while keeping later code to remove the meta pkg from having 
dependency issues.
4. By using Suggests, we aren't reversing the dependency list when we 
use a frontend (like debfoster) to remove a meta pkg.  Of course this is 
just semantics, but it's an important one, reversing the Depends list is 
bad and could lead to problems.  Reversing the suggests list means there 
is no chance of circular dependency issues when removing, since the pkg 
manager doesn't use suggests as a dependency during resolution.


So we basically complete the meta pkg by making it possible to remove 
under all circumstances and install (install works now, without any 
changes with some common pkg installers), keep everything backwards 
compatible with older pkgs and pkg managing programs, keep the control 
file, installing and removing logically sane and all without having to 
add anything to the control file or change anything other than the 
frontends (and very little there needs to be done except maybe debfoster 
removal code...)


anyway, just an idea.  If people like it, i'll even work out a patch for 
apt-get to use suggests to install pkgs optionally, since that's a nifty 
feature anyway.  




--
To UNSUBSCRIBE, ema

Re: Meta pkgs in debian

[Ed Sweetman]

On Sun, Jan 22, 2006 at 20:31:53 -0500, Ed Sweetman wrote:
 


Ok, i'm not subscribed here so please cc me any responses directly.

Before I propose my suggestion I want to outline my issues with how meta 
pkgs are done currently. 
   



[...]

 

The problem #2: Meta pkgs in debian are one way.  Removing a meta pkg 
doesn't remove or even check for the pkgs it installed to see if they 
are no longer dependent on anything or ask the user if they want to 
remove them.  Because of problem #1, removing a meta pkg isn't even 
   



Aptitude does this per default.



So does debfoster, but how can aptitude remove the meta package, and
attempt to remove all the pkgs that were installed because of it, when
you removed one of those pkgs yourself before and that caused the pkg
manager to remove the meta pkg.

say you installed mymetapkg.  mymetapkg installs something the 
maintainer thought was really useful to it, but not interdependent with 
the rest of the pkgs.   Now you decide you dont want that nifty pkg that 
got installed when you installed mymetapkg, you remove it.  pkg manager
removes the pkg "mymetapkg" too because it depends on that nifty other 
pkg. Now a while later you decide you dont want mymetapkg because you 
hate it or whatever, now what do you do? Reinstall the mymetapkg pkg to 
remove it? Using the Suggests field instead of Depends ensures this is 
never a problem.  It fixes every issue there is with having meta pkgs 
use dependencies to get the other pkgs installed, without any drawbacks.



aptitude can't do this. so saying this is something aptitude can do is 
completely wrong.   If the pkg isn't installed, aptitude doesn't respond 
with any action when asked to remove it.


It just doesn't make as much sense to use depends than suggests.. 
aptitude already supports installing/retrieving via suggests, removing 
those installed real pkgs wouldn't remove the meta pkg with suggests, 
where as in depends it does.  This makes removal of the meta pkg 
possible (and it's installed pkgs) a much more straightforward and 
logical process later on, no regexps or state juggling or black magic is 
 required.   only the "simple" feature of removing suggested pkgs, 
perhaps via an argument/option similar to the one used to install 
suggested pkgs.


Suggests solves this annoying issue with meta pkgs with extremely minor 
changes to the way the pkgs are made (s/Depends/Suggests) and for 
removal, an argument/option that's selectable to tell aptitude to try 
removing suggested pkgs in the given pkg if they're installed.



Oh, and if i'm missusing Suggests when in fact, aptitude uses Recommends 
to install non-"depends" pkgs, then replace all my usages of Suggests 
with Recommends.



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

Re: Intent to package: umich-ldap / WNPP: Dermot Bradley probably not maintaining packages

[Ed Donovan]

Hi - 

(Excuse me if I'm cc'ing this around too much.)

I think Dermot Bradley isn't actively maintaining packages.  I sent mail
to one of his addresses, about packaging gated, a while back.  I didn't
hear from him, though I saw gated came off the WNPP list under his name
later on.  His packages in the archive are mrtg, libgd, libgd-dev, and
radiusd-merit (the last already tagged as an orphan); the most recent
date on any of them is July 24.  And I don't see any mails to -devel or
-user from him since July.  

So I think he's probably just gotten too busy, and you should go for it
with ldap, Brian.  :-)  

Philippe - hope it's reasonable to run this info by you.

Thanks all,

--
Ed Donovan  [EMAIL PROTECTED]



>>>>> "Brian" == Brian Bassett <[EMAIL PROTECTED]> writes:

Brian> Oops...  forgot about that doc.  Sorry for any
Brian> confusion. Brian

Brian> On Tue, 2 Dec 1997, Adam P. Harris wrote:

>>  [Brian Bassett <[EMAIL PROTECTED]>] I was wondering if
>> anyone was working on packaging the University of Michigan's LDAP
>> server and client suite.  I noticed that hamm does not contain
>> anything LDAP related and thought this might be a good addition.
>> 
>> According to the debian prospective packages list,
>> http://www.debian.org/doc/prospective-packages.html Dermot
>> Bradley <[EMAIL PROTECTED]> is working on that package.
>> 


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

Re: Intent to package: umich-ldap / WNPP: Dermot Bradley probably not maintaining packages

[Ed Donovan]

Dermot - 

(Just caught up with the list again; my Gnus setup caught your mail to
the list first and put the direct reply in the 'duplicates' bin.)

As the one making the speculations about your absence, I'm extremely
sorry.  I didn't mean to put you in a position of explaining yourself.
Some people on debian user had been sharing user-versions of mrtg; I got
the wrong idea, and thought I was facilitating further packaging work .
I'm much happier to see that you *are* still working on the project; do
excuse me.

--
Ed Donovan  [EMAIL PROTECTED]


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

Re: Debian AMD64 Archive Move

[Ed Cogburn]

On Friday 06 May 2005 11:22am, Joerg Jaspert wrote:
> Hi
>
>  Note: non-free is NOT provided yet. We need to decide what we do with
>  it, as we may be forbidden to distribute some of the software in it (we
> aren't Debian).


Wait a second, if you *aren't* Debian, it should be *easier* for you to 
provide non-free, not harder.  The only problem with non-free is the internal 
politics of Debian.  Ubuntu certainly doesn't have any problem providing 
access to, but not support for, non-free.  If you're having problems that 
even Debian doesn't have, that sounds a little disturbing.  Like you're 
adopting a militant position for the AMD64 port that was even rejected (by 
the vote to keep non-free) in Debian itself?  That's scary.  Just put up 
non-free, and we can eliminate "problem" packages as they are identified, 
rather than keeping ALL of non-free offline until "someone" (who?) is 
"satisfied" (according to what rules?) that non-free is "ok".  If its 
available from Debian's non-free repository then that is *by definition* "ok" 
for us, unless we are just now learning that the AMD64 port is going to take 
a more hostile position against non-DFSG software than even the minority 
within Debian itself?  What gives?



Nvidia users:  you can try getting the nvidia packages from Ubuntu at

deb http://archive.ubuntu.com/ubuntu/ hoary main restricted universe 
multiverse

I don't know if they're compatible with Debian, but since Ubuntu still has 
Xfree in their archive too, they *should* be.  I also don't remember which 
section they're in, probably 'restricted' but not sure.  If all else fails, 
we could use their "source" file for the nvidia binary packages, and see if 
that builds for us (its a wrapper around nvidia's package that builds it The 
Debian Way - but I haven't tried it yet).

The best thing is to keep the packages you have now until we find what's going 
on.


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

Re: Debian AMD64 Archive Move

[Ed Tomlinson]

On Sunday 08 May 2005 05:02, Joerg Jaspert wrote:
> On 10283 March 1977, Ed Cogburn wrote:
> 
> >>  Note: non-free is NOT provided yet. We need to decide what we do with
> >>  it, as we may be forbidden to distribute some of the software in it (we
> >> aren't Debian).
> > Wait a second, if you *aren't* Debian, it should be *easier* for you to 
> > provide non-free, not harder.
> 
> No, not beeing Debian makes it only harder, not easier.
> There may be stuff in it with "Yes, Debian is allowed to distribute it"
> - which makes it undistributable for anyone else, except he gets the
> same.
> Or stuff you aren't allowed to built and then distribute or whatever
> else some idiot thought about for his license.
> 
> > The only problem with non-free is the internal politics of Debian.
> 
> No.
> 
> > Ubuntu certainly doesn't have any problem providing access to, but not
> > support for, non-free.
> 
> I dont care what/how they do it. Maybe they analyzed it, or just ignore
> it and wait if someone plays law-games with them, i dont know.
> I dont want law-games for me or for our mirrors or for the place where
> we host the machine, thats not worth the stuff thats in there, so its
> not added right away.
> 
> > The best thing is to keep the packages you have now until we find what's 
> > going 
> > on.
> 
> Whats going on == someone needs to check it. Thats it.

That was the point made by Ed Cogburn.  Its already been checked in the other
arch!  If this is not the case please explain why.  Without that explanation I 
am
forced to agree with Ed - the problem are political...  Which is the bane of 
debian.

Ed Tomlinson


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

Re: Debian AMD64 Archive Move

[Ed Tomlinson]

On Sunday 08 May 2005 09:27, Joerg Jaspert wrote:
> On 10283 March 1977, Ed Tomlinson wrote:
> 
> >> Whats going on == someone needs to check it. Thats it.
> > That was the point made by Ed Cogburn.  Its already been checked in the 
> > other
> > arch!  If this is not the case please explain why.  Without that 
> > explanation I am
> > forced to agree with Ed - the problem are political...  Which is the bane 
> > of debian.
> 
> We are *NOT* Debian, thats all you need to get!

Ok.  So from what I understand you are worried there are packages that debian 
can
distribute but only debian has the permission...   If this is the case is there 
not a way
you can ask debian to distribute just the non free stuff?  ie.  This project 
builds the
packages from debian sources, debian hosts the non free stuff on one of their 
servers.

Thanks
Ed Tomlinson


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

Re: Debian AMD64 Archive Move

[Ed Cogburn]

On Sunday 08 May 2005 9:27am, Joerg Jaspert wrote:
> On 10283 March 1977, Ed Tomlinson wrote:
> >> Whats going on == someone needs to check it. Thats it.
> >
> > That was the point made by Ed Cogburn.  Its already been checked in the
> > other arch!  If this is not the case please explain why.  Without that
> > explanation I am forced to agree with Ed - the problem are political... 
> > Which is the bane of debian.
>
> We are *NOT* Debian


We ARE Debian for Heaven's sake!  This move to another server is just 
TEMPORARY!  We WILL be Debian as soon as sarge gets out and development on 
etch picks up.  Who in the world is going to get upset when they know we will 
soon be part of official Debian, and they've already given permission for 
Debian to distribute their stuff!  Get real people!

How many non-free packages have been cleared?  Why haven't you at least set up 
non-free and moved the packages known to be ok into it?  I know for sure that 
the rogue-like games in non-free are perfectly fine and can brought on-line 
now, since they and a lot of other stuff is in non-free just because they are 
"old" pre-GPL software with "don't sell for money" restrictions which make 
them fail the DFSG test on distribution, but are otherwise fully open-source 
(and who's earlier authors can no longer be found to ask them if they'd agree 
to a change to the GPL or some other Free license).

In fact, looking through the non-free docs section, most of that can go in 
right now because they don't require anyone's permission to distribute since 
they're in non-free because of the dispute between Debian and FSF over 
documentation.


> thats all you need to get!


Hogwash.  This sounds like an extremely defensive response.  How many packages 
have been cleared for non-free?  Why haven't you just put up a non-free 
section with the stuff thats been cleared?  Why has it been more than a week, 
with no non-free section at all, no indication of how the "vetting" process 
is going, and with you telling us above that we don't need to know anything 
more?  Now do you understand why I'm just a little bit skeptical?

Just establish the non-free section and move everything over.  If anyone 
complains then just drop the package they're complaining about.  Of course, 
NO ONE is going to complain since they know we will "become" Debian soon 
anyway (and for all intents we ARE Debian - just not on their server), and 
they've already given Debian permission to distribute.  For the rest of 
non-free, permission to distribute is not an issue, and not the reason 
they're in non-free to begin with.

Re-evaluating non-free is just silly when we're going to "officially" become 
Debian again in a few months, certainly less than a year, anyway (assuming 
Debian gets Sarge out soon).  Heck, Debian doesn't even advertise us, we're 
the bastard child they don't want to talk about, because when they do it 
reignites the argument about which architectures to "officially" support, and 
why... and why not.  NO ONE IS GOING TO CARE ABOUT OUR NON-FREE!


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

Re: Debian AMD64 Archive Move

[Ed Cogburn]

On Tuesday 10 May 2005 11:19am, Goswin von Brederlow wrote:
> Ed Cogburn <[EMAIL PROTECTED]> writes:
> > On Sunday 08 May 2005 9:27am, Joerg Jaspert wrote:
> > In fact, looking through the non-free docs section, most of that can go
> > in right now because they don't require anyone's permission to distribute
> > since they're in non-free because of the dispute between Debian and FSF
> > over documentation.
>
> Will you pay us for the work and cover legal fees if any should arise?


Sure.  Because any rational person knows it won't happen.  Give us one 
reasonable example of why some one would waste time and money to sue the 
amd64.debian.net server owner in this matter, when they have absolutely 
nothing to gain, and potentially a lot to LOSE if the judge gets angry about 
the pointlessness of their suit?  This would happen in Germany, and the 
German judicial system hasn't yet become as screwed up as the American 
system.  Besides, by the time they FIND OUT, we'll be officially part of 
Debian anyway!


> Seriously, get some patience and don't inflame the situation
> please. Things like "most of that" is of zero help in deciding what
> can go in and what not. We know most of it can, the question is what
> packages are those in particular. We can't just add all of non-free
> and say it is mostly OK.


Yes you can.  That's my point.  Non-free has already been vetted by Debian 
itself, and we are part of Debian.  Any rational judge will see that, if 
given evidence by the Debian organization itself (see below).


> > Just establish the non-free section and move everything over.  If anyone
> > complains then just drop the package they're complaining about.  Of
> > course, NO ONE is going to complain since they know we will "become"
> > Debian soon anyway (and for all intents we ARE Debian - just not on their
> > server), and they've already given Debian permission to distribute.  For
> > the rest of non-free, permission to distribute is not an issue, and not
> > the reason they're in non-free to begin with.
>
> The pine author would for one thing.


Then load everything up but pine, if that's the only one you know of.  I've 
already listed more packages that I know about, and I'm "just" a regular 
user.  I'll bet if you had asked on d.d you could have quickly put together a 
list of 30 - 50 packages which were ok.  So why nothing in over a week?  Are 
you holding up all of non-free just because of 1 package?

And what is the point?  We are Debian.  It doesn't matter which server we're 
on.


> It will be at least 18 month going by the release plans till etch will
> be stable and sarge amd64 can be dropped. Considering the track record
> of past timelines 2-3 years is probably more accurate. That is a long
> time for someone to start suing.


Hogwash again.  We aren't talking about *release* dates, Goswin, we're only 
talking about how long it takes before debian.org is ready to move the amd64 
port onto it.  Once sarge is out, everybody can get back to moving *forward*, 
as opposed to running in place right now, which means the ftpmasters of 
debian.org can do what they need to do to make room for pure64 *Sid*, and 
move it over so we get synced up as Etch.  Sarge can stay where it is, that's 
not the issue.  Getting the *next* Debian AMD64 port onto debian.org is not 
going to take 3 years.


> In one point you are right though:
>
> NO ONE IS GOING TO CARE ABOUT OUR NON-FREE! None of us anyway. With
> the exception of nvidia* package it seems. That is the only package
> that users missed so far.


Right, only the relatively few users of this technically unofficial and mostly 
unknown-to-the-world official Debian port have noticed you left non-free 
behind.  So explain to us why you believe any copyright holder of one of 
these problem packages OUTSIDE OF DEBIAN is going to find out about this, and 
for some irrational reason bothers to sue amd64.debian.net, because it isn't 
on debian.org (but its contents *is* Debian)?  Geez, compared to that, I'd 
say me getting hit by a meteorite when I next leave my apartment is a 
guaranteed certainty... heck, let me go write my will before I go to the 
grocery store.

All you need is official blessing from Debian proper, in writing, or at least 
publicly announced on the net, that yes, the AMD64 port on amd64.debian.net 
is officially part of Debian, and isn't on debian.org only because of 
technical problems, but will be physically integrated soon (which is all 
true).  With that, you don't have to worry about any lawsuits.  So please 
stop with this weird excuse.


> Please excuse us for not giving it higher 
> priority than fixing RC bugs or otherwise vital archive mainta

Re: Debian AMD64 Archive Move

[Ed Cogburn]

On Tuesday 10 May 2005 3:22pm, Joerg Jaspert wrote:
> On 10285 March 1977, Ed Cogburn wrote:
> >> Will you pay us for the work and cover legal fees if any should arise?
> >
> > Sure.  Because any rational person knows it won't happen.
>
> Laywers arent rationale.
>
> > Give us one reasonable example of why some one would waste time and
> > money to sue the  amd64.debian.net server owner in this matter, when
> > they have absolutely nothing to gain, and potentially a lot to LOSE
> > if the judge gets angry about the pointlessness of their suit?
>
> With that logic: Why does SCO still exist?


All laywers are rational enough to know to not waste their time going after an 
organization THAT DOESN'T HAVE A BILLION DOLLARS.  That's why nobody is going 
to care, Debian is broke anyway, there is no point in a lawsuit.


>
> > Yes you can.  That's my point.  Non-free has already been vetted by
> > Debian itself, and we are part of Debian.  Any rational judge will see
> > that, if given evidence by the Debian organization itself (see below).
>
> No we cant. Just get a CLUE, we are *NOT* debian. We are as similar as
> one can get, but the Debian stuff is on .d.o hosts.


What difference does it make where we are located if Debian itself says we're 
part of them?


> > user.  I'll bet if you had asked on d.d you could have quickly put
> > together a list of 30 - 50 packages which were ok.  So why nothing in
> > over a week?  Are you holding up all of non-free just because of 1
> > package?
>
> No. Because of all the crap that is in there and because WE HAVE MORE
> IMPORTANT THINGS TODO - which includes reading crap from someone who
> just trolls on lists and not does any work for it.


Nobody did any work before because it wasn't necessary.  Now you're telling us 
there has been no work done at all on non-free.  So you guys really had no 
plan at all to get non-free moved over, did you?  So why didn't you just say 
that to begin with?


>
> > And what is the point?  We are Debian.  It doesn't matter which server
> > we're on.
>
> We arent, get a clue.


I'm not the clueless one here.


>
> > Hogwash again.  We aren't talking about *release* dates, Goswin, we're
> > only talking about how long it takes before debian.org is ready to move
> > the amd64 port onto it.  Once sarge is out, everybody can get back to
> > moving *forward*, as opposed to running in place right now, which means
> > the ftpmasters of debian.org can do what they need to do to make room for
> > pure64 *Sid*, and move it over so we get synced up as Etch.  Sarge can
> > stay where it is, that's not the issue.  Getting the *next* Debian AMD64
> > port onto debian.org is not going to take 3 years.
>
> Hell, please go and read what amd64.d.n is and you would see what a mess
> you just wrote. amd64.d.n will exist as long as Sarge is there.


And I've said twice now that I'm not talking about Sarge, I'm talking about 
Sid.  This has nothing to do with release dates on anything, its just about 
co-location of the port and non-free.


> And actually there was one who just went over the non-free crap, looking
> at the licenses, giving us something to work with.
> If non-free is so important for you - why did you wasted time writing
> such mails and havent done that work yourself?


Because the work has bloody well already been DONE!  Everybody knows we are 
destined to return to debian.org, and we ARE Debian now in all but a 
technicality, a technicality that won't make a bit of difference in court and 
goes away with a simple statement from Debian that we are part of them, just 
not on their servers yet.  But you guys never bothered to ask, you just threw 
out non-free without thinking about it, because it was something you wanted 
to do anyway.


>
> Thats my last mail in this thread, I have more important things todo.


Yea, like annoying users by leaving non-free behind just because you're still 
mad that the DDs voted to keep it.  Sure.


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

Re: Debian AMD64 Archive Move

[Ed Cogburn]

On Sunday 08 May 2005 4:23pm, Goswin von Brederlow wrote:
> Ed Tomlinson <[EMAIL PROTECTED]> writes:
> > On Sunday 08 May 2005 09:27, Joerg Jaspert wrote:
> >> On 10283 March 1977, Ed Tomlinson wrote:
> >> >> Whats going on == someone needs to check it. Thats it.
> >> >
> >> > That was the point made by Ed Cogburn.  Its already been checked in
> >> > the other arch!  If this is not the case please explain why.  Without
> >> > that explanation I am forced to agree with Ed - the problem are
> >> > political...  Which is the bane of debian.
> >>
> >> We are *NOT* Debian, thats all you need to get!
> >
> > Ok.  So from what I understand you are worried there are packages that
> > debian can distribute but only debian has the permission...   If this is
> > the case is there not a way you can ask debian to distribute just the non
> > free stuff?  ie.  This project builds the packages from debian sources,
> > debian hosts the non free stuff on one of their servers.
>
> Who is to say we are allowed to build the binaries?


This isn't an answer to his question.  He's saying why not let the AMD64 
non-free be distributed from a Debian server, since you're original excuse 
was that "you aren't Debian".  The answer is of course that you never even 
bothered to ask "Debian" for help or for a statement about your identity that 
would eliminate any theoretical legal threat.  Hell, you could have just kept 
non-free on alioth and linked to it from AMD64's new location until a 
solution to the problem was found since non-free by itself is very small and 
the move away from alioth was because of space reasons, but no, even keeping 
the old location temporarily wasn't acceptable, non-free had to go, period.  
You saw a chance to get rid of non-free, even though its temporary, even 
though a majority of DDs have officially disagreed with you in a vote, and 
its only result is to annoy the AMD64 users until AMD64 returns to a "Debian" 
server, all because of your extremist ideology.

I've been using Debian since pre-1.0 days when I got it off an Infomagic CD 
when I didn't have regular net access, but the times have changed, certainly 
the people around Debian have.  I never would have thought that Debian would 
reach the point where it would deliberately and **pointlessly** annoy its own 
users because of software religion, instead of just trying to produce the 
best Linux distro possible, but its apparently come to that.  No wonder 
Ubuntu looms large over Debian now, they're taking the best of Debian, but 
leaving behind the religious wars, and they will now gain strength and speed 
as Debian slows down due to endless religious infighting.  Anyway, its been 
fun, but its time to move on now, apparently.  Goodbye all.


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

Re: Re: new version breaks some uses of unput()

[Ed Himwich]

Okay maybe defining the function in the rules section does solve the 
problem. However, this can have the effect of putting bug hunks of C 
code in the rules section. This would seem to be bad coding style as 
already suggested. It would seem that (at least one of) the uses of the 
"user code" section is to make it possible to avoid this.


Is undefining these items (like yytext_ptr) at the end of the rules just 
being fastidious or is it really necessary for the new functionality?


Manoj Srivastava wrote:

On Tue, 15 Apr 2003 12:44:49 -0400,
Joey Hess <[EMAIL PROTECTED]> said: 


 > Manoj Srivastava wrote:
 >> Flex sets up a number of things that are available in the rules
 >> section, and now cleans it all up before polluting the user
 >> namespace. Now, actions can be any C statement, but using
 >> functions that in turn use flex macros is going to be a problem
 >> since declaring the function is going to be problematic.
 >>
 >> Some of these changes were driven by the need to make flex
 >> scanners reentrant, others by hte requirements for having multiple
 >> scanners, perhaps with different options, in the same program.

 > It seems to promote bad coding style to require that reasonable
 > little functions like this:

 >   eos() {
 >   if (yytext[yyleng-1] == '.')
 >   dintI();
 >   else
 >   yyunput(yytext[yyleng-1], yytext);
 >>

 > Must be inlined into the rules block or defined as macros or
 > something, instead of just being defined as regular functions.

	Not quite. 
--

   In the rules section, any indented or %{ %} enclosed text appearing
before the first rule may be used to declare variables which are local
to the scanning routine and (after the declarations) code which is to be
executed whenever the scanning routine is entered.  Other indented or
%{ %} text in the rule section is still copied to the output, but its
meaning is not well-defined and it may well cause compile-time errors
(this feature is present for POSIX compliance. See *Note Lex and Posix::, for
other such features).

   Any _indented_ text or text enclosed in `%{' and `%}' is copied
verbatim to the output (with the %{ and %} symbols removed).  The %{
and %} symbols must appear unindented on lines by themselves.
--

I'll attach a file at the end that uses functions once
 again. Just the placement of these function definitions has changed.

 >> > Oh and why do I need an expliciy main() and yyweap() function
 >> > now?  This code always worked before with flex generating stub
 >> > functions automatically. The real code is in the filters
 >> > package, in cockney.l, jive.l, and others.
 >>
 >> With multiple scanners now possible in the same program, flex
 >> would not know where to put main, obviously, it shoulkd not
 >> generate stubs in all the scanners generated.
 >>
 >> What is yyweap?

 > Typo for yywrap.

   You must supply a `yywrap()' function of your own, or link to
`libfl.a' (which provides one), or use


 %option noyywrap

   in your source to say you don't want a `yywrap()' function.

manoj


%{
/* COMMENT: code block */
%}

%option noyywrap
/* COMMENT: Definitions Section */
BW [ \t\n]
SP [ \t]+
EW [ \t.,;!\?$]
%%
  /* COMMENT: Rules Section */
%{
/* COMMENT: Define function */
void foo () { unput(yytext[yyleng-1]); }
%}
foo  /* COMMENT: after regex */   foo(); /* COMMENT: after code block */
 /* COMMENT: Rules Section (indented) */
%%
 /* User COMMENT: Code Section */
int
main(void) {
yylex();
}

--



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

Bug#4381: (no subject)

[Ed Petron]

This problem has been fixed but can anyone tell me how to get the
maintainer changed from "unknown" to myself since I'm the maintainer.
Thanks.
-- 
Ed Petron
[EMAIL PROTECTED]
http://www.leba.net/~epetron

Re: anarchism_7.7-1.deb

[Ed Boraas]

> Taking the risk to burn like hell: I think the "exhaustive exploration"
> of ANY political theory and practice is VERY misplaced in ANY Linux
> distribution. I would say the same thing about "The top 1000 FAQ on
> home-made apple pie", but nobody has packaged that (yet).
>
> To give a positive formulation: documentation and data packaged in ANY
> Linux distribution should either directly relate to (at least) computing
> in general or be the input to an also-packaged program (that does more
> with it than a little bit of formatting so it reads nicer).

Well, it looks like the Anarchist FAQ debate has come to life once again.
Just for the record, I packaged this for a number of reasons, including:

- It interests me
- It interests many "geeks" (to use the katzian term) whom I know
- It's a GPL-licensed, open project.

I'm fully willing to move the document to the data section when it comes
into existence, but in the mean time it will live in main, along with the
other non-computer-related electronic texts.

For free software,
ed.

Re: anarchism_7.7-1.deb

[Ed Boraas]

On Sat, 25 Sep 1999, Jaldhar H. Vyas wrote:

>Some packages are "worth" more than others.  Worth is often hard to define
>but not impossible.  Debian may not want to get into the definition
>business but that doesn't mean it can't be done and circumstances may
>force it too. 

I can't help but infer from this statement that you feel the anarchism
package is of low worth. If this was not your intent, please feel free to
clarify. In any case, I would like to respond to your message.

The concept of "worth" is by its nature a qualitative assesment, and
therefore subjective. I would be inclined to say that it would be
impossible to correctly judge the worth of a given package. Nevertheless,
there are other properties we can consider: general "quality" and "fitness
for a particular purpose". For instance, if a package is ridden with bugs
(be they shortcomings in code, or grammatical errors in text), one could
judge it to be of low quality, possibly low enough to warrant removing it
from the distribution. Contextual fitness, on the other hand, rates a
package as having "worth" in a particular situation. Sure, the anarchist
FAQ may not be useful in learning to write applications in GTK+, but that
doesn't mean it's not applicable to debian's userbase. 

Probably many users of debian will never find use for the anarchism 
package. So be it. The fact remains that there are quite a few debian
users who do find it useful. [The number of emails i got when i was late
packaging the most recent version of the FAQ is testament to that. ]

>Yes but the maintainer should also ask
>
>- Does it enhance Debian?

I agree with you completely. If you were referring to the anarchism
package in this statement, I would like to mention that I asked myself
that very question before i packaged anarchism. I thought it did -- and i
still do -- and the last time the debate over this package emerged, the
number of fellow debian maintainers who volunteered to take over the
maintainership of the package should i bend to the wishes of those who
wanted it removed greatly reinforced this judgment in my mind.

>This has been a bit of a rant.  Let me try and add something constructive.  
>It looks like we are going to 3 CDs.  In the future we will only get
>bigger.  How do we manage that growth while not irritating users (swapping
>CDs sucks) or censoring maintainers?  
>
>One approach which has been suggested is to make extra cds by section.  
>So a data CD could include the bible, anarchy FAQ etc. Perhaps at some
>point there will be a ham radio cd, electronics cd etc. This has the
>advantage of being infinitely extensible but I worry that it narrows the
>scope of Debian for the general user as most CD vendors especially the
>cheap ones will probably not bother with the extra CDs.

I've supported this direction in the past, and will continue to do so.
Rather than narrow the scope of debian, however, I think it could actually
serve to widen it -- imagine, in the case of textual works, a "debian
bookshelf" CD of dfsg-free literary works, all ready to be integrated with
the rest of the system with one simple call to apt-get. Similiarly, other
special-interest collections could emerge: a CD for amateur radio
enthusiasts, a CD for research scientists, etc. It's essentially just
modularity at the distribution level -- and the freeness of debian allows
even the most esoteric collections to be published in short runs and
obtainable at a reasonable cost, even without access to a CD writer or an
internet connectoin.

>The big fly in the ointment is how to decide what gets into the core
>because as you point out, it is very subjective.  I think the
>popularity-contest is a good way to help with this. 

I agree. I also believe that maintainers of the individual packages should
be trusted to have enough common sense to place their package in the
section in which it fits best. Even for those few hypothetical developers
who may feel an ego boost by pumping limited-utility packages into the
core distribution, the BTS can serve as a means to encourage them to
rectify their position.

In any case, I appreciate your comments.

For free software,
Ed.

Procedure Questions

[Ed Petron]

Hello,
I'm almost ready to upload a new release of PCCTS. It is based on a
new
upstream version in addition to containing some bug fixes. Also, the
upstream source now also includes sorcerer and is seems appropriate
to
include sorcerer as part of PCCTS. The questions that I have are:
1. Who needs to be contacted about removing the sorcerer package?
2. Should I, at least temporarily, put include a package conflict for
sorcerer in PCCTS?
Thanks.
-- 
Ed Petron
[EMAIL PROTECTED]
 

Procedure Questions

[Ed Petron]

Hello,
I'm almost ready to upload a new release of PCCTS. It is based on a
new
upstream version in addition to containing some bug fixes. Also, the
upstream source now also includes sorcerer and is seems appropriate
to
include sorcerer as part of PCCTS. The questions that I have are:
1. Who needs to be contacted about removing the sorcerer package?
2. Should I, at least temporarily, put include a package conflict for
sorcerer in PCCTS?
Thanks.
-- 
Ed Petron
[EMAIL PROTECTED]
 

ITP(?): Interbase 6

[Ed Boraas]

Hi there. I'm planning on packaging Interbase 6, when it's released. I
haven't seen any ITPs on this yet, but if someone else was planning on
doing this, please let me know.

Interbase 6 is (will be) an MPL-licensed SQL92-Compliant database.
A non-free (but free beer) "Public Field Test" has recently been released
in binary-only form, and can be found at www.interbase.com. I have no
plans to package any non-free releases of IB6, but if people feel strongly
about it, I may be convinced to investigate the legality (not sure if
redist is permitted) of it and package it.

Take care,
Ed Boraas <[EMAIL PROTECTED]>

Re: A "progressive" distribution

[Ed Szynaka]

I really don't think that a "progressive" branch is necessary.  The
problems involved in keeping track of three branches at one time and
trying to keep version dependencies in order between branches would far
out weigh any benefit that would be created by such a branch.  IMHO the
structure (stable, frozen, unstable) is more than adequate.

The problem that I see is that there is too much time between stable
releases.  I think that shorter and much more regular time periods
between freezes is necessary.  By fixing the number and date of freezes,
with say three or four a year, and letting everyone know long in advance
of the freeze it would allow developers to schedule when all bugs must
be removed by.  Also the fact that the time period would be much shorter
would make changes between stable versions less drastic and therefore
easier to handle.

Ed

"Bernhard R. Link" wrote:
> 
> After reading this nice diskussion with all it's aspects, I want to
> complete the mess and suggest a "distribution" called
> e.g. "progressive" beetween stable(frozen) and unstable.
> 
> As I understood the problem, at the moment, only the stable
> distribution is able to be distributed, while the unstable branch is to
> unstable and there's no distrubution in between. (To simplify I count the
> frozen as stable short before release here.)
> 
> When potate becomes stable, a branch called e.g. "progressive" could be
> created between the branches "stable" and "unstable". This branch (sorry
> for using this term, but I don't like distribution so much) would start
> with the modules from stable and subsets of unstable would be added, if
> they are usable. The term subset I use for  packages that contain together
> like one ore more basis packages (libc,xfree,perl,... or just something
> like emacs) and those packages depending on this basis package. (Note that
> I mean basis as basis of dependencies not basis of the whole or larger
> parts of distribution)  And usable shell mean, that this package can be
> used for average use without the need of Debian-like-tability.
> 
> With the next freeze, this "progressive" branch could be copied to
> "froozen" and new useable packaged from unstable would go to
> "progressive", while those in frozen are kept and only made more
> stable.
> 
> Doing this there would be a distribution in between, where new versions of
> products can reside and easily be used. Someone should be easily use a
> snapshot of progressive at an good moment to form a not-so-stable but
> up-to-date unofficial release, which could also be called less inoffical,
> if there is a common will for this.
> 
> Though some advantages this would cause at least two problems:
> 
> On the one hand this proposal would prohibit the current way of
> naming, because with any release a new distribution is created beetween
> stable and unstable, so some branch would change name and the old name
> would be used for a possibly totally other branch. So unstable( and
> perhaps progressive) had to be without name and just be "unstable".
> This coresponds to the loss of a cycle for the whole
> distribution. Changes would start in unstable and go through the phases of
> unstable, progessive and froozen before they become stable.
> 
> On the other hand would this proposal multiply the number of branches to
> up to four when there will be the next freeze and
> stable,frozen,progressive and unstable beeing all together. This made me
> the most headacke, but I think it's not so much of a problem, as many work
> to make the frozen version of his package will seriously prevent him from
> working so much on the unstable version, that this could become
> "usable". So most packages would be either the same in frozen and
> progressive or they would be same in progressive and unstable.
> 
> Hochachtungsvoll,
>   Bernhard R. Link
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: A "progressive" distribution

[Ed Szynaka]

> On Wed, Mar 15, 2000 at 02:36:47PM -0500, Ed Szynaka wrote:
> > The problem that I see is that there is too much time between stable
> > releases.  I think that shorter and much more regular time periods
> > between freezes is necessary.  By fixing the number and date of freezes,
> > with say three or four a year, and letting everyone know long in advance
> > of the freeze it would allow developers to schedule when all bugs must
> > be removed by.  Also the fact that the time period would be much shorter
> > would make changes between stable versions less drastic and therefore
> > easier to handle.
> 
> How does this account for drastic changes to something like libc that
> might take weeks or months to shake out?

Well say that there are 3 releases a year.  That gives say 3 months for
devel.  With a freeze scheduled to start at the beginning of the 4th
month and a stable release at the end of a month of freeze.  I think
that even the most drastic changes can be worked out in the course of 4
months.  Now if something _can't_ be completed in that time frame just
postpone it until the next freeze.  Since the next stable would only be
4 months off the penalty for not making it into the stable isn't that
severe.

With only the 3 months of changes I don't think that a freeze will take
as long as it has with a 6 or even 12 month devel cycle.

Ed

Re: Debian conference in the US?

[Ed Cogburn]

Russell Coker wrote:
On Sat, 24 May 2003 09:51, Alan Shutko wrote:
The citizens of the US have a little more power than the rest of the
world, in that you have a *vote* as to who gets to fuck the rest of the
world.
Well, didn't work that way last time...

They got their second choice.

I never chose Little Napolean and he wasn't on my alternate list either. 
 Please stop assuming everyone in a given country actually agrees with 
what their government has done or is doing.  This is the most 
distressing aspect of this thread:  Debian is (supposed to be) a group 
of intelligent, like-minded individuals whose individual nationality or 
origin is largely irrelevent.  There should be only 2 requirements for a 
conference:  someone is willing to sponsor it, and enough people are 
willing to come to make it worthwhile.  This idea that conference 
locations need to be vetted based on the politics of the host country is 
dangerous and stupid.  What Debian is about has nothing to do with 
individual nations or their politics.  We should be better than this.

Re: Service stopping in prerm considered harmful

[Ed Falk]

For the nth time squared, an initscript MUST NOT FAIL to stop an already
stopped service.


How is it supposed to do that? The service isn't running, so can't be
stopped, therefore the script (if called to stop it) can only fail to stop
it...


If the service is already stopped, then the script should declare 
victory and return.  Am I missing something?  Clearly the purpose of a 
prerm script is to ensure that the service is not running so that it's 
safe to remove the software.  If the service is already not running, 
that sounds like it meets the criteria to me.



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

Re: plagiarism of reiserfs by Debian

[Ed Boraas]

Hello, all.
I've only just returned from spending the long weekend out of town.  Of 
course, I've awoken to find a rather large thread on debian-devel 
regarding attribution issues with my packages of reiserfsprogs. You can 
imagine my excitement :)

As a result, I've privately emailed Hans to try to resolve the issue. I 
would like to apologize to debian-devel for the traffic this has 
generated over the past few days.

In any case, I'll keep you posted. If you have any comments, concerns, 
or strong opinions, please feel free to email me directly. I would like 
to balance the wishes of the software's upstream authors with wishes of 
the package's users as well as possible, and would apprciate knowing how 
you feel. For instance, if Hans insists on retaining the complete 
sponsorship message verbatim, how strongly would you, as users of the 
package, feel about the issue?

Anyway, I'm confident that the issues will be resolved swiftly and 
amicably. If nothing else, I do intend to upload a new version of the 
package with the upstream README included (yes, that was an oversight), 
and the extra licensing clauses included in debian/copyright (which I 
had missed due to taking COPYING as authoritative), if no agreement on 
the sponsorship-message issue is reached in the next couple of days.

Ideally, I think, including the verbatim message in a separate file 
("SPONSORS"?) and including a reference to that file in mkreiserfs' 
output should serve as an acceptable balance. I'm willing to reconsider 
that position, however, if the authors and/or users disagree.

For free software,
Ed

Re: plagiarism of reiserfs by Debian

[Ed Boraas]

On Tue, 2003-04-22 at 13:57, Matt Zimmerman wrote:
> On Tue, Apr 22, 2003 at 09:58:08AM -0600, Ed Boraas wrote:
> 
> > As a result, I've privately emailed Hans to try to resolve the issue. I 
> > would like to apologize to debian-devel for the traffic this has 
> > generated over the past few days.
> 
> Thanks.  Could you perhaps share with us whether you were contacted about
> this previously (while you were away or otherwise), or whether the messages
> to debian-devel were your first encounter with this issue?

The messages to debian-devel were the first I'd heard from Hans. (The
messages he sent to debian-devel this weekend were Cc'd to me personally
[in addition to the list], however, if that's relevant to your
question.)

-Ed

Re: Debian conference in the US?

[Ed Cogburn]

Martin Schulze wrote:
Aaron M. Ucko wrote:
While convenient for american developers, there are rather a number of
non-american developers who will not set foot on American soil, due in
part to the DMCA and (I imagine) the apparent dangers to non-americans
coming into the country.
Two of the people I originally contacted said this too, but always in
the third person.  I ask again, who on this list actually still feels
this way?

I do.
Even though the US may be an interesting country for holidays, its
government has plastered so many limitations and violations of human
rights that I don't believe I'll ever visit the US again.

That's funny considering just how many people are risking their LIVES to 
get here.  Then again, maybe its not, maybe its an insult to the ones 
who've died trying to get here over the years.


 The DMCA is one problem.

One which is not just a US headache.  The "EU Copyright Directive" is 
coming next, so where will all you Europeans run to when that law 
eventually comes into force?  Greed among businesses is universal, there 
are plenty of European companies who love that Copyright Directive and 
are pushing it hard.  Yes, I know, only two EU members have enacted it 
so far, but there is too much Big Money behind it for it to fail, its 
just a matter of time (according to the 2 articles I read).  BTW, you 
are aware the DMCA lost its last case in court over here, right?  The 
story is not over, my gut says it will at least be amended eventually.


Surveillance and misuing personal data, e.g. gained from
the flight agencies are another one.

And this is also only a US problem?  What about the public surveillance 
camaras in Britian and elsewhere?  You think the Isrealis are laissez 
faire when it comes to who they allow on their planes?  Big Brother is a 
problem everywhere, its only a problem here now because 9/11 was used as 
an excuse for a power grab.  We have an independent judiciary that will 
eventually decide if they've grabbed too much.


 International politics is right another problem I dislike too much.

One bad President and all of America is suddenly evil?  At most he has 
only about 6 more years, and there's a real chance it will only be about 
2, but you've already written us all off huh, even though this President 
didn't even win the majority vote, you're lumping us all together as 
miscreants with no chance at salvation?  I dislike politics period, all 
governments tend to behave selfishly, erratically, and stupidly, but 
that doesn't mean I'm going to draw up a 
DO-NOT-VISIT-THIS-COUNTRY-BECAUSE-I-DON'T-LIKE-THEIR-LEADER list. 
That's just silly.

> I rather stay a free person in a free country.
So do I, and I like it just where I am.

So do we REALLY want to turn this thread into yet another exercise in 
America bashing?  If someone wants to sponsor a conference here, FINE, 
let them, for heaven's sakes!  Most of the ones doing the bitching here 
would likely not come anyway because of the expense of getting here. 
And if the Europeans want to have a conference of their own, FINE, let 
them, for heaven's sake!  Most Americans won't come not because we're 
boycotting French Fries, but because WE can't afford the travel either. 
 Its not like there is some rule that says we can only have one 
conference at a time.  This whole thread is getting ridiculous.

Re: SGI's xfs

[Ed Boraas]

> Previously Matthias Berse wrote:
> > Are there any plans in supporting the usage of SGI's xfs filesystem in
> > debian? Are there kernel patches available and/or userspace tools
> > being packaged?
> 
> The userspace tools have been in unstable for a while already actually.

And the kernel patches are in incoming.

-Ed

Re: Interbase status (ITP #83098)

[Ed Boraas]

> Hello,
>
> any news from the Interbase Debian packages?

It's coming, slowly. I'm also evaluating firebird packages.

The problem with InterBase specifically, is the curiosities involved in
doing a bootstrap build (as opposed to a build that depends on an
already-installed set of InterBase binaries).

Feel free to contact me offlist if you like.

-Ed

Re: XFS Kernel image packaging

[Ed Boraas]

> At this time being, there's no official XFS kernel images nor patches in
Debian, however there is xfsprogs as far as I know in Woody & Sid.  I am
willing to work on an XFS kernel floppy boot disk, but it would be pointless
cine a kernel image with XFS is bloated by about 300K if I'm not mistaken,
at least the ones on some of the machines I put XFS into.  There are
Reiserfs images avaiable however.
> I certainly would like to get a hold of some XFS based install disks if
anyone ever has done any with success.

kernel-patch-xfs is most certainly in woody and sid.

-Ed

Re: Bug#127252: -unstable compiled against the wrong libpng

[Ed Tomlinson]

I use debain.  As a debian user I am quite distressed at how this
bug is being treated.  I have watched the bug reports on this issue
and have created one (See 127215).  From my perspective the problem
seems to be the libpng3 changes the dependencies of qt2 and hense kde.
It seems the fix is not to revert/fix libpng but to fix the qt
dependencies however I get the impression that frustration is setting
in.  ie. did not create the bug so I should not fix it.  From a user
POV this is scary.  With something as complex as debain or even just
the kde tree this type of bug should be expected and _fixed_ quickly
even if the person repairing the bug is doing damage control.

Once the bug is _fixed_ then the developers can and should improve 
processes to make this sort of problem less apt to occur.

I would not consider it a bug if qt2 had failed to upgrade until all 
dependent apps had recompiled packages available - my system would
not have broken...  This would have also put pressure on package
owers to recompile.  As it stands now there seems to be little incentive
to recompile.  Look at 127215 - its closed but nothing is fixed.

Ed Tomlinson


Mark Purcell wrote:

> On Tue, Jan 01, 2002 at 06:50:03PM +0900, Junichi Uekawa wrote:
>> On Tue, 1 Jan 2002 19:39:07 +1100 Mark Purcell <[EMAIL PROTECTED]> wrote:
>> 
>> > The solution is rather simple, requiring recompilation to
>> > get the correct linkage to libpng3, but it would of been nice to
>> > see some dicussion on debian-devel before the upload of
>> > libpng3 to unstable 'broke' all our pacakges.
>> 
>> Do you call that solution pretty simple?
> 
> Well it is simple once you know about it.  I have two complaints as
> a maintainer of a couple of libpng dependant packages.
> 
> 1.Why hasn't there been any discussion on debian-devel to actually
> let maintainers know that there is this major backwards incompatibility
> issue,
> which is going to create all sorts of user problems.  The only reports I
> have seen sofar are Bug#126808 and Bug#126904.  Have a look in debian-kde
> 'where have my icons gone threads' to guage the amount of confusion this
> issue is causing.
> 
> 2.What measures are in place to prevent such a monster change
> as caused by the uncontrolled introduction of libpng3??
> 
> This is a big issue, I'm stll suprised there has been zero discussion
> about this and the implications for developers of libpng dependant
> packages.
> 
>> We have around 300+ packages depending on libpng2,
>> which amounts to more than 1000 rebuilds.
>> And we don't have the incompatibility information in
>> our dependency system, which means that it will fail to trickle
>> into "testing".
> 
> The incompatibility as I see it from here is that any application
> which depends on libpng2, is only good with libpng2 <= 1.0.12-2 and
> upon recompiling will be dependant on libpng3.
> 
> libqt 2.3.1-18 has been recompiled and now depends on libpng3, but almost
> every other package needs to be recompiled as well :-(
> 
> I understand that Philippe Troin, libpng maintainer, is currently on
> vacation.  Perhaps someone more knowledgeable about the libpng issues
> could comment as this is only what I have been able to gather from the
> outside looking in.
> 
> Mark
> 
> 

Re: getting kernel 2.2 into slink

[Ed Boraas]

On Thu, 21 Jan 1999, David Welton wrote:

>I think we should include it, as a service to people who don't want to
>download the whole thing, but attach a note saying "As 2.2 was
>released just before we released slink, we are including it, but there
>may be problems, it might eat your computer... we are not responsible
>for anything at all..."

I hate to sound like another "me too"-er, but I like that idea. I'm
running linux 2.2 on my slink box, and haven't had any problems -- but we
certainly don't have the time to test it extensively enough to make it an
official part of the distro (and the Deep Freeze would definitely make it
impossible). I'm sure including the image and source wouldn't violate the
Deep Freeze with a little bit of law-bending :)

-ed

pppd 2.3.5 (was RE: getting kernel 2.2 into slink)

[Ed Boraas]

On Thu, 21 Jan 1999, Brent Fulgham wrote:

>> The issue being that there IS a problem - e.g. are we going to provide
>> ppp1 and ppp2?  That sounds like trouble to me.
>>
>Real Question (not a snipe):  Is there any reason everyone couldn't use a
>current pppd that would be compatible with the new kernel image?  Why have
>two packages?

I don't see a problem at all: slink includes pppd version 3.3.5, which is
fully compatible with the 2.2 series of kernels. This being the case, the
kernel-2.2.0 package would simply need to depend on slink's pppd. Not a
big deal in the least... anyone running slink would have the required pppd
anyway!

-ed

Re: Debian logo & its license

[Ed Boraas]

On Sun, 24 Jan 1999, Wichert Akkerman wrote:

>I propose that we vote on accepting both the logo and the current
>license.

I think this is a good idea. If this proposal needs to be seconded,
consider this my "seconded!".

If it needs to be seconded somewhere else (debian-vote?) i'll do so
there :)

-ed

Re: Debian logo & its license

[Ed Boraas]

On Sat, 23 Jan 1999, Chris Waters wrote:

>Wichert Akkerman wrote:
>
>> I propose that we vote on accepting both the logo and the current
>> license.
>
>I very much dislike the current license.  I'm a debian developer, I'd
>like to put the debian logo on my home page, but I do *not* necessarily
>want to devote half or more of my home page to debian.  I'd rather have
>pointers to the debian web site, and let debian speak for itself. 
>Current (expired) license forbids this.
>
>I've previously raised issues about using the logo inside of packages
>too -- this one may be addressed by the current license, but it's
>certainly not clear.
>
>The logo should be a logo, it should be used to refer to or to advertise
>debian.  It should *mean* debian.  The current license isn't even
>*close* to filling this goal, imo.

[snip]

>Debian is a free project to distribute a free OS.  It should have a free
>logo.  FREE THE LOGO!!  FREE THE LOGO!!  :-)

well then, that's all the more reason to have a vote, imho. i personally
dislike the logo and agree with you about the license. since there are
enough people raising concerns about the logo, i think a vote is
warranted.

what do you think?

-ed

RE: Debian logo & its license

[Ed Boraas]

On Sat, 23 Jan 1999, Darren Benham wrote:

>
>On 23-Jan-99 Wichert Akkerman wrote:
>> I propose that we vote on accepting both the logo and the current
>> license.
>> 
>
>The current license?  Are you sure?  It needs to be rewritten if for no other
>reason but to remove the expiration date.

Note that the proposal is to vote *on* the license & logo, not necessarily
*for* it.

-ed

Re: NDN: Re: Time to rewrite dpkg

[Ed Breen]

Why am i continually getting this stupid message:

Post Office wrote:
> 
> Sorry. Your message could not be delivered to:
> 
> Jorge Araya (Mailbox or Conference is full.)
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

-- 
Ed Breen Informatics Research Leader
Proteome Systems Ltd  (www.proteomesystems.com)
+61-2-98891823 (5)
[EMAIL PROTECTED]
---

new package

[Ed Breen]

Hi,

I intend to make a deb package for my C interpreter EiC:

http://www.pobox.com/~eic

I have followed the howto and have made a debian package that
installs and purges fine. However, when I use alien to make
an rpm, and try to install the rpm I get a stack of dependency
problems:

failed dependencies:
/bin/sh   is needed by eic-4.0.1-2
ld-linux.so.2 is needed by eic-4.0.1-2
libc.so.6 is needed by eic-4.0.1-2
libm.so.6 is needed by eic-4.0.1-2
/home/edb/bin/eic is needed by eic-4.0.1-2
/usr/local/EiC/eic is needed by eic-4.0.1-2
/usr/local/bin/eic is needed by eic-4.0.1-2

but I have /bin/sh, ld-linux.so.2, libc.so.6. And I don't know
why it is reporting that last 3 dependencies. These just don't
make sense to me at all. I usually have EiC installed /usr/local
and in my home directory -- but I removed these before I
made the deb package, and I have searched the makefiles
and scripts in the package and I can't get any clues why
this is happening. I am using rpm  2.5.1-6, and slink.

Ed.

-- 
Ed. Breen
Email: [EMAIL PROTECTED]
 (http://www.pobox.com/~eic)
-

Bug#1034051: ITP: ripcalc -- simple network calculation and lookup tool

[ed neville]

Package: wnpp
Severity: wishlist
Owner: ed neville 
X-Debbugs-Cc: debian-devel@lists.debian.org, ed-deb...@s5h.net

* Package name: ripcalc
  Version : 0.1.6
  Upstream Author : Ed Neville 
* URL : https://www.usenix.org.uk/content/ripcalc.html
* License : GPL
  Programming Lang: (Rust)
  Description : simple network calculation and lookup tool

Calculate or lookup network addresses, then print results in a variety 
of formats.

Various datacenter audit/CMDB tools store reports in CSV, which can then 
be used as a source to lookup from. Ripcalc allows the end user to 
specify which parts of the CSV to include in output.

This will be maintained in the Debian Rust team.

Bug#1039943: ITP: linescroll -- simple tool to watch logfile throughput

[ed neville]

Package: wnpp
Severity: wishlist
Owner: ed neville 
X-Debbugs-Cc: debian-devel@lists.debian.org, ed-deb...@s5h.net

* Package name: linescroll
  Version : 0.1.2
  Upstream Contact: Ed Neville 
* URL : https://www.usenix.org.uk/content/linescroll.html
* License : GPL
  Programming Lang: Rust
  Description : simple tool to watch logfile throughput

Monitor log files for activity and display results via graph or 
statistics.

Useful for live comparisson of server access. E.g. cached vs uncached 
web access. Results can easily be displayed in a format suitable for 
email reports.

In need of sponsorship.

Bug#1012384: ITP: libtext-balanced-perl -- Perl module for extraction of delimited text from strings

[Ed J]

Package: wnpp
Severity: wishlist
Owner: Ed J 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: libtext-balanced-perl
  Version : 2.06
  Upstream Author : Damian Conway 
* URL : https://metacpan.org/pod/Text::Balanced
* License : GPL, Artistic, available at * 
/usr/share/common-licenses/{GPL,Artistic}
  Programming Lang: Perl
  Description : Perl module for extraction of delimited text from strings

Text::Balances provides various extract_... subroutines may be used to
extract a delimited substring, possibly after skipping a specified prefix
string. By default, that prefix is optional whitespace (/\s*/), but can be
changed.

Bug#802948: ITP: python-mmh3 -- Python wrapper for MurmurHash (MurmurHash3)

[Ed Swierk]

Package: wnpp
Severity: wishlist
Owner: Ed Swierk 

* Package name: python-mmh3
  Version : 2.3.1
  Upstream Author : Hajime Senuma 
* URL : http://github.com/hajimes/mmh3
* License : Public Domain
  Programming Lang: Python and C++
  Description : Python wrapper for MurmurHash (MurmurHash3)

This is a Python wrapper for MurmurHash (MurmurHash3), a set of fast and
robust hash functions.  mmh3 2.3.1 supports both Python 2.7 and 3.x.

python-mmh3 is a dependency of OpenStack per
https://wiki.debian.org/OpenStack/OpenStack/todo.

My initial attempt at packaging for Debian is at
https://github.com/skyportsystems/mmh3.  I have never created an official
Debian package and would need a sponsor for this package.

Re: An abrupt End to Debian Live

[Ed Dixon]

So sorry to hear this Daniel! I feel what they have done here is so wrong,
but I have noticed they are very totalitarian in their processes. To do
this to someone who has contributed so much though is really stupid on
their part! I will definitely be forking here as prior versions fit my
needs perfectly and I have no interest in being a part of whatever this is
they plan to change it into. I hope you do not mind the occasional question
every now and then. I owe you so much in addition to the great softwareI
feel like I have become friends here with you, Ben Armstrong, and
Challis. I am sure this is not the end of where your amazing talents take
you please keep me in the loop and THANK YOU.

Thanks,

On Mon, Nov 9, 2015 at 10:03 AM Daniel Baumann <
daniel.baum...@progress-technologies.com> wrote:

> [ I don't know why this post is not showing up on planet.debian.org:
> https://danieltmp.wordpress.com/2015/11/09/an-abrupt-end-to-debian-live/
> I am sending it here by mail now. ]
>
>
> An abrupt End to Debian Live
> 
>
> Debian can be great.
>
> But depending on who you are, where you come from, and who your friends
> are, Debian can also be hateful and full of deceit.
>
> Before even more of reality[0] is spin-doctored into some distorted[1]
> view of it, and before my past work is being discredited, I will take
> the high road and continue my work on Debian Live images on the outside.
>
> If there is one thing I did learn over the past years of agressions
> towards me, then that it is this: I am forced to blindly and
> unchallenged accept everything others decide about me or my work,
> resistence to the cabal is futile, anything goes, no[2] matter[3] what[4].
>
> Therefore, after having founded Debian Live back in 2006 and having by
> now almost 10 years continuously worked on it, without further ado:
>
>   Debian Live is dead, hijacked by the debian-cd and the
>   debian-installer Teams[5]
>
> The live.debian.net server will be shut down end of month, the Git
> repositories are read-only as of now and mirrored to GitHub[6] for
> archival.
>
> So long, and thanks for all the fish[7].
>
> Daniel
>
> [0] https://www.debian.org/News/weekly/2006/08/
> [1] https://lists.debian.org/debian-live/2015/11/msg8.html
> [2] https://bugs.debian.org/497471
> [3] https://bugs.debian.org/759189
> [4] https://bugs.debian.org/754910
> [5] https://bugs.debian.org/804315
> [6] https://github.com/debian-live
> [7] http://live.debian.net/project/downstream/
>
>

Re: [ralph.amis...@gmail.com: outrageous, thievery]

[Ed Dixon]

Be sure to share Daniels story via social media using the buttons on his
blog. I hope it wakes up the entire community to what happens when you
actually do something right around here! https://t.co/NwWs9AfW87 Thanks,

On Mon, Nov 9, 2015 at 2:15 PM Richard Newton  wrote:

> I agree, shame on those responsible. I have been using Debian for almost
> 15 years and this is the first time I have been ashamed. Add my name to the
> record "of conscientious objection."
>
> RIchard Newton
>
> On Mon, Nov 9, 2015 at 11:42 AM, Ralph Amissah 
> wrote:
>
>> I post not in anger but sadness, I should not let my voice go uncounted.
>>
>> Attached is my note to Daniel of earlier today, before his posting of
>> "an abrupt end to Debian Live". Debian Live which he said Debian should
>> have (as a Debian developer) in 2006 and went on to deliver, rather
>> nicely (with (and without) help).
>>
>> - Forwarded message from Ralph Amissah 
>> -
>>
>> From: Ralph Amissah 
>> To: Daniel Baumann
>> Subject: outrageous, thievery
>> Date: Mon, 9 Nov 2015 09:28:44 -0500
>> Message-ID: <20151109142844.GA28261@niu>
>> User-Agent: Mutt/1.5.24 (2015-08-30)
>>
>> Daniel, (already one of the more active Debian Developers then) I
>> remember you telling Debian at Debconf 2006, Mexico about how "we"[1]
>> needed a live-maker within the project. I said then that I thought this
>> one of the most important projects within Debian (I was surprised that
>> there was not more interest and effort offered by others at the time,
>> though there was some, those so keen now did not seem to pay attention
>> then).  Already then it was clear that it would one day be able to and
>> possibly be the preferred way to do a Debian install... as I said,
>> important. I saw how you contributed to Debian then, and I know how you
>> have contributed since. Instead of welcoming you and your work, there
>> seems to have been an effort to isolate you.
>>
>> Well clearly others have seen the fruits of your labor as a threat and
>> with envy, and ripe for their plucking!
>>
>> Outrageous! Disgusting. It is nasty. A bit strange to think that I
>> "know" some of those guys.
>>
>> My interest in Debian proper, dropped with your earlier treatment, it
>> took away the desire to be a closer part of it. At least that took out
>> much of any idealized notion of the inner workings of it. And there have
>> been other moves since. I continue to be amazed by the politics of
>> groups within Debian.  This though has the feel of blatant thievery.
>> Chals characterization of a dictatorial coup would seem to be most
>> accurate.
>>
>> It has no doubt to do with power (perhaps indirectly money is involved
>> as well), your work & work area being seen as strategically important.
>> They do it because they can, & justify it whatever which way they will.
>>
>> I am sorry. I feel pretty bruised on your behalf.
>>
>> We have not spoken in a long while. I hope we have the chance to talk in
>> happier times.
>>
>> Greetings.
>> Ralph
>>
>> P.S. We are ok, not much to report.
>>
>> - End forwarded message -
>> [edits: addition of footnote, &; s/picking/plucking/]
>>
>> Indeed I am a friend of Daniel and primarily a user of Debian (a minor
>> contributor of a package (sisu[2]) that I wrote that I am happy to have in
>> Debian). In other circumstances I would consider myself at least an
>> admirer of individuals involved on the other side of this. Indeed I (use
>> use some of your software daily and) have met a number of you over the
>> years at a number of Debconfs and have fond memories for example of
>> visits to Cambridge when I lived in the U.K. and of being "introduced"
>> to Debian by Debian insiders.
>>
>> Thanks to all who have stood up for Daniel, he is a wonderful, generous,
>> (and capable) person. And yes, I do think him "wronged" by "Debian".
>> There are others that know him pretty well, who have followed a fairly
>> long sequence of events who must be outraged as well.
>>
>> Of course I wish Debian well, but I do not see your "handling" of Daniel
>> as its finest hour. This will no doubt "blow over" as it must ultimately
>> for the good of the project, but it sticks in my craw as it no doubt
>> does others, and there should be some record of conscientious objection.
>>
>> Ralph Amissah
>>
>> [1] to be clear, "we" was Debian.
>> [2] http://www.sisudoc.org/
>> https://qa.debian.org/developer.php?login=s...@lists.sisudoc.org
>>
>>
>
>
> --
> CONFIDENTIALITY NOTICE: This electronic communication with its contents
> may contain confidential and/or privileged information. It is solely for
> the use of the intended recipient(s). Unauthorized interception, review,
> use, or disclosure is prohibited and may violate applicable laws including
> the Electronic Communications Privacy Act. If you are not the intended
> recipient, or authorized to receive for the intended recipient, please
> contact the sender and destroy all copies of the communication. Thank you
> for your co

Bug#816649: ITP: cloudabi-utils -- Utilities and libraries for starting CloudABI programs

[Ed Schouten]

Package: wnpp
Severity: wishlist
Owner: Ed Schouten 

* Package name: cloudabi-utils
  Version : 0.8
  Upstream Author : Ed Schouten 
* URL : https://nuxi.nl/
* License : BSD
  Programming Lang: C
  Description : Utilities and libraries for starting CloudABI programs

CloudABI is a Unix-like runtime environment that is purely built on the
concept of capability-based security. By using capability-based
security, applications become easier to test and reuse (due to its
similarity to dependency injection). It also makes applications more
secure, as processes only start up with a restricted set of rights.

The cloudabi-utils package provides two things:

1. libcloudabi: Native Linux versions of some of the APIs that are
   normally only available inside of CloudABI. More specifically, it
   provides ports of the functions that you normally call to launch
   CloudABI processes.

2. cloudabi-run: This utility uses libcloudabi to spawn CloudABI
   processes, providing it access to resources specified in a YAML
   configuration file.

More information about CloudABI can be found here:

- Official website: https://nuxi.nl/
- Talk at 32C3: https://www.youtube.com/watch?v=62cYMmSY2Dc
- C library source code: https://github.com/NuxiNL/cloudlibc
- Software ported to CloudABI: https://github.com/NuxiNL/cloudabi-ports
- Source code for cloudabi-utils: https://github.com/NuxiNL/cloudabi-utils
- Linux kernel modifications: https://github.com/NuxiNL/linux

As I am the author of this piece of software, I will maintain this
package myself.

Re: insurace_notice_for_ed_CVge

[ed nelson]

Would  like to here more
On Jun 29, 2016 4:08 PM, "Tollef Fog Heen"  wrote:

> fgh Never Pay for Covered Auto Repairs Again
>
> 9$/month
>
> Check now for Confirmation
>
>
>
>
>
> unSubHere
>
> 0Pt0utHere  
> 
> !@#$%^&@#$%*&
>
>

Bug#1093168: ITP: libpdl-fit-perl -- Fitting functions for PDL.

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libpdl-fit-perl
  Version : 2.099
  Upstream Author : PerlDL Developers 
* URL : https://metacpan.org/release/PDL-Fit
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Fitting functions for PDL.


Currently, only Levenberg-Marquardt, Gaussian, linear, and polynomial
fitting are implemented.
For a fairly concise overview on fitting see Numerical Recipes,
chapter 15 "Modeling of data".

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1093174: ITP: libpdl-graphics-simple-perl -- Simple backend-independent plotting for PDL

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libpdl-graphics-simple-perl
  Version : 1.015
  Upstream Author : Craig DeForest 
* URL : https://metacpan.org/release/PDL-Graphics-Simple
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Simple backend-independent plotting for PDL

PDL can plot through a plethora of external plotting modules. Each module
tends to be less widely available than Perl itself, and to require an
additional step or two to install. For simple applications ("throw up an
image on the screen", or "plot a curve") it is useful to have a subset of all
plotting capability available in a backend-independent layer.
PDL::Graphics::Simple provides that capability.

PDL::Graphics::Simple implements all the functionality used in the PDL::Book
examples, with identical syntax. It also generalizes that syntax - you can
use ::Simple graphics, with slight syntactical differences, in the same
manner that you would use any of the engine modules. See the Examples below
for details.

The plot you get will always be what you asked for, regardless of which
plotting engine you have installed on your system.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1093178: ITP: libpdl-io-envi-perl -- Read ENVI data into PDL

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libpdl-io-envi-perl
  Version : 2.098
  Upstream Author : PerlDL Developers 
* URL : https://metacpan.org/release/PDL-IO-ENVI
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Read ENVI data into PDL


The ENVI image format is a flat-binary raster file with an accompanying
ASCII header file. The data are stored as a binary stream of bytes in
one of the following formats, often referred to as the interleave type.
It is used for geospatial data. See
https://www.nv5geospatialsoftware.com/docs/ENVIImageFiles.html for more.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1093177: ITP: libpdl-gsl-perl -- PDL interface to the GNU Scientific Library

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libpdl-gsl-perl
  Version : 2.101
  Upstream Author : PerlDL Developers 
* URL : https://metacpan.org/release/PDL-GSL
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : PDL interface to the GNU Scientific Library


Provides:
  * PDL::GSL::CDF
  * PDL::GSL::DIFF
  * PDL::GSL::INTEG
  * PDL::GSL::INTERP
  * PDL::GSL::LINALG
  * PDL::GSL::MROOT
  * PDL::GSL::RNG
  * PDL::GSL::SF
  * PDL::Stats::Distr

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1093180: ITP: libpdl-io-gd-perl -- PDL interface to the GD image library

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libpdl-io-gd-perl
  Version : 2.103
  Upstream Author : PerlDL Developers 
* URL : https://metacpan.org/release/PDL-IO-GD
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : PDL interface to the GD image library


Provides both a function-orientated, and more recently an object-oriented
interface. Can produce files and data in both RGB-in-lowest dimension,
and X-and-Y-in-lowest dimension formats.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1093179: ITP: libpdl-perldl2-perl -- Simple shell (version 2) for PDL using Devel::REPL

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libpdl-perldl2-perl
  Version : 2.002
  Upstream Author : Chris Marshall 
* URL : https://metacpan.org/release/PDL-Perldl2
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Simple shell (version 2) for PDL using Devel::REPL

Uses Devel::REPL to provide a better understanding of Perl syntax than
the "perldl" shell provided in main PDL. Also enables being a genuine REPL,
where if an option is set, then the return values of each given command
are automatically printed out.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1093176: ITP: libpdl-io-dicom-perl -- Read 16-bit gray level Dicom images into PDL.

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libpdl-io-dicom-perl
  Version : 2.098
  Upstream Author : PerlDL Developers 
* URL : https://metacpan.org/release/PDL-IO-Dicom
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Read 16-bit gray level Dicom images into PDL.


As Dicom is an extremely complex format, this module can unfortunately
not handle all different image types included in the DICOM standard. One
common format that is currently not supported is the Papyrus format.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1093181: ITP: libpdl-transform-color-perl -- Useful color system conversions for PDL

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libpdl-transform-color-perl
  Version : 1.007
  Upstream Author : Craig DeForest 
* URL : https://metacpan.org/release/PDL-Transform-Color
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Useful color system conversions for PDL

PDL::Transform::Color includes a variety of useful color conversion
transformations. It can be used for simple hacks on machine-native color
representations (RGB <-> HSV, etc.), for simple encoding/decoding of
machine-native color representations such as sRGB, or for more sophisticated
manipulation of absolute color standards including large-gamut or perceptual
systems.

The color transforms in this module can be used for converting between proper
color systems, for gamma-converting pixel values, or for generating
pseudocolor from one or two input parameters. In addition to transforming
color data between different representations, Several named "color maps"
(also called "color tables") are provided.

The module uses linearized sRGB (lsRGB) as a fundamental color basis. sRGB is
the standard color system used by most consumer- to mid-grade computer
equipment, so casual users can use this color representation without much
regard for gamuts, colorimetric standards, etc.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1093185: ITP: libpdl-graphics-trid-perl -- PDL 3D interface

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libpdl-graphics-trid-perl
  Version : 2.099
  Upstream Author : PerlDL Developers 
* URL : https://metacpan.org/release/PDL-Graphics-TriD
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : PDL 3D interface

Provides a 3D plotting capability to PDL, using OpenGL.

Can currently plot lines, points, meshes, and arbitrary triangles, both
with and without smoothing.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1093184: ITP: libpdl-io-idl-perl -- Read IDL(tm) data files into PDL

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libpdl-io-idl-perl
  Version : 2.098
  Upstream Author : PerlDL Developers 
* URL : https://metacpan.org/release/PDL-IO-IDL
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Read IDL(tm) data files into PDL


Currently, only reading is implemented. Scalars, arrays, and structures are
all supported. Heap pointers, compiled code, and objects are not supported.
Of those three, only heap pointers are likely to be supported in the future.

This code was not developed by RSI, makers of IDL.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1093182: ITP: libpdl-transform-proj4-perl -- PDL::Transform interface to the PROJ library

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libpdl-transform-proj4-perl
  Version : 2.098
  Upstream Author : PerlDL Developers 
* URL : https://metacpan.org/release/PDL-Transform-Proj4
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : PDL::Transform interface to the PROJ library


Works like PDL::Transform::Cartography, but using the PROJ library.
Please see the proj library docs at http://www.remotesensing.org/proj for
more information on PROJ, and how to use the library.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1093186: ITP: libpdl-io-hdf-perl -- PDL interface to read and write HDF4 files with the SD, VS, and V interfaces.

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libpdl-io-hdf-perl
  Version : 2.003
  Upstream Author : PerlDL Developers 
* URL : https://metacpan.org/release/PDL-IO-HDF
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : PDL interface to read and write HDF4 files with the SD, VS, 
and V interfaces.


For more information on HDF, see http://hdf.ncsa.uiuc.edu/

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1093172: ITP: libpdl-graphics-colorspace-perl -- PDL implementation of Graphics::ColorObject

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libpdl-graphics-colorspace-perl
  Version : 0.204
  Upstream Author : Maggie J. Xiong  
* URL : https://metacpan.org/release/PDL-Graphics-ColorSpace
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : PDL implementation of Graphics::ColorObject


Does image color space conversions such as RGB to XYZ and Lab to
LCH. Derived from Graphics::ColorObject (Izvorski & Reibenschuh, 2005)
but since it's implemented in C and PDL, it runs *much* faster.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1093183: ITP: libpdl-opt-simplex-perl -- PDL implementation of simplex optimization algorithm

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libpdl-opt-simplex-perl
  Version : 2.097
  Upstream Author : PerlDL Developers 
* URL : https://metacpan.org/release/PDL-Opt-Simplex
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : PDL implementation of simplex optimization algorithm


The algorithm is to move a "simplex" of N+1 points in the
N-dimensional search space according to certain rules. The main benefit of
the algorithm is that you do not need to calculate the derivatives of your
function.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1101194: ITP: libopengl-glfw-perl -- Perl bindings for the GLFW library

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libopengl-glfw-perl
  Version : 0.04
  Upstream Author : Chris Marshall 
* URL : https://metacpan.org/release/OpenGL-GLFW
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl bindings for the GLFW library

OpenGL::GLFW provides perl5 bindings to the GLFW library for OpenGL
applications development. The implementation is a direct translation of the
GLFW C interface to perl. You can use the official GLFW documentation at
http://www.glfw.org/documentation.html for the specifics of the GLFW API.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1101193: ITP: libopengl-modern-perl -- Perl extension to Modern OpenGL API up to 4.5

[Ed J]

Package: wnpp
Owner: Ed J 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libopengl-modern-perl
  Version : 0.04
  Upstream Author : Chris Marshall 
* URL : https://metacpan.org/release/OpenGL-Modern
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl extension to Modern OpenGL API up to 4.5

OpenGL::Modern provides perl bindings to the OpenGL graphics APIs using
the OpenGL Extension Wrangler (GLEW) library.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.