Re: Bug#283994: ITP: glastree -- builds live backup trees, with branches for each day

[Anthony DeRobertis]

Matthew Palmer wrote:
The advantage of using glastree over pdumpfs is that it is implemented
in Perl rather than Ruby (this is in fact the reason that I encountered
it in the first place).

How is that an advantage of use?
We're talking about free software. Modifying it to fit your needs is a 
perfectly valid, indeed encouraged use. Personally, I know perl, but not 
ruby.

Re: Bug#283994: ITP: glastree -- builds live backup trees, with branches for each day

[Anthony DeRobertis]

Matthew Palmer wrote:
Sounds like you need to expand your repertoire a bit. 
Possibly so, but unfortunately my time is a finite. There are far too 
many languages (even in debian main) for me to learn them all.

Can you imagine a world in which your argument was taken at face value? 
There would be a reimplementation of basically everything in every language
under the sun, just so that some random person could avoid learning a new
language.  Ghods what a hideous mess that would be.
Sounds like ftp.debian.org.

Re: murphy is listed on spamcop

[Anthony DeRobertis]

Thomas Bushnell BSG wrote:
What is this, "you go to war with the army you have, not the army you
want"?
Consider the full context of the quote[0], yes.

[0]
  http://www.defenselink.mil/transcripts/2004/tr20041208-secdef1761.html

Re: Print Alternative

[Anthony DeRobertis]

Fernanda Giroleti Weiden wrote:
That would ease porting this application to run on Debian. This
application would add a great facility for our users since it is
impossible to know what command must be used to print a document on a
Debian system.
Which ones don't support 'lpr' ? The LPR varients obviously do, and CUPS 
certainly does.

My suggestion to the name of this alternative is "print" which should
point to the command used to print (ex.: /usr/bin/lpr)
That name won't work. We already have a "print" command, part of the 
mime-support package.

Re: LCC and blobs

[Anthony DeRobertis]

Brian Thomas Sniffen wrote:
So would a web-based firmware loader, that never saved the firmware to
disk allow the drivers to be in main?

Of course not.  It's fetching software, then using that software.  ICQ
software merely mentions messages, but doesn't use them.
ICQ uses the messages as instructions telling it what glyphs to display 
on your screen. That part of the message, though, might be free.

It does use significant features from non-packaged software --- message 
routing, buddy list management, buddy tracking, file transfer, etc.

We've elected to ignore ICQ's dependency on an ICQ server. We've elected 
to ignore a driver's dependency on firmware burnt in ROM or stored in 
flash --- even when it executes that code on the main CPU. We've elected 
not to ignore firmware that resides in RAM instead.

I'm not sure how to make a consistent (and still useful) position out of 
all that.

Re: LCC and blobs

[Anthony DeRobertis]

Raul Miller wrote:
On Fri, Dec 31, 2004 at 05:02:15PM -0500, Anthony DeRobertis wrote:
The social contract says "...but we will never make the system depend on 
an item of non-free software." not "but we will never make the system 
depend on an item of non-free software /which we must distribute/."

We don't make the hardware.
Took me a while to figure out exactly what you're saying, but is it 
essentially that we could say:

We are not making our system depend on an item of non-free software.
Your hardware vendor did, not us.

Re: LCC and blobs

[Anthony DeRobertis]

Josh Triplett wrote:
I would like to suggest an additional option, which I think covers most
cases quite well:
If Debian were to package (a copy of) the non-free item in the non-free
section, would the Free package express a Depends, Recommends, or
Build-Depends on the non-free package?  If so, the Free package should
be in contrib.
That's an interesting criteria. It winds up working for flash and 
ROM-based devices because they are like Essential: yes packages.

However, it has one pitfall I can think of: If a package requires a 
certain version of an essential package, we'd normally declare a 
Depends: on that version (or later). I'm not sure what we'd do for 
firmware, though it'd probably be either a 'Suggests' or 'Recommends'.

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Anthony DeRobertis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wouter Verhelst wrote:
| You misunderstood. I don't fight generic changes to the order; I just
| don't think it would be a good thing that any random developer could
| prioritize his pet package.
|
Any random developer already has root on X thousand debian systems. We
can trust him with that, but not with helping determine build order?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCN1FE+z+IwlXqWf4RArSmAJwLA1aiNaTQtVzgXWYcua2061CsbACfUTnG
Ye6KWZ+xsscs+7VRHRTL8Dw=
=kHlW
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Do not make gratuitous source uploads just to provoke the buildds!

[Anthony DeRobertis]

Wouter Verhelst wrote:
That's not to say that a request to prioritize a package is to be
ignored; however, the power of deciding which packages get built first
should be with those that actually build the packages, rather than with
those who want their packages to be built. The former are expected to be
following the larger picture; the latter are not.
The latter, however, also know a good deal more about the particular 
details of the upload. It'd seem to at least make sense to use 
critical/medium/low as part of the sort criteria, for example before 
alphabetical. Maybe even ahead of standard/optional/extra.

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

Re: Checksumming tool

[Anthony DeRobertis]

Lars Wirzenius wrote:
> 
> The best I've come up with so far is a pseudo rfc822 syntax:
> 
> File: foo%20bar/hellurei.txt
> Size: 12345
> MD5: 012345667
> SHA-256: 0a0a0a0a0a0a0a0a0a0a0a0a
> Mode: 0644

[EMAIL PROTECTED]:tmp$ md5sum test
04c09e317db0addf12be8d1a4e2b9e37  test

[EMAIL PROTECTED]:tmp$ sha1sum test
35a980f320a5f72b11f3616c476fab2844118879  test


That format is extremely easy to work with using basic Unix commands
like grep, cut, sort, diff, etc. The one you've come up with is not.

Please, keep the useful one record (file) per line format. Is there
something wrong with:

LINE = TAG DELIM1 HASH DELIM2 FILENAME
DELIM1 = " " | "-" | ":" | ... (pick one)
DELIM2 = " "

If you let DELIM1 be either "-" or ":" and DELIM2 be " " then you are
backwards compatible with both md5sum and sha1sum by making 32-character
untagged hashes mean MD5 and 40-character ones mean SHA-1.

sha-256:<> test

is so much easier to deal with than rfc822 stuff.


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Anthony DeRobertis]

Norbert Preining wrote:

> 
> texlive-binaries-source   96M
> ---
> texlive-basicbin  texlive-base-bin
> texlive-binextra  texlive-extrautils

I'd suggest texline-extra-utils here, because (at least to me) "extra"
and "utils" put together are hard to read. Possibly because "au"
generally (always, maybe even) goes together as one sound in English.

In general, hyphenated is far easier to read than concatenated, so I
don't see a problem with prefering it. Just-try-reading-this-sentence
vs. Justtryreadingthissentence.

> texlive-langindic texlive-lang-indic

Shouldn't this go with languages, below?

> texlive-graphicstools texlive-graphicstools

A hyphen would really be appreciated here, too. Probably because of "st"
generally being one sound in English. Not to mention "graphic stools"
has the same spelling.

> texlive-langcjk   texlive-lang-cjk

Another language.

> texlive-documentation-basetexlive-base-doc
> texlive-documentation-bulgarian texlive-bg-doc
> texlive-documentation-czechslovak texlive-cs-doc
> texlive-documentation-dutch   texlive-nl-doc

I'm going to agree with the other poster: These should all be
texlive-doc-FOO instead of texlive-FOO-doc (including the base one).
It'll make them all sort nicely in aptitude, and also makes them be
found when the user searches (in aptitude) for texlive-doc.

> texlive-languages-source  37M
> 
> Reasoning: We use names instead of codes as several of these packages include
> support for different languages/variants (greek: various versions of greek 
> with different iso codes, ...). 

This makes them oddly different than the documentation packages. Could
you maybe use ISO codes, either two or three letter, where possible? Its
fairly clear that -lang-african can't do that, but almost all of them can.


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

Re: texlive-basic_2005-1_i386.changes REJECTED

[Anthony DeRobertis]

Norbert Preining wrote:

>>allrunes   dfsg
>>
>>Please: Tell me its not true that the DFSG is used as a license there.
> 
> 
> As stated in the License file, this list was generated from the TeX
> Catalogue, which *can be wrong*! If you check the actual allrunes files,
> you see that it is LPPL.

I really hope you've done this --- for all files --- before uploading.
Also, there are several versions of the LPPL, at least one of which
might have DFSG issues.


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

Re: ITP: ladder.app -- GNU Go frontend for GNUstep

[Anthony DeRobertis]

Roberto C. Sanchez wrote:
> On Wed, Nov 30, 2005 at 12:59:07PM +0100, Gürkan Sengün wrote:
> 
>>It uses gnugo as its
>>engine and you must have a recent version of gnugo installed in order to run 
>>it.
> 
> This statement is unnecessary.  You use dependencies to specify that.

"The description should also give information about the significant
dependencies and conflicts between this package and others, so that the
user knows why these dependencies and conflicts have been declared."
---Debian Policy, Section 3.4


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

Re: How to automatically update files on alioth from svn

[Anthony DeRobertis]

Frank Küster wrote:

> What do you mean
> with https?  I don't want to only check out individual files from a
> websvn site, but complete directories, including new files.

http://svnbook.red-bean.com/en/1.1/ch06s04.html


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

Re: [EMAIL PROTECTED]: Re: Bug#343662: fsck errors halting boot after upgrade]

[Anthony DeRobertis]

Theodore Ts'o wrote:
> (for example if the US Congress
> changes the definition of daylight savings time), 

That should be "when", not "if", unfortunately. AFAIK, they've already
done it.

On my system, /bin, /etc, /lib, and /sbin together are 156M;
/usr/share/zoneinfo is 5.5M. So, while a 3.5% increase in the size of /
would fix it, it seems rather wasteful for the need of ~1K.

Maybe just copy (in, e.g., postinst) the one file needed to
/lib/zoneinfo, and create the symlink to that. It really shouldn't be in
/etc; binary files do not belong there.


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

Re: switching to vim-tiny for standard vi?

[Anthony DeRobertis]

Anthony Towns wrote:

> Yeah; vi not behaving like vi by default seems like a showstopper.

I don't understand why. Debian is a GNU/Linux system, not a UNIX system.
Even such simple things as our "echo" command do not behave exactly as
POSIX dictates and classic UNIX does; we've generally, I think, told
tradition to go take a hike when faced with the choice of "better" vs.
"traditional."

Why should vi be any different? If we have a better alternative, replace it.

[Appologies if this message comes dangerously close to starting an
editor war]


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

Re: Size matters. Debian binary package stats

[Anthony DeRobertis]

Andrew Suffield wrote:

> As a general rule, UK bandwidth prices are roughly five to ten times
> those of equivalent service in other EU countries. Not that you can
> get equivalent service.

Ouch. I pay less than that for a T1 to my house, and far far far less
for bandwidth at a colo. I suggest that you consider either emigrating
or rioting in the streets.


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

Re: dependencies on makedev

[Anthony DeRobertis]

Matthew Garrett wrote:

> Indeed. Editing plain text configuration files has never been the Unix
> way, and vi certainly isn't a standard unix tool.
>

I think the right question for him to ask is, "what ever happened to the
 unix way?"

chmod, chown, etc. are all simple tools that do one job and do it well.
If I want to change the group of /dev/hdc to "foo" from its current
"cdrom", it is _very_ self-evident how to do that with chgrp.

Now, since my system actually runs udev, let's figure out how to do it
with vim... First, I take a look at /etc/udev.d. I see a udev.conf as
well as a bunch of other files. Open it up, nothing there. So next I go
look at rules.d (after trying to figure out where there is a rules.d as
well as a bunch of .rules files; aparently a less-clean version of
apache2's foo-available/foo-enabled. Should probably fix this. Whishlist
bug filed.) Next, it looks like you edit 020_permissions.rules (or
rather the file it is symlinked to). Maybe you change this line:

ENV{ID_CDROM}=="?*",GROUP="cdrom"

to

ENV{ID_CDROM}=="?*", KERNEL!="hdc"  GROUP="cdrom"

but I'm not sure.

I like udev overall (after all, I'm running it), however, this is
definitely not one of its strong points. It fails to keep simple things
simple.


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

Re: dependencies on makedev

[Anthony DeRobertis]

Joey Hess wrote:

> If there is then it would be possible to write a tool
> like what I think Anthony is suggesting:
> 
> udev-chown 666 /dev/cdrom
> udev-chmod -a 644 /dev/sda /dev/sdb # change all scsi usb devices
> 

That'd definitely be a great tool.


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

Re: Fwd: Bug#344758: init.d script should create /var/run/dirmngr

[Anthony DeRobertis]

Steve Langasek wrote:

> That's fine; I'm just saying that there's not much point in telling people
> to *not* ship /var/run (or subdirectories thereof) in their package.

Well, there is the slight point that if you ship /var/run/foo in your
package, you (a) probably use /var/run/foo just assuming it exists
because, after all, you shipped in in your package; (b) if you actually
mkdir -p it, you have two different ways that /var/run/foo could be
created, and possibly with two different sets of permissions.


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

Re: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265920

[Anthony DeRobertis]

Felipe Sateler wrote:

> This seems like a nice idea. File a whishlist bug against reportbug ;)
> 

If you really want to do this, look at
/usr/share/doc/reportbug/README.developers.


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

Re: libecw

[Anthony DeRobertis]

Miriam Ruiz wrote:
> I'm not sure if it's license (
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293346 ) can be considered
> free enough to be in main:

FYI, the right place to ask this is [EMAIL PROTECTED]
Moving it over there. Full-quoting because of this.

Summary: I don't believe this is a free software licence, failing at
least DFSG 3, 4, and 9. It may additionaly fail DFSG 6. Due to the
failure of DFSG 9, I doubt this can even go in non-free.


> 
> Use of the ECW SDK with Unlimited Decompressing and Unlimited Compression for
> applications licensed under a GNU General Public style license ("GPL") is
> governed by the "ECW SDK PUBLIC USE LICENSE AGREEMENT".

Not sure what they're thinking, as this definitely isn't GPL-compatible.

> 
> 
> * About modifications:
> 
> b)You may make modifications to the Software and distribute your
> modifications, in a form that is separate from the Software, such as 
> patches. The following restrictions apply to modifications: 

Requiring patches is allowed as an explicit exception given in DFSG.
However, I don't see anything allowing us to distribute binaries built
from patched sources, thus this seems to fail DFSG 4 ("[t]he license
must explicitly permit distribution of software built from modified
source code.")

> i)Modifications must not alter or remove any copyright notices in the
> Software. 

This is acceptable, provided they're actually reasonable copyright notices.

> ii)   When modifications to the Software are released under this license, a
> non-exclusive royalty-free right is granted to the initial 
> developer of the Software to distribute your modification in future versions
> of the Software provided such versions remain available under 
> these terms in addition to any other license(s) of the initial developer. 

I'm uncomfortable with this, but considering the other problems I can
punt on deciding :-D

> iii)  You are not permitted to change the ECW file format.

Fails DFSG 3.

> iv)   You are not permitted to use Software Product for development or
> distribution of "Server Software" that provides services or 
> functionality on a computer acting as a server.

Fails DFSG 3 and 9 (restriction in this case is "may not be distributed
alongside server software"); also possibly 6.

> 
> 
> * About restriction of use (I just don't know DFARS 252.227-7013 so I have no
> idea what's said in here)

Neither do I.

> 
> 3)U.S. GOVERNMENT RESTRICTED RIGHTS. 
> The SOFTWARE PRODUCT and documentation are provided with RESTRICTED RIGHTS.
> Use, duplication, or disclosure by the US Government is subject 
> to restrictions as set forth in subparagraph (c)(1)(ii) of The Rights in
> Technical Data and Computer Software clause at DFARS 252.227-7013 
> or subparagraphs (c)(1) and (2) of the Commercial Computer Software -
> Restricted Rights at 48 CFR 52.227-19, as applicable. Manufacturer is 
> Earth Resource Mapping Limited.
> 
> 4)DESCRIPTION OF OTHER RIGHTS AND LIMITATIONS. 
> a)Rental. You may not rent, lease or lend the SOFTWARE PRODUCT. 

Not sure how this affects DFSG freeness. I can't think of a single free
license we've seen on -legal with similar provisions.


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

Re: Amendment to GR on GFDL, and the changes to the Social Contract

[Anthony DeRobertis]

Christopher Martin wrote:

> Therefore, no modification of the DFSG would be required after the passage 
> of the amendment, since it would have been decided by the developers that 
> there was no inconsistency.

If a simple majority can yell, "there is no inconsistency" then the 3:1
requirement has little meaning. I think it'd be reasonable to request
that people who believe [0] is wrong should produce reasoned arguments
against it; to the best of my knowledge (and memory, of course), no one
has done so.

Without a reasoned argument for why the GFDL w/o Invariant Sections is
free, I don't see how the Secretary can consider the amendment anything
else than an attempt to change a foundation document, and either rule it
out of order or require the supermajority.

[0] http://people.debian.org/~srivasta/Position_Statement.xhtml


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

Re: Backports

[Anthony DeRobertis]

Joseph Smidt wrote:

> " I provide these files without any warranty. Use them at your own risk.
> If one of these packages eats your cat or your rabbit, kills your
> neighbour, or burns your fridge, don't bother me. "

Well, perhaps you should read the following, printed whenever you log in
to your Debian machine:

"Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law."

Hey, "without any warranty" is at least a step up from "ABSOLUTELY NO
WARRANTY", and the latter is even yelling at you.

:-D


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

Re: Backports

[Anthony DeRobertis]

Joseph Smidt wrote:

> Were you writing this  just to ridicule  me?

No, not at all. It was just supposed to be a joke.

I appologize; I should have been clearer.


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

Re: yet another mass bug filing on GFDL issues ?

[Anthony DeRobertis]

Holger Levsen wrote:

> Hm, on a second thought this (*) _might_ be a feature: the GFDL says 
> invariant 
> sections need to be listed, but there aren't any, as a template has been 
> used. Yay ?!

I suspect that many of those cases might just be an accidental ommission
in the copyright file...

OTOH, it is hillarious that after typing 'info gdb' I was unable to
actually find the statement saying the documentation is under the GFDL;
it appears that the FSF has once again mis-applied their own license...


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

Re: For those who care about the GR

[Anthony DeRobertis]

On Sun, Jan 22, 2006 at 03:42:39PM -0800, Steve Langasek wrote:

> > And what? If someone tries to bring through a GR stating that
> >  MS office warez can be distributed in main since it meets the DFSG,
> >  one might rule that as frivolous and a waste of time.
> 
> I'm not convinced the constitution gives the secretary the power to make
> such a ruling.  There are no provisions in the constitution for the Project
> Secretary to dismiss a GR -- *even* a GR stating that the Debian Project
> holds the value of pi to be 3 -- so long as the GR has the requisite number
> of seconds.

I suspect the Secretary could effectively do so by declining to take the
vote under Section 2.1.1 ("[n]othing in this constitution imposes an
obligation on anyone to do work for the Project.") It seems then that
the secretary has no obligation to actually perform 4.2.3 or 7.1.1.

> 
> In the present case, I understand that the proposed ballot option is
> ambiguous wrt whether it constitutes an implicit amendment to the foundation
> docs, and that in the absence of clarification (in the form of a re-worded
> proposal) on the part of the proposer, it is the project secretary's
> prerogative to specify a supermajority requirement.

I think that under 7.1.3, it'd be the Secretary's job/power to determine
supermajority requirement regardless of what the proposed ballot option
says.

If 6 developers (K=5 currently, I think) can decide that the
supermajority requirements to not apply to a ballot option, then the
supermajority requirements are rather worthless.


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

Re: How to purge linux-image-2.6.14

[Anthony DeRobertis]

Sam Morris wrote:

> PS - why do packages without any config files get into the config-files
> state in the first place? :)

Possibly, because dpkg can only know if a package has conffiles, and not
configuration files in general?

Look up the details in policy, but not all configuration files are
managed by dpkg. Packages may manage their own (using, e.g., ucf) as
long as they follow the rules laid out by policy.

BTW: I think sometimes packages do go strait from installed to purged on
just remove... Not 100% sure if it even happens, but maybe its if there
is no postrm script and no conffiles.


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

Re: Obsolete packages in Experimental

[Anthony DeRobertis]

apt-show-versions | grep /experimental

should work too, but I haven't tested it (no experimental packages
installed on this machine)


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

Re: Proposal: move /etc/{protocol,services,rpc} to base-files

[Anthony DeRobertis]

Nathanael Nerode wrote:

> In fact, this would solve in a certain sense the long argument about how many 
> protocols/services to include in the lists: alternate packages could 
> Provides: netbase-data if they included any superset of the most basic list.

In this way, I dare say, lies madness. Not only will there be multiple
packages owning the same config file, but there is the problem of
multiple versions existing --- package A and package B both include a
superset, and now for no good reason can't be installed together.

If there is really a problem with not being able to include everything
in netkit-data or whatever, we need an update-services command, etc.


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

Re: the latest gnome

[Anthony DeRobertis]

Kevin Mark wrote:
> If 'upgrades'
> in Gnome are going to remove something, I think there should be
> something obvious like a document placed on the desktop saying
> 'gnome_2.12.2.removed.features' and explaining what was removed and how to 
> work around it
> based upon the functionality in the last version.

Well, personally, after the tasklist applet lost its ability to only
show iconified (minimized) windows, I found that the solution was along
the lines of: [At the risk of starting a flame war]

# apt-get install kicker
...
$ killall gnome-panel
... damn, it comes back.
$ while true; do killall -9 gnome-panel; done
... wait a few seconds, control-c the while true loop,
and now it doesn't come back. Yeah!
$ kicker


GNOME seems to be more and more focusing on the entry-level Linux user,
and less and less on advanced users. Most unfortunate, its much prettier
than KDE. And Nautilus beats Konqueror's file handling hands down.


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

Re: conffile purging and maintainer scripts

[Anthony DeRobertis]

Roger Leigh wrote:

> This updated version should cater for both the old and new behaviour.
> Any comments?

Maintainers using this should be aware that it will mistakenly delete
conffiles that have been converted to e.g., ucf configuration files.
This is, of course, unavoidable.

It will also delete any locally-installed configuration files, of
course. The following sequence of actions could be quite bad:

1. Locally install FOO, with its config file /etc/foo.conf. Maybe
because FOO isn't available in stable.

2. Someone packages FOO for Debian, with the config file /etc/foo.conf.

3. Debian package changes to using /etc/foo/foo.conf

4. Upgrade to stable+1, install Debian FOO package. Or install from
backport, whatever.

5. Decide you'd rather keep locally installed FOO, purge Debian FOO package.

Solution to this one is that admins should follow the FHS and put their
config files in /etc/local/ :-D


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

apt-secure broke?

[Anthony DeRobertis]

Recently, I've just started getting errors like these:

W: GPG error: http://http.us.debian.org testing Release: Unknown error 
executing gpgv
W: GPG error: http://http.us.debian.org unstable Release: Unknown error 
executing gpgv
W: GPG error: http://http.us.debian.org experimental Release: Unknown error 
executing gpgv

I suspect this has to do with
http://http.us.debian.org/debian/dists/testing/Release.gpg being an
empty file. Stable still has a signature; what happaned?


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

Re: Reboot in postinst

[Anthony DeRobertis]

On Fri, Jan 21, 2005 at 10:18:44AM -0800, Ken Bloom wrote:

> So I dist-upgrade, and it upgrades 12 packages. Your postinst runs before
> any of the other 11. The computer reboots immediately in your postinst.

Even worse: One of those other 11 was a kernel-image package, and this
machine uses lilo.


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

Re: How to define a release architecture

[Anthony DeRobertis]

Steve Langasek wrote:
One of the delays affecting getting lully.d.o back on line, AIUI, was a dead
power supply that was non-trivial to replace.  This is a case of scarce
hardware impacting a port even *before* it has ceased to become available
for sale.
Well, N+1 redundancy is already required. Maybe a requirement for N+2 or 
more for architectures where replacement parts are hard to find?

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

Re: Bug#302419: ITP: nzb -- A binary news grabber using nzb files

[Anthony DeRobertis]

Ron Johnson wrote:
What the heck is an nzb file?  I checked out the listed web site,
but it didn't enlighten.
FYI, I think it is a seperate file that is sometimes posted along with a 
multi-part binary that contains details about the posts that make up 
that binary and their order. Might even be XML. (I sort of remember 
seeing some in binaries groups)

The long description should probably at least make mention of this.
PS: Make sure to cc comments about ITPs (and bugs in general) to the 
BTS. I think I've managed to restore the correct cc's.

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

Re: Bug#304266: ITP: sdate -- never ending september date

[Anthony DeRobertis]

Josselin Mouette wrote:
Is there any real-life use for this program?
Is there any real-life use for filters?
/usr/games/jethro
/usr/games/kraut
/usr/games/cockney
/usr/games/jive
/usr/games/nyc
/usr/games/ken
/usr/games/ky00te
/usr/games/newspeak
/usr/games/eleet
/usr/games/b1ff
/usr/games/chef
/usr/games/jibberish
/usr/games/upside-down
/usr/games/rasterman
/usr/games/studly
/usr/games/fudd
/usr/games/censor
/usr/games/spammer
/usr/games/uniencode
Though, rather than having a seperate package for this, it'd probably be 
better to add it to some other package of small toys.

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

Re: OT: macs?

[Anthony DeRobertis]

Jens Peter Secher wrote:
Shouldn't that be
>
  "Windows is like a prostitute.  Sure it's got a nice make up,
   but you have all kinds of vira after spending some time with it."
No, it shouldn't be, or the Latin scholars will take revenge on you.
[sending to -curiosa where this belongs]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Outrageous Maintainer

[Anthony DeRobertis]

Klaus Ethgen wrote:

> The according bug is #306608.

It looks like the issue there (trying to quickly read through it) is if
package libwxgtk2.4-python nedds to declare a Conflicts: with package
wxpython2.5.3. The reason being that both provide a /usr/bin/helpviewer.

First off, this is a tad bit weird; wxpython2.5.3 declares a
Replaces: libwxgtk2.4-python. Maybe because of the order of installation
dpkg is ignoring this.

However, Policy 10.1 gives two ways to handle programs with the same
file name and the same functionality. [Same name, different
functionality, is not allowed at all.] Either alternatives or conflicts
may be used.

This is a bug, though possibly not in the libwxgtk2.4-python package. If
the relevant maintainers (libwxgtk2.4-python, wxpython2.5.3) and bug
sumitters can't work out a solution, then ask the Technical Comittee to
do so. That's what they're there for.


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

Re: Should Debian use lsb init-functions?

[Anthony DeRobertis]

Marc Haber wrote:

> The bootlogd docs strongly suggest not using it.

Out of curiosity, where? I checked /usr/share/doc/sysvinit,
/usr/share/doc/initscripts, and bootlogd(8). The only thing I found was
a warning about parsing the kernel's command line in the manpage.


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

Re: packages missing from sarge

[Anthony DeRobertis]

On May 8, 2005, at 08:36, Andreas Henriksson wrote:
Hi everybody!
Although I guess there's no chance for it to make it in,
Openswan is the one on my personal wishlist.
Seconded! The only RC-bug in openswan is for a newer version of the  
kernel which will not ship with Sarge.

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

Re: packages missing from sarge

[Anthony DeRobertis]

On Tue, May 10, 2005 at 09:32:49AM +0200, Rene Mayrhofer wrote:
> Am Dienstag, 10. Mai 2005 02:40 schrieb Anthony DeRobertis:
> > Seconded! The only RC-bug in openswan is for a newer version of the
> > kernel which will not ship with Sarge.
> Yes, that's true. I have to admit that I messed up in not marking this bug 
> sid. My current best solution would be to put 2.2.0-4 back into testing 
> (which got removed because of that RC bug that's for 2.3.0). What is the 
> general opinion on this?

If that 2.3.x bug really only affects the newer (> 2.6.8) kernel, why
not just get 2.3.x pushed into sarge? Are there any other big issues
with it, that weren't in 2.2.x? Some people might certainly like the
agressive mode support, or 2.3.1's NAT-T fixes. Personally, 2.2.x is
fine for me though --- anything but 2.1.x for me :-)

> 
> with best regards,
> Rene



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

Re: /usr/lib vs /usr/libexec

[Anthony DeRobertis]

Thomas Bushnell BSG wrote:

> Still, nobody has said.  What filesystems available on Debian have a
> better than linear search time for open,

reiserfs, ext2/3 (with dir_index), and probably others.


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

Re: RES: /usr/lib vs /usr/libexec

[Anthony DeRobertis]

On May 13, 2005, at 11:28, Humberto Massa Guimarães wrote:
You said it yourself. Even if your 256MB machine were typical (it's  
not), the less cache memory you use to cache dentries of /usr/lib,  
the better (more memory for your apps, or to cache other, more  
useful stuff).
If you suspect that separating /usr/lib into multiple directories  
will improve performance, please bring reasonable benchmarks, not  
speculation.

Re: packages missing from sarge

[Anthony DeRobertis]

On May 15, 2005, at 22:16, Steve Langasek wrote:
Still, the concerns about re-adding this software version (which  
has been
out of testing for months) via t-p-u remain.
Its hard to see it being any worse than freeswan, which has been  
abandoned for a while by its upstream. And if it turns out to be a  
problem, it could just be removed again, right?

racoon doesn't have all the features that freeswan and openswan have;  
not sure about isakmpd and pipsecd.

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

Re: RES: /usr/lib vs /usr/libexec

[Anthony DeRobertis]

Thomas Bushnell BSG wrote:
I do believe you've missed the point.  Splitting /usr from / helps in
a teeny percentage of cases, and most of the cases where it "helps"
that have been mentioned here, it actually doesn't.
Well, I think it helps in the case of network mounting it; it is easier 
to mount a non-root FS than the root fs. Given this isn't a huge 
benefit, and isn't for a huge number of people either.

Personally, I don't have /usr on a different partition on any machine. 
No need for it.

Yet, splitting
/usr/lib, which is grotesquely huge and hard to deal with, is treated
as an impossible thing, needing a great level of proof before it can
be considered.  This is very foolish.
Well, I didn't ask for great levels of proof. I asked for /any/ proof. 
The /usr split has already been done; it'd be more work to re-merge /usr 
and / than it would be to leave it the way it is. The same can't be said 
for libexec.

We've been told that /usr is necessary to allow network sharing.  Of
course, you can network share any directory, not just /usr.  If you
want executables to be shared, then share /bin.  It's not a problem.
I've done it.
Sharing the root fs is possible via special kernel support or via 
initrd. /bin I guess is doable alone, but would require some nice initrd 
hacking.

We've been told that /usr is necessary because then you reduce the
chance that the system will be hosed from disk corruption.
This is, of course, BS; use a journaled file system for that. Either 
that, or make /home, /tmp, /var, etc. separate and then / will hardly 
ever be dirty, so it won't suffer corruption. You could even mount it ro.

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

Re: packages missing from sarge

[Anthony DeRobertis]

Steve Langasek wrote:
With the delays in getting
t-p-u built across architectures, that's not long enough for me to be
comfortable.
I didn't realize t-p-u took so long. But I suppose that's the way it is. 
Thanks for the explanation, and thank you for your work on getting Sarge 
out the door!

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

Re: Bug#311997: ITP: gaim-latex -- gaim plugin wich translate LaTeX code into image in conversation

[Anthony DeRobertis]

Martin Braure de Calignon wrote:

> Quoting tex2im code:
> 
> (...)
> latex -interaction=batchmode out.tex > /dev/null
> cd "$homedir"
> dvips -o $tmpdir/out.eps -E $tmpdir/out.dvi 2> /dev/null
> (...)
> convert +adjoin -antialias -transparent $color1 -density $resolution
> $tmpdir/out.eps $tmpdir/out.$format
> (...)
> #
> So they directly use latex.

This looks like a Bad Idea(tm):

[EMAIL PROTECTED]:latex-test$ cat out.tex
\documentclass{letter}
\begin{document}
\input{/etc/passwd}
\end{document}

$ latex -interaction=batchmode out.tex > /dev/null
$ dvips -o out.eps -E out.dvi 2> /dev/null
$ convert +adjoin -antialias out.eps out.png
$ see out.png

And yes, the contents of /etc/passwd pop up on screen. Given this isn't
too big a deal, but TeX can write files too, and would have permission
to change any file the user does.


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

Re: Bug#311997: ITP: gaim-latex -- gaim plugin wich translate LaTeX code into image in conversation

[Anthony DeRobertis]

Roberto C. Sanchez wrote:

> At some point, you do need to execute something on your machine, else
> you may as well unplug it and find something else to do.  I understand
> what you are saying, but we can't put everyone in a small padded room.
> Based on your assessment, we would have cause to seek the removal of
> latex, vi, emacs, cat and less.

Ummm, I think you've missed my point. The thread is discussing a GAIM
(instant message client) plugin. So that script is not run by you, it is
run by an arbitrary stranger sending you an instant message, but on your
machine and as you. That's why its a problem.

Looks like if you installed this package, I could send you an IM and
overwrite an arbitrary file on your machine.

[This is just judging from the code snippet posted; don't have time to
fully audit the software.]


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

Re: Bug#311997: ITP: gaim-latex -- gaim plugin wich translate LaTeX code into image in conversation

[Anthony DeRobertis]

Nicolas Schoonbroodt wrote:

> chdir("/tmp")
> system("latex -interaction=nonstopmode " FILE_TEX)
> system("dvips -o" FILE_PS " -E " FILE_DVI)
> system("convert " FILE_PS " " FILE_PNG)
> 
> and finaly a I do a
> system("rm -rf /tmp/GaimTeX.*") somewhere

This is still a security problem, this time from local users: A standard
symlink attack.


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

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Anthony DeRobertis]

Matthew Garrett wrote:


Lack of choice of venue imposes a burden on the licensor in case of
litigation - I see no reason why one is obviously free and the other
non-free.


No, lack of choice of venue generally imposes a burden on the plaintiff, 
who may be either the licensor or the licensee.



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

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Anthony DeRobertis]

Humberto Massa Guimarães wrote:


Well said. IMHO, no. DFSG #8 -- witch is part of the SC, IIRC --
forbids us to have rights that our users don't have.


No, it doesn't. It says:

The rights attached to the program must not depend on the program's 
being part of a Debian system. If the program is extracted from Debian 
and used or distributed without Debian but otherwise within the terms of 
the program's license, all parties to whom the program is redistributed 
should have the same rights as those that are granted in conjunction 
with the Debian system.


Very clearly, DFSG 8 states that you can not have a different set of 
rights in regard to FireFox when it is distributed as part of Debian vs. 
when it is not distributed as part of Debian. That's all.


It does /not/ prohibit Debian the organization from having rights that 
other people don't. It is unreasonable to read it that way, because 
Debian will *always* have additional rights in some works, for example 
those which it is author or copyright holder of.

Re: Ongoing Firefox (and Thunderbird) Trademark problems

[Anthony DeRobertis]

Humberto Massa Guimarães wrote:

> And this is my problem with the inclusion of MF's trademark usage in
> our package: the right to include such trademark *is* attached to
> the program (after all, it's the original name of the program (**));
> it's a right that *must* *not* *depend* on the program's being part
> of a Debian system. One *must* be capable of extracting the program
> from Debian and use it, or distribute it, without debian, but
> otherwise within the terms of the program's license -- which
> obviously (at least IMHO) includes the license to the trademarks
> originally included in the program.

You must be free to do so, and you are free to do so.

If you further modify it, you have to follow the terms of the license.
One of those terms is that you change the name, and that is perfectly
acceptable under the DFSG.

All that has happened, as far as I can tell, is that the Mozilla
Foundation waved the requirement for Debian to change the name. Granting
additional rights shouldn't make something less free.

> 
>>It does /not/ prohibit Debian the organization from having rights
>>that other people don't. It is unreasonable to read it that way,
>>because Debian will *always* have additional rights in some works,
>>for example those which it is author or copyright holder of.
> 
> 
> You are 100% right. But this is irrelevant, because you ignored the
> context of my phrase. The relevant (contextualized) meaning of my
> phrase above is:
> 
> premise 1 => DFSG #8 classifies as non-free software that has *any*
> rights attached to it that depends on the software be distributed in
> Debian.

As long as we're being technical about the meaning of DFSG 8, I might as
well point out that, technically, the Mozilla Foundation has offered
additional permission for software prepared by Debian. If Debian decided
to distribute Mozilla Firefox outside of Debian-the-OS, that permission
would still apply.

> 
> premise 2 => Mozilla Foundation Firefox trademark, which is present
> to be displayed in the usage of the firefox browser as it comes
> originally, has a restrictive license that either (a) forbids it to
> be used by Debian or (b) allows it to be used by Debian and Debian
> only, according to our acceptance or not of their offer of exclusive
> trademark licensing.
> 
> conclusion => non-rebranded Firefox is not Free Software as per the
> DFSG.

DFSG explicitly allows the license to require the software be renamed if
modified. Hence, non-rebranded Firefox is free though without the
additional trademark license, we might not be able modify it and keep
the name [as you note, I'm not sure if trademark law actually requires
us to rename it, especially for minor changes]. But that's only
discouraged, not non-free.

> This is a fairly simple conclusion, and no "historically the DFSG
> was made thinking about copyrights only" argument contradicts what
> is precisely stated there.

I agree with this part: Claims that the DFSG applies only to copyrights
are not correct; the DFSG must apply to the entire, aggregate licence to
the software, no matter what area of law it is made under: Otherwise, we
are not actually protecting the freedoms of our users, in violation of
the Social Contract.

But the DFSG generally wouldn't apply to trademarks, because trademarks
are names, and names are exempted explicitly from the DFGS.

> 
> Even taking the DFSG #4 concession, what is being asked from the MF
> is not a rename of the program (in which case the version in Debian
> could be called firefox-debianized or somesuch), but a complete
> purge of the trademark from the visible part of the program
> (including menu items, etc), which goes IMHO clearly beyond the
> DFSG #4 exception.

The DFSG 4 exception talks about "a different name", not "a different
package name," "a different file name," or any other similar technical
concept. The name of a program is a human concept, and should be
understood as allowing the license to require a change in what the user
will perceive the name to be, not just what the packaging system calls it.

That includes changing that every window says "Mozilla Firefox" in the
title bar; that the Help menu says "About Firefox" and displays a
dialogue with the name Firefox prominently displayed as the program's
name, etc.

Now, it may be that we don't think that should be free. If so, though,
we need to change the DFSG.


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

Re: Greylisting for @debian.org email, please

[Anthony DeRobertis]

Steve Kemp wrote:

>   Email may appear to be realtime, and you may even expect it to
>  be because this is frequently how it works.  But this is not guaranteed.
> 
>   Either way people's, misguided, beliefs on the realtimeness of
>  email delivery is not a valid reason to choose against greylisting.

I assure you the Internet is not guaranteed to be up either. I propose
we down it, as your mistaken belief in the reliability of the Internet
is not a valid reason to choose against shutting it down to stop spam.

People's expectation for email to be nearly instantaneous are a very
good reason for it to be so.


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

Re: Greylisting for @debian.org email, please

[Anthony DeRobertis]

Russell Coker wrote:

> Why is it tolerable to receive 200 spams in a day?  On a bad day I will 
> receive over 100 spams even though I use most of the anti-spam measures that 
> some people in this discussion don't like.

I receive ~500/day. Of those maybe 4 make it through SpamAssassin. I
rarely (maybe once per month) see a false positive.

Given, spamassassin does give a good deal of CPU load.


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

Re: Mozilla Foundation Trademarks

[Anthony DeRobertis]

Gervase Markham wrote:

> Then I'm slightly confused as to your concept of trademark infringement.
> If I label the car I've built as a Ford (even if it uses a lot of Ford
> parts), it infringes Ford's trademark.

OTOH, as has been pointed out before in one of the many related threads,
if I take a Ford, built by Ford Motor Company, replace the fuel pump, I
can still sell it as a Ford.

I'm not a trademark lawyer, haven't read much on trademark, etc. so I
don't feel competant at all trying to figure where that line is drawn in
software. However, I'd be surprised if putting

Mozilla Firefox
Modified by Debian
(see /usr/share/doc/mozilla-firefox/changelog.Debian.gz)

in the About box and similar things in the package description wouldn't
be allowed.

OTOH, I don't see any issue whatsoever with Debian taking the Mozilla
Foundation's trademark license offer, so long as it only gives Debian
additional rights.


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

Re: Getting rid of circular dependencies

[Anthony DeRobertis]

Josselin Mouette wrote:

Le mardi 28 juin 2005 à 16:05 +0200, Josselin Mouette a écrit :


2) document that packages using some extra feature (e.g. SVG loader)
needs to depend on an extra package (librsvg2-common)


Guess why we moved from doing things this way to make librsvg2-2 depend
on librsvg2-common...



To make things clearer: there is no way to tell whether a program
actually needs librsvg2-common. Even testing it with and without
librsvg2-common installed wouldn't be enough, as it could e.g. make use
of themes that include SVG files.


Wouldn't that at most be a Recommends, or even a Suggests?

Re: Section for a new package

[Anthony DeRobertis]

Bernd Eckenfels wrote:

> You can ship the generated file instead.

No, that's not source code. To be in main, you must be able to build
from source using only tools in main.


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

Re: Section for a new package

[Anthony DeRobertis]

Lionel Elie Mamane wrote:
> that I think of it, the last condition is pretty necessary for any
> kind of security support... It may thus be a hard requirement rather
> than "it'd be better".
> 

There isn't any guarantee of security support for non-free at least, and
I'd guess contrib as well.


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

Re: HashKnownHosts

[Anthony DeRobertis]

Wouter Verhelst wrote:

> and
> relying on other people's security to increase your own isn't pretty
> clever, actually.

Well, it increases your own security to: It makes it harder to use your
machine, were it to be compromised, as an attacker. This increases your
security in two ways:

1. Generally, you log into (and thus have public keys for) boxes you
care about. The worm won't be able to auto-propogate to those machines.
[Remember, there have been root exploits in sshd before. And worms that
exploited them.]

2. You won't have to convince law enforcement, your employer, etc. that
no, really, you didn't attack that machine, it was a worm, because the
attack won't happen (at least from your machine).


And, in general, turning this on by default increases the general
security of the Internet. That is a good thing, really. Its unfortunate,
but when you share a network with a billion other people, you have to
rely somewhat on the security of their machines.


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

Re: Package distribution, a concept for a modern package distribution

[Anthony DeRobertis]

Goswin von Brederlow wrote:

> For some time now (as in around a year) you can update your Packages
> files by downloading only the differences (ed script format diff) to
> your local file. Using that daily updates go down from the full 3+MB
> (2+Mb with bz2 now) to ~10K per day.

Really? I don't see it documented in, e.g. the sources.list manpage.
Google finds only an open bug requesting the feature. Nor do I find any
diffs at, e.g.,
http://http.us.debian.org/debian/dists/testing/main/binary-i386/


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

Re: Shared library versioning

[Anthony DeRobertis]

[EMAIL PROTECTED] wrote:

> g.h :
> template 
> void g (T x);
> 
> g.cc :
> template 
> void g (T x) {
>cout << x;
> }
> 
> The .h file has to include the .cc one in order for the compilation to work.
> That leads to a shared library that we'll call libg.so.1.0.0
> Let's say now that I compile a program `prgm` and link it against the above 
> library.

There are two issues here. The first is that you are not really linking
against the code in the shared library. GCC does not support template
export (for damn good reasons, really), and certainly does not support
it through shared libraries. In all likelyhood, the compiler is actually
inlining g().

If you were really using the shared library, you would not have to
include the .cc file. You're not. Your .so most likely does not even
export the instantiation of g you need.


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

Re: Shared library versioning

[Anthony DeRobertis]

[I think you meant to sent this to -devel as well as just me
privately... I hope you don't mind me sending my response back to -devel]

[EMAIL PROTECTED] wrote:

> But is this possible ? If for instance I know that T will be double, int and a
> "custom" class, can I force the code for g, g and g to be
> in the shared library ?

I think it is using explicit instantiation. However, you lose a lot of
the advantages of C++ templates --- ability to inline code, and, most
importantly, ability to instantiate with an arbitrary (compatible) type.

If you decide to go this route, though, you will need to get rid of the
.cc files from the -dev package; otherwise, you risk breaking the one
definition rule. (Maybe this is what you meant by every change needing a
new soversion?)


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

Re: cdrtools

[Anthony DeRobertis]

Erast Benson wrote:
>
> I do not need to make the build system 
> available under GPL (GPL §3 requires me to make it available but does
> not mention a license) 

GPL 3(a) requires the "complete corresponding source code [be]
distributed under the terms of Sections 1 and 2 above". GPL 3
defines the source code to include the "the scripts used to control
compilation and installation of the executable."

Section 2(b) requires third parties to publish derived works under the
GPL ("to be licensed as a whole at no charge to all third parties under
the terms of this License."). Section 2 also states "[T]he distribution
of the whole must be on the terms of this License, whose permissions for
other licensees extend to the entire whole, and thus to each and every
part regardless of who wrote it."


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

Re: how to deal with packages depending on mysql-server

[Anthony DeRobertis]

Bastian Venthur wrote:
> What is the preferred solution for this kind of problem?
>
>   


I've heard rumors that packages have a Description: field which could
probably contain a note along the lines of:

WordPress requires access to a local or remote MySQL server. If you
wish to run the server locally, additionally install the
mysql-server package.


of course, the rumors of the Description: field's existence could be false.


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

Re: new mplayer

[Anthony DeRobertis]

Yavor Doganov wrote:
> I was wondering, what's so important about mplayer?  With totem and
> vlc (and I anticipate there's something similar for KDE) you have
> everything you need. 

Not true. Mplayer is the only one with proper support for ASS subtitles.


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

Re: Orphaning most of my packages

[Anthony DeRobertis]

Steve Greenland wrote:
> Bug#392672: O: positron - synchronization manager for the Neuros Audio
> Computer Python. Probably dead after v1.1. Pierre Habouzit has NMU'd a
> version 1.1 upgrade and support for new python policy, see bug # 380895.
I can confirm that Positron is dead. Not only is it dead, it isn't
compatible with newer Neuros firmware. Sorune (Perl) and NDBM (Java) are
the two not-dead replacements.

I suggest removal.


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

Re: Lots of (easily recognisible) spam sent to the BTS today

[Anthony DeRobertis]

Bruce Sass wrote:
> I have yet to see a spam message sent to the BTS which used a "Package:" 
> pseudoheader, so that should work to eliminate BTS spam without 
> preventing non-DD's helping out.
>   
OTOH, a /lot/ of legitimate mail is sent to the BTS w/o a Package:
pseudo-header (think: pretty much anything to [EMAIL PROTECTED]).
So this isn't really a solution.


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

Re: Bug#396117: ITP: cpufreq-detect -- detect CPU frequency control driver

[Anthony DeRobertis]

Peter Palfrader wrote:
> How come it never outputs p4_clockmod?  I use that happily on several
> different machines.
>   

I can confirm I've tried it on a machine. The performance impact was
substantial (at least if I allowed it to go to its lowest speed); the
power consumption difference was immeasurable[0].

Have you actually measured the power savings?



[0] Immeasurable as in the measurement equipment (an UPS with load
indication, in this case) could not notice any difference. The same UPS
does notice a substantial difference with K8 chips.


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

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

[Anthony DeRobertis]

Lucas Nussbaum wrote:

> Some packages (e.g choose-mirror) fetch a newer version of a file during
> build if it's possible to fetch that file. I don't think this is RC,
> since the file is not missing from the package if the network is not
> available.
>   

In general, I strongly suspect that fetching updated source during build
is RC due to a violation of the Social Contract: the source we are
shipping intentionally does not correspond to the binary package.

I'm not sure if the above applies to choose-mirror. In particular, if
the file shipped in the binary is its own source, then it doesn't.
However, I'd still say it's bad idea, and a bug (maybe even RC). Some
more general reasons (not all necessarily apply to choose-mirror)

* changes to the package are not reflected in the changelog
* random network or remote server issues can cause a broken (or
  worse) build. What happens if the file on the server is corrupted?
* builds are no longer repeatable. Different source may even wind up
  built on different architectures.
* the package is much harder to NMU. What should be a spelling fix
  suddenly becomes a large change (due to the automated source
  pull), unbeknown to the NMU-er. Same problem for the security team.
* the supposedly-signed source package isn't really; it's pulling
  unsigned source for the build

Also, depending on what is being downloaded from the network, there
could be security issues. What happens if the server is compromised?


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

Re: Lots of (easily recognisible) spam sent to the BTS today

[Anthony DeRobertis]

Bruce Sass wrote:

> I don't think that disqualifies it as a solution, it just means there 
> would be a transition period while users learn that it is a required 
> part of messages sent to the BTS.

Yes it does. People other than Debian developers mail
[EMAIL PROTECTED] Heck, people who are not even Debian users
legitimately use [EMAIL PROTECTED] Example: upstream software authors.


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

Re: Bug#396117: ITP: cpufreq-detect -- detect CPU frequency control driver

[Anthony DeRobertis]

Mattia Dongili wrote:

> Yes, p4-clockmod is mostly useless for power saving but it helps
> reducing the processor temperature. And this is the only driver working
> for my p4 desktop.
>   

Odd. I was unable to measure any temperature reduction either.



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

Re: Downgrading the priority of nfs-utils

[Anthony DeRobertis]

Matthias Julius wrote:
> I would guess that most people who install a linux system don't need
> NFS.
>   

Donno. I use it on all my systems, home and otherwise; how else would I
mount file servers...

> And actually, NFS us not required to run Debian.  Do I don't think it
> needs to be in the default installation even if 70% of the users will
> use it. IMHO
>   

I think you've misunderstood the purpose of the default installation.
It's not the bare minimum to make the system work (that's Essential:
yes). It's the standard stuff that everyone expects to be on a UNIX
system, including things like a working c & c++ compiler, etc. 70% of
users using something is, IMO, a very strong argument for it to be
installed by default.

(Remember: installed by default does not mean you have to install it. It
just means if you don't manually select packages, it will be installed).


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

Re: Proposed new POSIX sh policy, version two

[Anthony DeRobertis]

Thomas Bushnell BSG wrote:

> Somebody needs to explain to Jari the concept of a shared text segment.
>   

Bash:

[EMAIL PROTECTED]:~$ grep 'Private_Dirty' /proc/$$/smaps | perl -e '$t = 0; 
while (<>) { /(\d+) kB$/ or die "parse err: $_"; $t += $1 } print "tot: $t\n"'
tot: 2800


Dash:

$ grep 'Private_Dirty' /proc/$$/smaps | perl -e '$t = 0; while (<>) { /(\d+) 
kB$/ or die "parse err: $_"; $t += $1 } print "tot: $t\n"'
tot: 84


Indeed, checking /proc/pid/status, we find bash's VmData is a mere 16
times larger than dash's.

Something tells me that 2.8MB * 20 could indeed be a problem on a 64MB
system.


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

Re: Question about "Depends: bash"

[Anthony DeRobertis]

Michelle Konzack wrote:
>
> I do not know a singel person which open 20 xterms with bash at the
> same time.  On my IBM i have normaly 4-6 XTerms open, mozilla and gaim.
>   

That's nice. ps/grep/wc shows I have 27 xterms, all with bash running,
open at the moment. Of course, I have far more than a PII w/ 64M of RAM.

And, of course, iceweasel uses more memory than all the xterms and
bashes combined. Oddly enough, gaim is even bigger(!)


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

Re: Ondemand governor by default in etch

[Anthony DeRobertis]

On Thu, Dec 07, 2006 at 09:36:29AM -0600, John Goerzen wrote:
>
>  * Will cause negligible impact on system performance.  ondemand seems
>to have the philosophy of "max system speed unless I can be shown
>that the system is pretty much idle"

This isn't true on this machine here. Enabling it has the following
effects:
1) it slows the CPU down to the point where I can watch the title
   bars of windows redraw step-by-step when I move the mouse over them
2) according to the power meter in my UPS, saves approximately 0W
   (yes, zero) of electricity.
3) lets the chip run approximately 0°C cooler.

vendor_id   : GenuineIntel
cpu family  : 15
model   : 4
model name  : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping: 1

analyzing CPU 0:
  driver: p4-clockmod
  CPUs which need to switch frequency at the same time: 0 1
  hardware limits: 375 MHz - 3.00 GHz
  available frequency steps: 375 MHz, 750 MHz, 1.13 GHz, 1.50 GHz, 1.88 GHz, 
2.25 GHz, 2.63 GHz, 3.00 GHz

OTOH, it works absolutely great on AMD64 chips.


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

Re: Ondemand governor by default in etch

[Anthony DeRobertis]

Matthew Garrett wrote:
> p4-clockmod is entirely useless. It's high-latency and doesn't drop the 
> core voltage.

Nice. Is there a good alternative for P4 machines? Is the ACPI one any
better (assuming a semi-sane BIOS)?


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

Re: Etch Software RAID Upgrade Trouble & Suggested Installer Improvements

[Anthony DeRobertis]

Alexey Feldgendler wrote:
>
> cp -avx --preserve=all 1/* 2  # rsync will do as well 

Of course, 1/* misses any dot-files in 1.


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

Re: DPL Debate prepared questions list [Debian Policy Sucks]

[Anthony DeRobertis]

Ritesh Raj Sarraf wrote:
Now, there was a known issue with those cards with e1000 driver upto kernel 
2.6.11, IIRC. 
  
Hmmm, and 2.6.12 panics (bug #327355 ) 
when I try and use the tape drive on my machine. New versions not only 
fix bugs, but introduce new ones, too.


[PS: Which e1000 bug are you referring to?]


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

Re: DPL Debate prepared questions list [Debian Policy Sucks]

[Anthony DeRobertis]

Martin Michlmayr wrote:

Anthony, do you still see this bug with 2.6.15 or (better yet) 2.6.16?
(will be uploaded tomorrow).
  
2.6.15, yes. I'll check 2.6.16 when it hits unstable (I'm guessing, 
though I still need to test, that the ide-tape cleanup in 2.6.9 borked it)



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

Re: Maintainers Guide

[Anthony DeRobertis]

Jeremy Stanley wrote:

   This has to include a copyright year, also.

...and following additional discussion, the resolution is:

   After considering the suggestion, I have decided to close this
   bug.
  
The year really should be included. At least in the US, not having a 
year in the notice appears to make the notice worthless. Quoting Title 
17 USC Sec. 401(b):


   (b) * Form of Notice.— *If a notice appears on the copies, it shall
   consist of the following three elements:

   (1) the symbol © (the letter C in a circle), or the word
   “Copyright”, or the abbreviation “Copr.”; and
   (2) the year of first publication of the work; in the case of
   compilations, or derivative works incorporating previously
   published material, the year date of first publication of the
   compilation or derivative work is sufficient. The year date may
   be omitted where a pictorial, graphic, or sculptural work, with
   accompanying text matter, if any, is reproduced in or on
   greeting cards, postcards, stationery, jewelry, dolls, toys, or
   any useful articles; and
   (3) the name of the owner of copyright in the work, or an
   abbreviation by which the name can be recognized, or a generally
   known alternative designation of the owner.

   
http://www4.law.cornell.edu/uscode/html/uscode17/usc_sec_17_0401000-.html


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

Re: Maintainers Guide

[Anthony DeRobertis]

On Tue, Mar 28, 2006 at 03:51:30PM +0200, Henning Makholm wrote:

> Only for some pretty strange values of "worthless". AFAIU the only
> legal effect of the notice requirements you cite is as defined by
> subsection (d): if a compliant notice is present, a defendant is
> excluded from the defense that he did not understand that the work was
> copyrighted.

Well, isn't prohibiting the "I didn't know it is copyrighted" defence
the only legal effect of having the notice nowadays, anyway?


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

Re: Bug#360340: ITP: libpcl1 -- the Portable Coroutine Library (PCL) implements the low level functionality for coroutines

[Anthony DeRobertis]

Ron Johnson wrote:

Vote: nay.  OP forgot to mention which volume of tAoCP.
  

I suspect some sarcasm has failed to convey over email.


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

Re: the BTS gains a remote bug tracking feature for free !

[Anthony DeRobertis]

On Wed, May 03, 2006 at 01:21:41PM +0200, Pierre Habouzit wrote:

>  * the forward canonization is vital for things like tracking bugzilla's
>"merges" (it in fact rewrites a $(uri)/show_bug.cgi?old_nnn into the 
>$(uri)/show_bug.cgi?new_nnn)

Out of curiosity, how does it handle un-merges in Bugzilla?


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

Re: Compiling packages for the standard distribution with -Os instead of -O2

[Anthony DeRobertis]

On Wed, May 03, 2006 at 11:02:57AM -0300, Henrique de Moraes Holschuh wrote:

> For Etch and Sid, it is probably a good idea to use -Os instead of -O2 at
> least on the bigger arches (ia32, ia64, amd64, etc), as we can probably
> trust gcc not to screw up.

If gcc generally generates faster code with -Os than -O2, then isn't
that a gcc bug, in that the optimizations enabled by -O2 are incorrectly
picked?

[Also, are there that man AMD64 machines with limited memory? Or IA64?]


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

Re: Bug#366069: ITP: fusesmb -- filesystem client based on the samba file transfer protocol

[Anthony DeRobertis]

On Thu, May 04, 2006 at 10:29:25PM +0200, Samuel Mimram wrote:

>  fusesmb is a filesystem client based on the samba file transfer protocol.
>  .
>  It is based on FUSE (userspace filesystem framework for Linux), thus you will
>  have to prepare fuse kernel module to be able to use it.

Please explain in the long description how this is different/better than
the smbfs and cifs kernel file systems.

[Looking at the URL, it seems it has some sort of "network neighborhood"
thing built in.]


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

Re: Compiling packages for the standard distribution with -Os instead of -O2

[Anthony DeRobertis]

On Sat, May 06, 2006 at 04:44:23PM +0200, Goswin von Brederlow wrote:

> Initialiy this was for people with older computers, not a 2 GHz amd64
> with 2GB ram. Think P90 with 64Mb or slightly better.
> 
> We are not talking "generally" here but "specific". Specific to
> certain hardware.

OP mentioned:
"For Etch and Sid, it is probably a good idea to use -Os instead of
-O2 at least on the bigger arches (ia32, ia64, amd64, etc), [...]"

Notice he suggested doing it in general on ia32 (which definitely has
older machines) but also with amd64 (which I doubt there are any 64mb
AMD64 systems) and ia64 (which I very much doubt there are any 64mb
systems).


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

Re: the BTS gains a remote bug tracking feature for free !

[Anthony DeRobertis]

On Fri, May 05, 2006 at 09:35:16AM +0200, Pierre Habouzit wrote:

> Could you please point me to an UNMERGED bug to see what it looks like ? 
> (an URL to the {status=closed ; resolution=merged} bug that was reopen, 
> as well as the bug in was merged "into").

https://bugzilla.mozilla.org/show_bug.cgi?id=85084

seems to be one such bug.

https://bugzilla.mozilla.org/show_activity.cgi?id=85084 shows what
happened fairly well.


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

Re: Testing security archive move

[Anthony DeRobertis]

Neil McGovern wrote:

deb http://security.debian.org etch/updates main contrib non-free
deb-src http://security.debian.org etch/updates main contrib non-free
  

Errr... apt-get says:

Failed to fetch http://security.debian.org/dists/etch/updates/Release  
Unable to find expected entry  main/binary-amd64/Packages in Meta-index 
file (malformed Release file?)



And, indeed, despite appearing in Architectures, there is no 
binary-amd64 in the release file.



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

Re: sending debian-private postings to gmail

[Anthony DeRobertis]

Kevin B. McCarty wrote:


Come to think of it, [pgp encrypting each message] isn't a bad idea.  Is it 
feasible for this to
be done transparently?  Mailing list admins, any comments?


I suspect that the end result of this would be more people keeping their 
GPG keys unencrypted on Internet-accessible machines.



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

Re: Please revoke your signatures from Martin Kraff's keys

[Anthony DeRobertis]

Tyler MacDonald wrote:
WTF?  In Oregon, if you have a driver's license, you cannot get an ID card.  
If you have an ID card, you have to surrender it to get a driver's license.  
You're only legally allowed one ID.



	Weird! 


Not really, same rules apply in Virginia, AFAIK.


You can still keep your birth certificate and social security
card though, right?
  


Neither of those are photo IDs.


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

Re: Testing security archive move

[Anthony DeRobertis]

Anthony DeRobertis wrote:

Errr... apt-get says:

Failed to fetch http://security.debian.org/dists/etch/updates/Release  
Unable to find expected entry  main/binary-amd64/Packages in 
Meta-index file (malformed Release file?)



And, indeed, despite appearing in Architectures, there is no 
binary-amd64 in the release file.




And indeed, it's still that way anyone know what's going on?


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

Re: Real Life hits: need to give up packages for adoption

[Anthony DeRobertis]

Christoph Haas wrote:
> Yes, of course. Besides some minor things I don't quite like about
> Subversion ([...] getting out old revisions of a file means typing 
> the full URL for no reason) 

svn cat -r 

works for me...


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

Bug#72140: Setting up libraries too slow

[Anthony DeRobertis]

Tim Connors wrote:
> only the occasional slowness as apt
> replaces libc6 and the /sbin/ldconfig program gets restored.  I move it
> back out of the way when I notice that apt is taking so long, and all is
> fine.
man dpkg-divert

That should help with your libc6 upgrades.


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

Re: Bug#375047: ITP: srtp -- Secure RTP (SRTP) and UST Reference Implementations

[Anthony DeRobertis]

Jonas Smedegaard wrote:

> (Include the long description here.)
>   
Yes. Please do so.

Writing the long description in the ITP allows debian-devel to help spot
any mistakes in, and make suggestions for improvement to, the long
description.


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

Re: new tar behavior and --wildcards

[Anthony DeRobertis]

Bdale Garbee wrote:

>The following table summarizes pattern-matching default values:
>
>MembersDefault settings
>--
>Inclusion  `--no-wildcards --anchored
>--no-wildcards-match-slash'
>Exclusion  `--wildcards --no-anchored
>--wildcards-match-slash'
>
>-- Footnotes --

Will this break my Amanda config? I'm not sure what flags Amanda passes
to tar, but I'm pretty syre I have no control (absent changing the
source, of course) over them.

Do I need to worry now which version of tar is installed on each machine
being backed up by Amanda? That'll be fun :-(


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

Re: ITP: openwatcom -- C/C++ compiler and IDE that produce efficient, portable code

[Anthony DeRobertis]

Matthew Garrett wrote:
>
> Ok, but it still needs to be modified. Are you suggesting that the 
> freedom to produce a binary that can't be recompiled by anyone else is a 
> necessary freedom?
>
>   

I haven't read the license, and I suggest asking on -legal if you want a
full analysis, but the general problems of clauses like that are:

* Have to distribute source to people I never distributed binaries
  too. So I can't make private modifications for a friend (and give
  source only to him). Nor can I make modifications interesting only
  to my organization (say, to make it run in a special environment
  unique to my organization) unless I distribute source (which is
  useless to anyone else, and which is probably a fair bit of
  additional work to distribute, especially if I don't already have
  a website to do it from.
* Because I must publicly distribute source, I can not secretly use
  the software. While there is unlikely to be any problem with my
  use of a compiler being known (well, at least not today), in other
  cases this could be a problem: Crypto software, DMCA-circumvention
  devices, etc.
* In order to keep the source publicly available for 12 months, I
  may have to bear practically unlimited costs: What happens if
  Slashdot links to my website? What happens if it turns out the
  software may violate a patent, copyright, etc? With software e.g.,
  under the GPL, I can limit my expenses/legal exposure by ceasing
  distribution entirely: Take down both the binary and the source.
  With this clause, I may not.


Also, although I'm less sure of the argument, "in order to use this
software, you must provide public access to it's source code" sounds
like demanding a fee to use it.


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

Re: ITP: openwatcom -- C/C++ compiler and IDE that produce efficient, portable code

[Anthony DeRobertis]

Marco d'Itri wrote:
> Bullshit. The only criteria for defining freedom for the purposes of
> Debian *is* the DFSG.

Under a strict reading of the DFSG, I'm not sure how a license that
prohibits running the code would fail.


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

Re: MPEG in general Was: Is anyone packaging `lame' ?

[Anthony DeRobertis]

> I'll dare to take the other route and ask: what is now holding back 
> software such as mplayer/mencoder, transcode and mjpegtools from 
> entering Debian?

Last time mplayer came up on debian-legal (the proper place for
questions like this), the problem was unclear licensing.

If the unclear licensing problem is fixed (not sure if it is), I don't
remember any remaining issues.


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

Re: Bug#195226: ITP: riece -- redesign of the Liece IRC client for Emacs

[Anthony DeRobertis]

On Thu, 2003-05-29 at 06:33, OHASHI Akira wrote:

>   Description : redesign of the Liece IRC client for Emacs
> 
> Riece is a redesign of the Liece IRC client.

I hope you don't intend to use that as your package description.


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