Re: [Mass bug filing] Native vs. non-native packages consistency

[Steve Langasek]

On Fri, Nov 04, 2005 at 10:13:50PM +0100, Roland Stigge wrote:
> I knew you would read this mail considering the subject. ;-)

> Below is a list of 311 packages that currently have a version in
> unstable that is not properly reflected by the existence of an
> orig.tar.gz file (that's 3.3% of the whole sid archive).

> Feel free to point me to false positives, as I haven't checked every
> single one of them. I know that some of them already have respective
> bugs filed against them.

Indeed, at least some of these *are* false positives; there is nothing that
prohibits the use of dashes in native version numbers, so I don't really
think it's appropriate to mass-file bugs against packages which appear to be
missing .diff.gz's until they've been verified individually.

Here are some false positives I found; I have not attempted to make a
comprehensive list.  However, noting that you've managed to tag large
numbers of core kernel packages as false-positives, I hope the reasons for
not encoding such a check in the archive software are now evident to you...

> doc-linux-html-pt_1999-12-4.tar.gz (Gleydson Mazioli da Silva <[EMAIL 
> PROTECTED]>)
> doc-linux-text-pt_1999-12-5.tar.gz (Gleydson Mazioli da Silva <[EMAIL 
> PROTECTED]>)
> kernel-headers-2.2.25-m68k_2.2.25-2.tar.gz (Christian T. Steigies <[EMAIL 
> PROTECTED]>)
> kernel-headers-2.4.27-m68k_2.4.27-1.tar.gz (Christian T. Steigies <[EMAIL 
> PROTECTED]>)
> kernel-image-2.2.25-amiga_2.2.25-4.tar.gz (Christian T. Steigies <[EMAIL 
> PROTECTED]>)
> kernel-image-2.2.25-atari_2.2.25-4.tar.gz (Christian T. Steigies <[EMAIL 
> PROTECTED]>)
> kernel-image-2.2.25-bvme6000_2.2.25-4.tar.gz (Christian T. Steigies <[EMAIL 
> PROTECTED]>)
> kernel-image-2.2.25-mac_2.2.25-4.tar.gz (Christian T. Steigies <[EMAIL 
> PROTECTED]>)
> kernel-image-2.2.25-mvme147_2.2.25-4.tar.gz (Christian T. Steigies <[EMAIL 
> PROTECTED]>)
> kernel-image-2.2.25-mvme16x_2.2.25-4.tar.gz (Christian T. Steigies <[EMAIL 
> PROTECTED]>)
> kernel-image-2.4.27-alpha_2.4.27-11.tar.gz (Debian Kernel Team 
> )
> kernel-image-2.4.27-arm_2.4.27-3.tar.gz (Vincent Sanders <[EMAIL PROTECTED]>)
> kernel-image-2.4.27-hppa_2.4.27-3.tar.gz (Thibaut VARENE <[EMAIL PROTECTED]>)
> kernel-image-2.4.27-i386_2.4.27-11.tar.gz (Debian Kernel Team 
> )
> kernel-image-2.4.27-m68k_2.4.27-3.tar.gz (Christian T. Steigies <[EMAIL 
> PROTECTED]>)
> kernel-image-2.4.27-s390_2.4.27-2.tar.gz (Debian S/390 Team 
> )
> kernel-image-2.4.27-sparc_2.4.27-9.tar.gz (Debian Kernel Team 
> )
> kernel-image-speakup-i386_2.4.27-1.1.tar.gz (Mario Lang <[EMAIL PROTECTED]>)
> kernel-latest-2.4-s390_2.4.27-1.tar.gz (Debian kernel team 
> )
> libast_0.6-0pre2003010606.1.tar.gz (Laurence J. Lane <[EMAIL PROTECTED]>)

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


signature.asc
Description: Digital signature

GPL... (was: Re: Debian based GNU/Solaris: pilot program)

[Adrian von Bidder]

On Friday 04 November 2005 14.33, John Hasler wrote:
> Wouter Verhelst writes:
> > Any *distributed* changes to foo.c must be contributed back to the
> > community.
>
> That's not true either.  Any distributed changes must be made available
> to those to whom the changes were distributed.  In practice changes
> usually become available to the community but that is not required.

... and it is also not required to make the changes available in a useable 
form.  (/me remembers some Montavista hacked gcc for some embedded 
platform: I tried to forward port their modification once, but gave up 
because all they distributed was the complete toolchain source with no 
indication what upstream version, exactly, it was based on[1].  Legally ok, 
to the letter of the GPL, but totally useless beecause isolating 
Montavista's work was virtually impossible.  I'm not picking on MV 
specifically here, it's just a good example from personal experience.)

[1] nontrivial - I concluded that it must have been a CVS snapshot with some 
additional upstream patches applied.

-- vbi

-- 
Could this mail be a fake? (Answer: No! - http://fortytwo.ch/gpg/intro)


pgpJ90YmDUABc.pgp
Description: PGP signature

Re: Debian based GNU/Solaris: pilot program

[Adrian von Bidder]

On Friday 04 November 2005 19.00, Andrew Suffield wrote:

> Complete bullshit. Get a life. 

Ahhh, yet another instance of asuffield.

-- vbi

-- 
featured product: GNU Privacy Guard - http://gnupg.org


pgpToLVOlXVEk.pgp
Description: PGP signature

Re: Debian based GNU/Solaris: pilot program

[Adrian von Bidder]

On Thursday 03 November 2005 20.51, Erast Benson wrote:
> HW vendors will *never* open their IP in
> drivers.

Ok, this becomes a bit OT here, but let me just remark that Linux today 
supports a *lot* of hardware, and that quite a few drivers (some RAID 
controllers, Intel SATA stuff, most of the S/390 and a lot of the HPPA 
stuff, I'm sure there's more) are actually actively supported by hardware 
vendors.  So you seem to live in a parallel universe at least to some 
degree.

-- vbi

-- 
Beware of the FUD - know your enemies. This week
* Patent Law, and how it is currently abused. *
http://fortytwo.ch/opinion


pgpfYbZmD9hLv.pgp
Description: PGP signature

Re: Clarification of NMU policy

[Steve Langasek]

On Wed, Nov 02, 2005 at 02:40:07PM +0100, Loïc Minier wrote:
> On Wed, Nov 02, 2005, Steve Langasek wrote:
> > For the record: there currently is not a 0-day NMU policy in effect.  There
> > was a 0-day NMU policy through the sarge release, and there are 0-day NMU
> > policies during BSPs, but the default NMU policy has reverted to that in the
> > developer's reference for now, in the absence of any other poilcy.

>  I think you skip the NMU policy for the C++ transition, for which I
>  think the first announcement was here:
> 

Ah, yes; I meant there was no 0-day policy in effect for packages at large.
:)

>  The C++ transition had no clear end, and AIUI is still ongoing.  I
>  think it's a bit fuzzy to track how far we are, what remains to be
>  done, and how long it's going to take, but I don't have any solution to
>  that.

http://people.debian.org/~mfurr/gxx/rebuild.html is still probably the best
summary of the status, although at this point most of the packages there are
not even NMU candidates since they only depend on libstdc++5 on one or two
architectures due to arch-specific problems.

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


signature.asc
Description: Digital signature

Re: d-i: partitioned md devices? allowed but not supported?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> It will autorun/enable *all* md devices it can, not just md0.  All of them
> will be available to bootstrap, and telling the kernel (through the command
> line) to mount a root partition in /dev/md1 will work just fine). This was
> true the last time I tried that, anyway, which was about one year ago.

Yes I guessed so, however it does not do it. In dmesg I only see md0
discovered, md1 does work only after putting it in mdadm.conf and using
mdrun

Well, I cant investigate on the system in question since it is now
productive, but will check another one. Thanks for your reply.

Gruss
Bernd


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

Re: Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...

[Steve Langasek]

On Thu, Nov 03, 2005 at 01:20:06PM -0500, Nathanael Nerode wrote:
> Steve Langasek wrote:
> >  We're only talking about keeping old binary packages around which
> > are no longer available from the new source package, which is precisely the
> > case that is at issue with library transitions.
> Ahhh.  I get it.  Just don't remove the old binaries unless they're manually 
> melanied, right?  That much is trivial, and should just involve making 
> britney stupider by making it do less.

The intent is that they would still be removed automatically, but that this
would be a second step *after* the test for whether an update makes packages
uninstallable.

> The hard part there is working out how to hang on to the old source package 
> (which is needed for licensing reasons), I guess?

Nope, by itself that should be fairly easy.

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


signature.asc
Description: Digital signature

Re: per-user temp directories by default?

[Manoj Srivastava]

On Thu, 3 Nov 2005 23:16:43 -0500, Noah Meyerhans <[EMAIL PROTECTED]> said: 

> Within the security team, there has recently been some talk of
> pushing for per-user temp directories by default in etch.  I'd like
> to see what people's reaction to such a proposal would be.

> session optional pam_tmpdir.so

> I have little operational experience with this PAM module, though.
> Does it cause problems for certain apps?  If so, could these
> problems be solved with a less simplistic PAM configuration?

It may need some tweaking of SELinux policy, depending on
 where these per user temporary directories  end up in.

manoj
-- 
An ounce of mother is worth a ton of priest. Spanish proverb
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: d-i: partitioned md devices? allowed but not supported?

[Henrique de Moraes Holschuh]

On Fri, 04 Nov 2005, Bernd Eckenfels wrote:
> starts them. I suspect it is doing that because there is a bootflag on the
> partition. I am not sure if the kernel can du that for all devices it auto

It looks for all type 0xFD partitions.

> detected (i havd md0 on sda1/sdb1 and md1 on sda2/sdb2, only the first is
> available before init).

It will autorun/enable *all* md devices it can, not just md0.  All of them
will be available to bootstrap, and telling the kernel (through the command
line) to mount a root partition in /dev/md1 will work just fine). This was
true the last time I tried that, anyway, which was about one year ago.

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


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

Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?

[Anthony DeRobertis]

Frank Küster wrote:

> Because one of the changes in the new version was crucial for the
> function of the program, the postinst script fails to initialize it, and
> the whole installation process fails.

I agree this is the right thing to happen. A package which has been
configured is expected to provide its functionality by any packages
which Depend: on it, and also by the admin.

Also, if you just ignore the error, it'll get lost in dpkg's messages,
and the admin will be confused when one of you Depend'ing packages
mysteriously fails to configure.

BTW: I suspect a lot of packages will fail to configure if you mess up
the config enough. Extremely important packages do this too; e.g., lilo,
kernel images. It is quite important there: The admin *must* be made
aware of the failure.


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

Re: Debian based GNU/Solaris: pilot program

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Erast Benson <[EMAIL PROTECTED]> writes:

> On Thu, 2005-11-03 at 22:19 +0100, Adam Borowski wrote:
>> Or, *freedoms*.  If a hardware vendor wants to profit from Linux users, 
>> they need to lift the limitations on the access to knowledge about their 
>> wares.
>
> Please wake up. :-)
>
> This will never happen. Nobody sane who spent 50$ millon dollars VC's
> capital will open their IP for free. This is fact of life. And than
> sooner Linux-kernel community will acknowlage it, it is better for them.
>
> The question is: whether Debian community wants to be on train or not
> and at which point?

You seem to miss the point that software freedom is what Debian is all
about.  Please read http://www.debian.org/social_contract; you might
then start to understand where we are coming from.  Anything not
falling within the scope of the DFSG is not of any interest.

Your many (somewhat confused) posts seem to be asking us to be doing a
lot of relicensing *for you*, but quite what we gain is not clear.
Working on proprietary software is not what we do.


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ 

iD8DBQFDbAmlVcFcaSW/uEgRAr2zAJ9xEthUrpw6cpc7AxeHIsjDHIoQaQCgu+KV
AqB9JJMCt3UmQksHJLhOnh4=
=s/fj
-END PGP SIGNATURE-


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

Testing-watch emails

[Henning Makholm]

Scripsit Steve Langasek <[EMAIL PROTECTED]>

> If you're interested in making this happen I'll be happy to give
> you any info I can;

OK, here are some questions.

 1) The copy of britney in merkel:/org/ftp.debian.org/ does not seem
to be synced regularly. Is there a place where one can see the
current code? It's not in the dak cvs (which appears to be
out-of-date wrt the merkel mirror anyway), and I tried poking
around on {cvs,svn,arch}.debian.org to no avail.

 2) Any advice on how to test patches to ftp-master code before
submitting them? My own scripts I can dry-run by substituting a
dummy command for sendmail and run them in the very place where
they will eventually function. In contrast, construcing a test
mock-up of the ftp-master environment to do test runs of a patched
britney appears to be highly nontrivial.  Does some automation for
this purpose exist? Or what do ftpmaster/release gurus do when you
change code?

 3) Do you (or somebody in QA who reads this) happen to know how the
'keyword' under which the PTS forwards emails is transmitted? I
cannot find any code in katie that sets this. Does the PTS analyse
subject lines for fixed patterns?

(Currently I'm extrapolating from the documented
[EMAIL PROTECTED] syntax, but I'm not sure
that is the Right Thing to do).

I'm not sure this is the right list to ask on, what with this being
technical matters rather than a flamewar. :-) Feel free to move to
somewhere appropriate, cc'ing me.

-- 
Henning Makholm "This imposes the restriction on any
  procedure statement that the kind and type
 of each actual parameter be compatible with the
   kind and type of the corresponding formal parameter."


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

Re: per-user temp directories by default?

[Steve Langasek]

On Fri, Nov 04, 2005 at 06:21:09PM +0100, Javier Fernández-Sanguino Peña wrote:

> A final point for consideration: libpam_tmpdir is not going to drive symlink
> attacks through temporary files away. There are packages that use temporary
> directories but are _not_ tmp. Some examples: the system's /var/lock/ and
> /dev/shm/, php4'as /var/lib/php4 (see #257111 for some discussion about
> this), php5's /var/lib/php5, transcriber's /var/lib/transcriber/ (fixed, see
> #257112), apache-common's /var/lib/apache/mod-bandwidth/ (see #257108, which
> was "fixed" with a simple note in the README.Debian file), tetex-base's
> /var/cache/fonts/{pk,source,tfm} and /var/spool/texmf/{pk,source,tfm}. All
> those are possible targets for security vulnerabilities for the programs that
> use them and will not be covered by the introduction of libpam_tmpdir.

Please explain what attack vector you see for /var/lib/php4.  The semantics
for /var/lib/php4 were chosen very carefully to specifically *avoid*
security problems, and you made no mention in #257111 of specific attack
vectors that you were concerned about.  The only attack vector I can foresee
here would be a brute force attack to guess the names of session files
located within the directory, which is unavoidable without moving to
per-uid session directories by default (which then doesn't meet the needs of
sites that share session files across security contexts).

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


signature.asc
Description: Digital signature

Re: Debian based GNU/Solaris: pilot program

[Henning Makholm]

Scripsit Florian Weimer <[EMAIL PROTECTED]>

> The GPL does fail the Dissident test because it does not permit
> anonymous changes.

Your copy of the GPL must have been garbled in transmission.
Please fetch a fresh copy from a trusted source.

-- 
Henning Makholm  "Gå ud i solen eller regnen, smil, køb en ny trøje,
   slå en sludder af med købmanden, puds dine støvler. Lev!"

Re: Debian based GNU/Solaris: pilot program

[Florian Weimer]

* Frank Küster:

>> Because that's what the GPL says, in relatively plain language.
>
> I cannot find it there.  Moreover, if it was in there, the GPL would
> fail the Dissident test and the Dessert Island test.

The GPL does fail the Dissident test because it does not permit
anonymous changes.

[Mass bug filing] Native vs. non-native packages consistency

[Roland Stigge]

Hi,

I knew you would read this mail considering the subject. ;-)

Below is a list of 311 packages that currently have a version in
unstable that is not properly reflected by the existence of an
orig.tar.gz file (that's 3.3% of the whole sid archive).

Feel free to point me to false positives, as I haven't checked every
single one of them. I know that some of them already have respective
bugs filed against them.

Interestingly, 3 of them have orig.tar.gz files but no Debian revision
(with one of those containing an empty diff).

If there are no serious concerns, I will start filing bugs against the
packages that are not already handled or bugged otherwise, together with
a verbose explanation and suggestions in a week or so.

To prevent this phenomenon in the future (people sometimes just forget
checking for an orig.tar.gz and ignore lin{da,tian} warnings), what
about making the archive maintenance software reject such uploads? This
should be easy to implement. However, care must be taken for corner
cases like NMUs for already existing packages etc.

Thanks.

bye,
  Roland


acl_2.2.32-1.tar.gz (Nathan Scott <[EMAIL PROTECTED]>)
adduser-ng_0.1.2-1.2.tar.gz (Robert Olejnik <[EMAIL PROTECTED]>)
aggregate_1.0.2-2.tar.gz (Simon Horman <[EMAIL PROTECTED]>)
alltraxclock_2.0.2-0.tar.gz (Romain Lerallut <[EMAIL PROTECTED]>)
alml_2005.01.01-2.1.tar.gz (Gaetano Paolone (bigpaul) <[EMAIL PROTECTED]>)
apcd_0.6b.nr-2.tar.gz (Tibor Koleszar <[EMAIL PROTECTED]>)
apoo_1.3-3.tar.gz (Rogerio Reis <[EMAIL PROTECTED]>)
arpwatch_2.1a13-2.tar.gz (KELEMEN Péter <[EMAIL PROTECTED]>)
asmon_0.70-1.tar.gz (Eric Evans <[EMAIL PROTECTED]>)
atari-fdisk_0.7.1-5.1.tar.gz (Roman Hodek <[EMAIL PROTECTED]>)
attr_2.4.25-1.tar.gz (Nathan Scott <[EMAIL PROTECTED]>)
avce00_1.3.0-1.tar.gz (Debian GIS Project
)
avifile_0.7.44.20051021-1.tar.gz (Zdenek Kabelac <[EMAIL PROTECTED]>)
barrendero_1.1-1.tar.gz (Eduardo Diaz Comellas <[EMAIL PROTECTED]>)
boa_0.94.14rc20-1.2.tar.gz (Teófilo Ruiz Suárez <[EMAIL PROTECTED]>)
bogl_0.1.18-1.4.tar.gz (Daniel Jacobowitz <[EMAIL PROTECTED]>)
bonobo-activation_2.4.0-4.tar.gz (Takuo KITAME <[EMAIL PROTECTED]>)
burn_0.4.3-2.tar.gz (Gaetano Paolone (bigpaul) <[EMAIL PROTECTED]>)
camlidl-doc_1.04-1.tar.gz (Stefano Zacchiroli <[EMAIL PROTECTED]>)
cdfs-src_2.4.20.a+2.6.12-2.tar.gz (Eduard Bloch <[EMAIL PROTECTED]>)
chemeq_1.2-1.tar.gz (Georges Khaznadar <[EMAIL PROTECTED]>)
classpath-tools_0.0.20020812-1.tar.gz (Grzegorz Prokopski (Debian
Developer) <[EMAIL PROTECTED]>)
coco-cs_20050926-1.tar.gz (Loeberbauer Markus <[EMAIL PROTECTED]>)
coco-doc_20050504-1.tar.gz (Loeberbauer Markus <[EMAIL PROTECTED]>)
coco-java_20050926-1.tar.gz (Loeberbauer Markus <[EMAIL PROTECTED]>)
console-data_2002.12.04dbs-49.tar.gz (Alastair McKinstry
<[EMAIL PROTECTED]>)
console-tools_0.2.3dbs-57.tar.gz (Alastair McKinstry <[EMAIL PROTECTED]>)
crystalspace_0.98-20040623-2.1.tar.gz (Christian Bayle <[EMAIL PROTECTED]>)
crystalspace-data_0.98-20040623-1.tar.gz (Christian Bayle
<[EMAIL PROTECTED]>)
dbbalancer_0.4.4-9.tar.gz (Andrew McMillan <[EMAIL PROTECTED]>)
dbf2mysql_1.14a-3.tar.gz (Francesco Paolo Lovergine <[EMAIL PROTECTED]>)
delo_0.8-2.tar.gz (Karsten Merker <[EMAIL PROTECTED]>)
dep.pl_1.36.0-5.tar.gz (Angel Ramos <[EMAIL PROTECTED]>)
deroff_1.1-5.tar.gz (David Frey <[EMAIL PROTECTED]>)
diffmon_20020222-2.tar.gz (Jeff Bailey <[EMAIL PROTECTED]>)
discus_0.2.9-1.1.tar.gz (Ron Farrer <[EMAIL PROTECTED]>)
dmapi_2.2.1-1.tar.gz (Nathan Scott <[EMAIL PROTECTED]>)
doc-linux-de_2003.10-3.tar.gz (Noèl Köthe <[EMAIL PROTECTED]>)
doc-linux-fr_2005.08-1.tar.gz (Pierre Machard <[EMAIL PROTECTED]>)
doc-linux-html-pt_1999-12-4.tar.gz (Gleydson Mazioli da Silva
<[EMAIL PROTECTED]>)
doc-linux-nl_20050324-2.tar.gz (Wouter Verhelst <[EMAIL PROTECTED]>)
doc-linux-sv_2001.12-2.tar.gz (Debian QA Group <[EMAIL PROTECTED]>)
doc-linux-text-pt_1999-12-5.tar.gz (Gleydson Mazioli da Silva
<[EMAIL PROTECTED]>)
docbook-xsl-stylesheets-ko_0.2-2.tar.gz (Yooseong Yang
<[EMAIL PROTECTED]>)
domesday_0.2cvs20030101-3.tar.gz (Mark Howard <[EMAIL PROTECTED]>)
duali_0.2.0-1.1.tar.gz (Mohammed Elzubeir <[EMAIL PROTECTED]>)
e2fsprogs_1.38-2.tar.gz (Theodore Y. Ts'o <[EMAIL PROTECTED]>)
ean13_0.4-8.1.tar.gz (Jim Westveer <[EMAIL PROTECTED]>)
falselogin_0.2-4.tar.gz (Tibor Koleszar <[EMAIL PROTECTED]>)
fireflier_1.1.6-2.tar.gz (Martin Maurer <[EMAIL PROTECTED]>)
flip_1.19-2.tar.gz (James R. Van Zandt <[EMAIL PROTECTED]>)
floppybackup_1.3-3.tar.gz (Matthew Vernon <[EMAIL PROTECTED]>)
fortunes-br_20011121-2.tar.gz (Eduardo Marcel Macan <[EMAIL PROTECTED]>)
fortunes-eo_20020729-4.tar.gz (Radovan Garabík
<[EMAIL PROTECTED]>)
fragroute_1.2-7.tar.gz (Simon Law <[EMAIL PROTECTED]>)
francine_0.99.8orig-5.tar.gz (Gerfried Fuchs <[EMAIL PROTECTED]>)
free-java-sdk_1.0-1.tar.gz (Grzegorz Prokopski (Debian Developer)
<[EMAIL PROTECTED]>)
freefem_3.5.7-3.tar.gz (Christophe Prud'homme <[EMAIL PROTECTED]>)
freeswan_2.04-12.tar.gz (Rene Mayrhofer <[EMAIL PROTECTED]>)
fte_0.50.0-1.1.tar.gz (Zdenek Ka

Bug#337518: ITP: synfigstudio -- GUI package for synfig (a 2D vector animation package)

[Paul Wise]

Package: wnpp
Severity: wishlist
Owner: Paul Wise <[EMAIL PROTECTED]>

Package: wnpp
Severity: wishlist
Owner: Paul Wise <[EMAIL PROTECTED]>

* Package name: synfigstudio
  Version : 0.61.00-39
  Upstream Author : Robert B. Quattlebaum Jr. <[EMAIL PROTECTED]>
* URL : http://www.synfig.com/
* License : GPL
  Description : GUI package for synfig (a 2D vector animation package)

synfig is a vector based 2D animation package. It is designed to be
capable of producing feature-film quality animation.

This package contains the graphical user interface for synfig.

Homepage: http://www.synfig.com/

I've asked upstream to remove all the PROPRIETARY and CONFIDENTIAL
notices from the source now that he has released it under the GPL. It
also doesn't build with gcc-4.0 at the moment.

Co-maintainers welcome. I'll need a sponsor once the upstream licence
stuff is sorted and I've packaged it.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#337516: ITP: synfig -- vector-based 2D animation studio

[Paul Wise]

Package: wnpp
Severity: wishlist
Owner: Paul Wise <[EMAIL PROTECTED]>

* Package name: synfig
  Version : 0.61.00-38
  Upstream Author : Robert B. Quattlebaum Jr. <[EMAIL PROTECTED]>
* URL : http://www.synfig.com/
* License : GPL
  Description : vector-based 2D animation studio

synfig is a vector based 2D animation package. It is designed to be
capable of producing feature-film quality animation. It eliminates the
need for tweening, preventing the need to hand-draw each frame.

Some key features:

* Spatial and temporal resolution independence - sharp and smooth ant
any resolution or framerate.
* Supports high dynamic range images (unfortunately this makes it slow.
a 2000% speed-up is planned).
* Comes with geometric, gradient, filter, distortion/transformation,
fractal and other layers.

Homepage: http://www.synfig.com/

I've asked upstream to remove all the PROPRIETARY and CONFIDENTIAL
notices from the source now that he has released it under the GPL. It
also doesn't build with gcc-4.0 at the moment.

Co-maintainers welcome. I'll need a sponsor once the upstream licence
stuff is sorted and I've packaged it.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Debian based GNU/Solaris: pilot program

[Glenn Maynard]

On Fri, Nov 04, 2005 at 03:54:01PM +0100, Andreas Barth wrote:
> * Glenn Maynard ([EMAIL PROTECTED]) [051104 14:40]:
> > On Fri, Nov 04, 2005 at 02:05:43PM +0100, Florian Weimer wrote:
> > > * Wouter Verhelst:
> > > 
> > > >> Lets assume you have GPL-ed project dpkg. Any change to foo.c must be
> > > >> contributed back to the community.
> > > >
> > > > No, that's not true.
> > > >
> > > > Any *distributed* changes to foo.c must be contributed back to the
> > > > community.
> > > 
> > > Huh?  Why do you think so?
> > 
> > Because that's what the GPL says, in relatively plain language.
> 
> I cannot remember to have read that. Perhaps you can cite the
> appropriate section. The only thing the GPL requires is that I do not
> further control the distribution of any file I gave someone else (except
> as far as controlled by the terms of the GPL). It does not require me or
> the other person to share the information with anyone else.

The point which Florian was correcting, was that you only have to give
source to people you give binaries to; changes which are not distributed
don't have to be given to anyone.

(If you're referring to "back to the community", then you should have
replied to Wouter's message, not Florian's.  The correction being made
in the message you replied to was "*distributed* changes", so that's what
you seem to be questioning.)

-- 
Glenn Maynard


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

Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?

[Petter Reinholdtsen]

[Frank Küster]
> Actually that wouldn't be hard for teTeX, since it looks for
> texmf.cnf at multiple places and reads them all.  Even the order is
> as intended - a file in /etc/texmf would override settings from the
> file in /usr/share/texmf.

Very good.  Should make it possible to implement a system to remove
the questions during upgrades. :)

> Having three files - ours in /usr/share/texmf/, a package-specific,
> generated one in /var/lib/texmf with the source files in
> /etc/texmf/texmf.d/, and the one for the local admin as
> /etc/texmf/texmf.cnf seems confusing to me.

One way to reduce the confusion would be to add references to the
other files in the header of each file.  This way the people reading
the file in /usr/share/, /etc/ or /var/lib/ have a better chance of
discovering the other files.


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

Re: Debian based GNU/Solaris: pilot program

[Lionel Elie Mamane]

On Fri, Nov 04, 2005 at 02:27:38PM +0100, Frank Küster wrote:
> Michael Poole <[EMAIL PROTECTED]> wrote:

>> The CDDL (based as it is on the MPL) allows you to mix
>> CDDL-licensed files in a project with files under CDDL-incompatible
>> licenses and distribute the resulting executable.

> Sorry, I didn't imagine that a license with such a clause exists,
> and less that anybody would call it free.

Come on, come on. The BSD license also permits mixing with non-free
files and distributing the resulting executable. And that one's widely
called "free".

-- 
Lionel


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

Bug#337498: ITP: unidesc -- Unicode Description Utilities consists of four programs for finding out what is in a Unicode file.

[Mohammed Sameer]

Package: wnpp
Severity: wishlist
Owner: Mohammed Sameer <[EMAIL PROTECTED]>

* Package name: unidesc
  Version : 2.15.1
  Upstream Author : Bill Poser
* URL : http://billposer.org/Software/unidesc.html
* License : GPL
  Description : Programs for finding out what is in a Unicode file.
Four programs for finding out what is in a Unicode file.
They are useful when working with Unicode files when one
doesn't know the writing system, doesn't have the necessary
font, needs to inspect invisible characters, needs to find
out whether characters have been combined or in what order
they occur, or needs statistics on which characters occur.
.
* uniname defaults to printing the character offset of each
character, its byte offset, its hex code value, its encoding,
the glyph itself, and its name. It may also be used to validate
UTF-8 input.
* unidesc reports the character ranges to which different portions
of the text belong. It can also be used to identify Unicode encodings
(e.g. UTF-16be) flagged by magic numbers.
* unihist generates a histogram of the characters in its input.
* ExplicateUTF8 is intended for debugging or for learning about Unicode.
It determines and explains the validity of a sequence of bytes as a UTF8
encoding.


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

-- 

-- Katoob Main Developer, Arabbix Maintainer.
GNU/Linux registered user #224950
Proud Egyptian GNU/Linux User Group  Admin.
Life powered by Debian, Homepage: www.foolab.org
--
Don't send me any attachment in Micro$oft (.DOC, .PPT) format please
Read http://www.gnu.org/philosophy/no-word-attachments.html
Preferable attachments: .PDF, .HTML, .TXT
Thanx for adding this text to Your signature


signature.asc
Description: Digital signature

Bug#337477: ITP: etl-dev -- Voria Extended Class and Template Library

[Paul Wise]

Package: wnpp
Severity: wishlist
Owner: Paul Wise <[EMAIL PROTECTED]>

* Package name: etl-dev
  Version : 0.04.06
  Upstream Author : Robert B. Quattlebaum Jr. <[EMAIL PROTECTED]>
* URL : http://www.deepdarc.com/2005/11/01/synfig-developer-preview/
* License : GPL
  Description : Voria Extended Class and Template Library

VoriaETL is a multiplatform class and template library designed to
complement and supplement the C++ STL.

I'm packaging this in order to package synfig, which depends on it.
Co-maintainers welcome, and I'll need a sponsor once the packaging is
done.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Debian based GNU/Solaris: pilot program

[John H. Robinson, IV]

Thomas Bushnell BSG wrote:
> Wouter Verhelst <[EMAIL PROTECTED]> writes:
> 
> > On Thu, Nov 03, 2005 at 12:48:53PM -0800, Erast Benson wrote:
> >> On Thu, 2005-11-03 at 12:18 -0800, Thomas Bushnell BSG wrote:
> >> > The GPL does not force developers to "contribute their changes back".
> >> > That's exactly the *point*.
> >> Lets assume you have GPL-ed project dpkg. Any change to foo.c must be
> >> contributed back to the community.
> >
> > No, that's not true.
> >
> > Any *distributed* changes to foo.c must be contributed back to the
> > community. There's a major difference here.
> 
> Not even that!  Any distributed changes must be given to the person
  ^
> you distribute foo to.

Not even that. They must at the very least be *offered*.

[excerpted from GNU GPL v2]
3.b) Accompany it with a written offer, valid for at least three years,
  to give any third party, for a charge no more than your cost of
  physically performing source distribution, a complete machine-readable
  copy of the corresponding source code, to be distributed under the
  terms of Sections 1 and 2 above on a medium customarily used for
  software interchange

-- 
John H. Robinson, IV  [EMAIL PROTECTED]
 http  
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type.  spiders.html  


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

Re: Bits from the release team: the plans for etch

[Philippe Troin]

Gabor Gombas <[EMAIL PROTECTED]> writes:

> On Sat, Oct 29, 2005 at 10:21:13PM -0700, Philippe Troin wrote:
> 
> > An other issue that always annoyed me is that assuming a NIS server
> > and a NIS client which both install say exim.  I want to give some
> > users membership in the group Debian-exim.  I can't easily.
> > 
> > The UID picked by Debian-exim is not going to be the same for the NIS
> > server and all the NIS clients, so I cannot get it propagated by NIS.
> > And I don't want to have to maintain the group membership on all the
> > clients.
> 
> That is a local administration decision. You should have a clear policy
> wether you'll be allowing system groups in NIS _before_ creating the NIS
> domain. If you do, you should have a plan _before_ creating the NIS
> domain about how you will deal with the inevitable conflicts.
> 
> When I last administered a complex distributed environment (we used
> first NIS+ then LDAP, but that's not important), we had a policy that
> local software should never use user/group IDs coming from NIS+/LDAP,
> and software installed on shared filesystems should never use user/group
> IDs _not_ coming from NIS+/LDAP. Mixing local and remote IDs in group
> membership was forbidden as well. That worked quite well.

Although I agree with the above on principle, how do you manage
membership to the floppy, audio, video, etc groups?

Phil.


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

Re: How to get rid of a poised version

[Kurt Roeckx]

On Fri, Nov 04, 2005 at 06:35:03PM +0100, Kurt Roeckx wrote:
> On Wed, Nov 02, 2005 at 11:30:20AM +0100, Peter Van Eynde wrote:
> > Hello,
> > 
> > Mea culpa. I did a stupid thing with sbcl: in version 1:0.9.6.0-1  I used 
> > the 
> > following construction:
> [...]
> > So is there anything else I can do? 
> 
> Yes, bootstrap it once for each arch manually.  This really is
> something the porters should do, or you can ask DSA to set up the
> chroots manually for you and build it yourself.
> 
> I've done this myself when -2 was uploaded for amd64, and it
> perfectly build all the others it tried (-3, -6, -7) without
> problems.

Actually, -7 failed, because there you seem to have made the
build dependency impossible to satisfy with the current version.
Which really is an RC bug.


Kurt


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

Re: Debian based GNU/Solaris: pilot program

[Adam Heath]

On Fri, 4 Nov 2005, Christian Perrier wrote:

> > 
> > As for relicensing it, fuck off.  I need to find a ClueBat(tm) attachment 
> > for
> > the Sodomotron 2000.
> > 
>
> ...which could certainly have been written:
>
> 
> As one of the dpkg authors, I do not intent to relicence it.
> 
>
> I actually don't really see a reason for being so aggressive verbally
> with someone we (you) disagree with. Erast Benson has been polite all
> along this thread and I'm afraid that the above sentence can only help
> many people reading the thread to keep convinced that Debian people
> still need to grow up a little.

This might be true; however, one needs to look past all the sweet talk and
honey, at the meat of the matter.  For this situation, there were very obvious
and apparent attempts at at misconception of the debian populace, in an
attempt to win favor.

If I had my druthers, I'd almost say this was a hoax.

It is in these situations, that one needs to see what is actually happening,
and get the evildoer to leave as quickly as possible; feeding with honey words
does not tend to have that effect.


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

Re: Debian based GNU/Solaris: pilot program

[Andrew Suffield]

On Thu, Nov 03, 2005 at 08:49:35PM -0500, Michael Poole wrote:
> Only quoting the first part of the second definition changes the
> meaning significantly -- but that is what is necessary to make it
> apply at all.

Complete bullshit. Get a life. 

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: per-user temp directories by default?

[Hubert Chan]

On Fri, 4 Nov 2005 01:42:08 -0500, Joey Hess <[EMAIL PROTECTED]> said:

> One problem I have experienced is that if I manually start cups via
> its init script, as root, the cups daemon ends up running as a less
> privliged user that cannot write to /root/tmp, and the failure mode is
> quite horrible (silent failure to print anything).

This could possibly be fixed by having programs fall back on a hardcoded
/tmp if $TMP is not writable. And/or by having init scripts clean up
their environment.

And of course I would consider silent failure to be a bug in CUPS.

-- 
Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.


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

Re: How to get rid of a poised version

[Kurt Roeckx]

On Wed, Nov 02, 2005 at 11:30:20AM +0100, Peter Van Eynde wrote:
> Hello,
> 
> Mea culpa. I did a stupid thing with sbcl: in version 1:0.9.6.0-1  I used the 
> following construction:
[...]
> So is there anything else I can do? 

Yes, bootstrap it once for each arch manually.  This really is
something the porters should do, or you can ask DSA to set up the
chroots manually for you and build it yourself.

I've done this myself when -2 was uploaded for amd64, and it
perfectly build all the others it tried (-3, -6, -7) without
problems.


Kurt


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

Re: per-user temp directories by default?

[Javier Fernández-Sanguino Peña]

On Fri, Nov 04, 2005 at 09:51:19AM -0500, Noah Meyerhans wrote:
> > Where was that talk done? I've been the one auditing that and there have 
> > been
> > DSAs for most of the bugs I've reported to the audit team. Granted, they are
> > not being issued inmediately (I usually provide the report and a patch), but
> > they are on the queue as far as I know.
> 
> Yes, your numerous reports are what lead to this discussion, which
> happened within [EMAIL PROTECTED]  Basically somebody was like "whoa, we'll
> never be able to fix all of these!  And why should we, anyway, since the
> problems are so minor?"  So it was proposed to at least provide an
> additional layer of safety so we can say that this class of bugs
> generally does not affect our default configuration.

The problem is, there are some issues which are *not* minor. Packages
that hardcode /tmp are either, from my experience:

- old stuff that was written when /tmp/something.$$ was believed random
  enough and safe. Easily fixed with a proper patch.
- new stuff that has been coded in a sloppy way, reviewing that code usually
  brings up a lot of other security bugs.

Sometimes, the /tmp bugs are more serious that one might believe at first
sight because:

a) they are predictable, i.e. a cron task runs the code or a daemon does it
periodically. For an example, see #256381
b) the code is run as root, not as $RANDOM user. For an example, see #249616

It's even worst if a) and b) happen together, for example see #256377, or
#329384. Those kind of bugs should have a DSA, they are not minor bugs.


> > The problem is, there's lots of those. And when I mean lots I mean that I
> > have a list of ~4780 binary packages of which at least ~2300 make use of
> > insecure tempfiles for sure and the others need to be reviewed (as the 
> > script
> 
> So can we really be expected to release ~2300 DSAs to fix all these
> things?  Even with patches to fix them, it's going to be an insane
> amount of work.  This is exactly why we want libpam_tmpdir.

You will have to, regardless of libpam_tmpdir. As I've said, those have
hardcoded /tmp paths in them so libpam_tmpdir will not prevent the attack.
From what I've seen, those that make use of TMPDIR (either explicitly or
because they use 'mktemp -d' or 'tempfile') seldom have race conditions.

IMHO, the use of $TMP or $TMPDIR should be mandated first in order for the
introduction of libpam_tmpdir to be really effective.

> You may be right that a policy change would be required.  Packages would
> need to respect $TMP or $TMPDIR in order for this proposal to work.  As
> has been pointed out earlier (Joey Hess mentioned CUPS breaking), this
> may result in a number of bugs.

A number is an understimation. There's lots of programs out there with
hardcoded /tmp stuff that are _not_ vulnerable to symlink attacks which would
need to be found and fixed.

A final point for consideration: libpam_tmpdir is not going to drive symlink
attacks through temporary files away. There are packages that use temporary
directories but are _not_ tmp. Some examples: the system's /var/lock/ and
/dev/shm/, php4'as /var/lib/php4 (see #257111 for some discussion about
this), php5's /var/lib/php5, transcriber's /var/lib/transcriber/ (fixed, see
#257112), apache-common's /var/lib/apache/mod-bandwidth/ (see #257108, which
was "fixed" with a simple note in the README.Debian file), tetex-base's
/var/cache/fonts/{pk,source,tfm} and /var/spool/texmf/{pk,source,tfm}. All
those are possible targets for security vulnerabilities for the programs that
use them and will not be covered by the introduction of libpam_tmpdir.

Regards

Javier


signature.asc
Description: Digital signature

Re: Debian based GNU/Solaris: pilot program

[Thomas Bushnell BSG]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> On Thu, Nov 03, 2005 at 12:48:53PM -0800, Erast Benson wrote:
>> On Thu, 2005-11-03 at 12:18 -0800, Thomas Bushnell BSG wrote:
>> > The GPL does not force developers to "contribute their changes back".
>> > That's exactly the *point*.
>> Lets assume you have GPL-ed project dpkg. Any change to foo.c must be
>> contributed back to the community.
>
> No, that's not true.
>
> Any *distributed* changes to foo.c must be contributed back to the
> community. There's a major difference here.

Not even that!  Any distributed changes must be given to the person
you distribute foo to.


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

Re: Calculating deps size - splitting a package

[Marcin Owsiany]

On Fri, Nov 04, 2005 at 02:49:44PM +0100, Francesco P. Lovergine wrote:
> On Fri, Nov 04, 2005 at 12:17:52PM +0100, Marcin Owsiany wrote:
> > 
> > Since there are currently 16 plugins, I don't want to investigate each
> > one manually. Ideally, there would be a tool, which would run ldd on
> > each plugin in turn and show the list of all direct and indirect
> > dependancies (with their installed-sizes) that adding the plugin in
> > question to a binary package would pull in. I am interested on the total
> > effect to an end-user, for each plugin.
> 
> Mmm, if plugins used dlopen() ldd would not help in that respect.

They don't. The main program dlopen()s the plugins, which in turn are
just linked against whathever shared libraries they need.

Marcin
-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216


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

Re: real-i386

[Rich Walker]

Daniel Ruoso <[EMAIL PROTECTED]> writes:

> Em Qui, 2005-11-03 às 21:39 +0200, Yavor Doganov escreveu:
>> At Thu, 3 Nov 2005 02:38:51 -0800 (PST), Nick Jacobs wrote:
>> > You mean, it's seriously been proposed that a significant amount of
>> > work should be done to restore support for a processor that has not
>> > been manufactured for 10 years? While slightly degrading performance
>> > for the 99.9% of x86 users who have Pentium/Athlon/or better?
>> Why not supporting it, if it is not so hard?
>
> I think i386 debian arch is not suitable anymore for real-i386 machines
> (self-experience), I mean, it's not suitable even for a Pentium 133 with
> 32 Mb RAM. Ok, I know it works, but it's a waste of memory and CPU
> cycles to run a full glibc-based distro in such restrictive
> environment...

It's also useful for people using x86-type CPUs without the full 686
instruction set - vis. the Via C3 cpu's, in use in a *lot* of systems.

Not having a 386-compatible kernel+libc, just a 686-compatible one, would
mean you couldn't run Debian at all on those machines.

cheers, Rich.

-- 
rich walker |  Shadow Robot Company | [EMAIL PROTECTED]
technical director 251 Liverpool Road   |
need a Hand?   London  N1 1LX   | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml


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

Re: dput works but dupload does not -- illegal PORT command

[Stephen Gran]

This one time, at band camp, Adam Kessel said:
> Starting some time in the past month, dupload always gives this error
> after checking the package and making the initial connection to the
> anonymous FTP upload queue:
> 
>  dupload fatal error: Can't upload (package).dsc: Illegal PORT command.
>  at /usr/bin/dupload line 508
> 
> Yet dput works fine.
> 
> Any suggestions what's wrong? Has anyone else been having htis problem?

You need one of passive ftp or the ftp nat kernel module (ip_nat_ftp,
but it used to be called something else on 2.4 kernels).
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Re: dput works but dupload does not -- illegal PORT command

[ajkessel]

>> Starting some time in the past month, dupload always gives this error
>> after checking the package and making the initial connection to the
>> anonymous FTP upload queue:
>> 
>>  dupload fatal error: Can't upload (package).dsc: Illegal PORT command.
>>  at /usr/bin/dupload line 508
>> 
>> Yet dput works fine.
>> 
>> Any suggestions what's wrong? Has anyone else been having htis problem?
>Did you try passive ftp? It works here.

Interesting--that hadn't occurred to me. It may be related to some
firewall/iptables problems I've been trying to figure out. I'll try that.  
-- 
Adam Rosi-Kessel
http://adam.rosi-kessel.org


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

Re: per-user temp directories by default?

[Adam Borowski]

On Fri, 4 Nov 2005, Lars Wirzenius wrote:

I don't think the suggestion was to make TMP=~/tmp, but TMP=/tmp/$USER,
where /tmp/$USER is owned by the user in question and is inaccessible to
others.


It would be a lot better to use TMP=/tmp/users/$USER, as user names are 
pretty likely to clash with files already in /tmp.  You can't pre-create 
all user dirs at boot as well -- there may be hundreds of thousands of 
users, new users can be created on the fly, or perhaps an authenthication 
mechanism doesn't even support providing you with the list of users.


Having a non-world-writable directory that can be written to only by a pam 
module which then chowns the individual dirs it creates would prevent such 
clashes.


Regards,
--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)


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

Re: per-user temp directories by default?

[Christoph Berg]

Re: Noah Meyerhans in <[EMAIL PROTECTED]>
> Sorry for not being more clear.  The default (only?) behavior of
> libpam_tmpdir is to set $TMP and $TMPDIR to /tmp/user/$UID.

The only difficult point I can see is that (the same) $TMPDIR should
also be available in chroots. I bind-mount /tmp in my chroots; if
libpam_tmpdir would create a new directory there, that would be bad as
files and sockets should be shared among the host and chroot
filesystem.

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: Debian based GNU/Solaris: pilot program

[Andreas Barth]

* Glenn Maynard ([EMAIL PROTECTED]) [051104 14:40]:
> On Fri, Nov 04, 2005 at 02:05:43PM +0100, Florian Weimer wrote:
> > * Wouter Verhelst:
> > 
> > >> Lets assume you have GPL-ed project dpkg. Any change to foo.c must be
> > >> contributed back to the community.
> > >
> > > No, that's not true.
> > >
> > > Any *distributed* changes to foo.c must be contributed back to the
> > > community.
> > 
> > Huh?  Why do you think so?
> 
> Because that's what the GPL says, in relatively plain language.

I cannot remember to have read that. Perhaps you can cite the
appropriate section. The only thing the GPL requires is that I do not
further control the distribution of any file I gave someone else (except
as far as controlled by the terms of the GPL). It does not require me or
the other person to share the information with anyone else.


Cheers,
Andi


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

Re: per-user temp directories by default?

[Noah Meyerhans]

On Fri, Nov 04, 2005 at 08:12:39AM +0100, Javier Fern?ndez-Sanguino Pe?a wrote:
> > There are a number of outstanding "insecure tempfile vulnerabilities",
> > and there has been some talk that they're both too numerous and of low
> > enough impact that they're not even worth releasing DSAs for.  Never the
> 
> Where was that talk done? I've been the one auditing that and there have been
> DSAs for most of the bugs I've reported to the audit team. Granted, they are
> not being issued inmediately (I usually provide the report and a patch), but
> they are on the queue as far as I know.

Yes, your numerous reports are what lead to this discussion, which
happened within [EMAIL PROTECTED]  Basically somebody was like "whoa, we'll
never be able to fix all of these!  And why should we, anyway, since the
problems are so minor?"  So it was proposed to at least provide an
additional layer of safety so we can say that this class of bugs
generally does not affect our default configuration.

> The problem is, there's lots of those. And when I mean lots I mean that I
> have a list of ~4780 binary packages of which at least ~2300 make use of
> insecure tempfiles for sure and the others need to be reviewed (as the script

So can we really be expected to release ~2300 DSAs to fix all these
things?  Even with patches to fix them, it's going to be an insane
amount of work.  This is exactly why we want libpam_tmpdir.

> IMHO, it's a worthwhile goal for etch but it should be done at the same time
> that there is a policy change mandating the use of mktemp/tempfile for shell
> scripts, File::Temp in perl scripts, tempnam in Php, tmpfile in C and safe
> constructs in those languages that lack a proper implementation (see #291389,
> for example).

You may be right that a policy change would be required.  Packages would
need to respect $TMP or $TMPDIR in order for this proposal to work.  As
has been pointed out earlier (Joey Hess mentioned CUPS breaking), this
may result in a number of bugs.

noah



signature.asc
Description: Digital signature

Re: per-user temp directories by default?

[Noah Meyerhans]

On Fri, Nov 04, 2005 at 01:00:48PM +0100, Klaus Ethgen wrote:
> That whould be no good idea for security environment where you do
> special think to secure /tmp (make it in memory and encrypt swap). With
> tempdir in users home all applications like for example gpg write
> temporary files to this location which ends up unencrypted on a disk or,
> more bad over an unsecure NFS share to the fileserver.
> 
> Please don't do this by default as it break the security of many, many
> systems!

First of all, libpam_tmpdir doesn't put $TMP in $HOME.  Second, we're
talking about the *default* configuration.  If you're doing something
with encrypted swap or $HOME on NFS, you've already diverged quite a bit
from the default configuration, so your security would not be broken
even if $TMP was in $HOME.  You'd simply have one single line to delete
from the default pam configuration.

noah



signature.asc
Description: Digital signature

Re: per-user temp directories by default?

[Noah Meyerhans]

On Fri, Nov 04, 2005 at 01:16:31PM +0100, Frank K?ster wrote:
> What do the security people mean with per-user temp directories?  It's
> clear that $HOME/tmp would be bad, but /tmp/$USERNAME/ with proper
> permissions doesn't sound so awkward.

Sorry for not being more clear.  The default (only?) behavior of
libpam_tmpdir is to set $TMP and $TMPDIR to /tmp/user/$UID.

noah



signature.asc
Description: Digital signature

Re: Debian based GNU/Solaris: pilot program

[Hamish Moffatt]

On Wed, Nov 02, 2005 at 06:21:41PM +0100, Gabor Gombas wrote:
> On Thu, Nov 03, 2005 at 12:11:32AM +1100, Hamish Moffatt wrote:
> 
> > I read all of your points as criticisms of Linux. That is disappointing.
> 
> Why is criticism disappointing? The goals of Linux and the Linux
> development model do not fit everybody's needs. Having an alternative

I would rather hear of OpenSolaris's benefits in their own right,
rather than just how it addresses alleged Linux deficiencies.

I don't know what the alleged benefits of Debian GNU/kFreeBSD are
either, but its developers haven't been telling us how it solves
all of Linux's problems here.

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


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

Re: dput works but dupload does not -- illegal PORT command

[Francesco P. Lovergine]

On Fri, Nov 04, 2005 at 08:19:32AM -0500, Adam Kessel wrote:
> Starting some time in the past month, dupload always gives this error
> after checking the package and making the initial connection to the
> anonymous FTP upload queue:
> 
>  dupload fatal error: Can't upload (package).dsc: Illegal PORT command.
>  at /usr/bin/dupload line 508
> 
> Yet dput works fine.
> 
> Any suggestions what's wrong? Has anyone else been having htis problem?
> -- 

Did you try passive ftp? It works here.

-- 
Francesco P. Lovergine


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

Re: Debian based GNU/Solaris: pilot program

[Hamish Moffatt]

On Thu, Nov 03, 2005 at 12:32:08PM -0800, Erast Benson wrote:
> today. may be not tomorrow. People are smart enough to not discard
> non-glibc ports and will come up with the solution.

Why don't you use glibc then? Your problem would be solved.
Debian GNU/kFreeBSD uses glibc according to their web site
http://www.us.debian.org/ports/kfreebsd-gnu/

I would say that currently the common element to all Debian ports
is glibc.

Please don't repeat your comments about the CDDL being superior.
Please give technical arguments instead.

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


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

Re: Debian based GNU/Solaris: pilot program

[Frank Küster]

Glenn Maynard <[EMAIL PROTECTED]> wrote:

> On Fri, Nov 04, 2005 at 02:05:43PM +0100, Florian Weimer wrote:
>> * Wouter Verhelst:
>> 
>> >> Lets assume you have GPL-ed project dpkg. Any change to foo.c must be
>> >> contributed back to the community.
>> >
>> > No, that's not true.
>> >
>> > Any *distributed* changes to foo.c must be contributed back to the
>> > community.
>> 
>> Huh?  Why do you think so?
>
> Because that's what the GPL says, in relatively plain language.

I cannot find it there.  Moreover, if it was in there, the GPL would
fail the Dissident test and the Dessert Island test.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Testing-watch emails

[Henning Makholm]

Scripsit Steve Langasek <[EMAIL PROTECTED]>
> On Thu, Nov 03, 2005 at 12:05:07AM +0100, Henning Makholm wrote:

>> I have now a frst draft of a status-change mail system running.  it
>> works from the archive mirror on merkel, [...]

> Thanks for running with this.  Ideally, we would get this integrated on
> ftp-master, so that the mails could be triggered by britney rather than
> being done post-hoc; this would also let us associate package removals with
> comments from britney hints files, so that they could be incorporated into
> the mails.  If you're interested in making this happen

I am. Also, I have gotten a couple of complaints that people want the
mails to be more easily procmailable. If they had katie instead of me
as sender, they would have a better chance of matching people's
existing recipies for routine Debian notices.

It seems that integrating it *properly* would involve learning Python,
(which won't happen this week or next), but less might work, too.

> I'll be happy to give you any info I can; though tbh, if I
> understood this part of the system very well, I probably would have
> written a patch myself already. ;)

I think that doing post-hoc analysis (perhaps on Sources files,
perhaps on cached HeidiResult files) is still a more robust
architecture than trying to hook into britney's actual
decision-making. Britney itself doesn't remember the hint comments
anyway, we'll need to do some heuristic parsing of the hints files
separately to extract removal reasons.

-- 
Henning Makholm"Manden med det store pindsvin er
  kommet vel ombord i den grønne dobbeltdækker."

Re: Debian based GNU/Solaris: pilot program

[John Hasler]

Wouter Verhelst writes:
> Any *distributed* changes to foo.c must be contributed back to the
> community.

That's not true either.  Any distributed changes must be made available to
those to whom the changes were distributed.  In practice changes usually
become available to the community but that is not required.
-- 
John Hasler


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

Re: Calculating deps size - splitting a package

[Francesco P. Lovergine]

On Fri, Nov 04, 2005 at 12:17:52PM +0100, Marcin Owsiany wrote:
> 
> Since there are currently 16 plugins, I don't want to investigate each
> one manually. Ideally, there would be a tool, which would run ldd on
> each plugin in turn and show the list of all direct and indirect
> dependancies (with their installed-sizes) that adding the plugin in
> question to a binary package would pull in. I am interested on the total
> effect to an end-user, for each plugin.

Mmm, if plugins used dlopen() ldd would not help in that respect.

-- 
Francesco P. Lovergine


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

Re: Debian based GNU/Solaris: pilot program

[Glenn Maynard]

On Fri, Nov 04, 2005 at 02:05:43PM +0100, Florian Weimer wrote:
> * Wouter Verhelst:
> 
> >> Lets assume you have GPL-ed project dpkg. Any change to foo.c must be
> >> contributed back to the community.
> >
> > No, that's not true.
> >
> > Any *distributed* changes to foo.c must be contributed back to the
> > community.
> 
> Huh?  Why do you think so?

Because that's what the GPL says, in relatively plain language.

-- 
Glenn Maynard


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

Re: Debian based GNU/Solaris: pilot program

[Frank Küster]

Michael Poole <[EMAIL PROTECTED]> wrote:

> Frank Küster writes:
>
>> Michael Poole <[EMAIL PROTECTED]> wrote:
>>
>>> Andrew Suffield writes:
>>>
 On Thu, Nov 03, 2005 at 12:48:53PM -0800, Erast Benson wrote:
> CDDL works similar way, except on per-file basis.

 This is incomprehensible gibberish.
>>>
>>> This is unsupportable hyperbole.  Erast's statement may be inapt,
>>> wrong, misleading, or have any number of other flaws, but it is
>>> neither incomprehensible nor gibberish.
>>
>> I do not comprehend what he means with "CDDL works on a per-file basis,
>> GPL does not".  One can of course create a project made up of GPL'ed
>> source files and other source files with different, GPL-compatible
>> licenses.
>
> The CDDL (based as it is on the MPL) allows you to mix CDDL-licensed
> files in a project with files under CDDL-incompatible licenses and
> distribute the resulting executable.

Sorry, I didn't imagine that a license with such a clause exists, and
less that anybody would call it free.

Thanks for the clarification,
Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: postinst scripts failing because a new conffile wasn't accepted: Is it a bug?

[Frank Küster]

Hi Petter, hi all,

(Sorry I didn't have time to watch your movies yet)

This thread turned to be very interesting in the light of the recent
discussion on -tetex-maint about TEXMF tree reorganization.

Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:

> Or even better, ship the defaults in /usr/share/, load them from there
> and load overrides from /etc/ if a file exist there.  If you want the
> package to have install time defaults, generate the file in /etc/
> based on install time input.  This way you can handle upgrades
> gracefully when changing the defaults, without loosing local
> configuration overrides.

Actually that wouldn't be hard for teTeX, since it looks for texmf.cnf
at multiple places and reads them all.  Even the order is as intended -
a file in /etc/texmf would override settings from the file in
/usr/share/texmf.

However, I don't see how I can handle the fact that there is an unknown
number of add-on-TeX-packages that might each provide a snippet for the
configuration file.  Currently we do this with an update-texmf program
that merges the snippets in /etc/texmf/texmf.d/ (ours and from add-on
packages) into the effective configuration file below /var.  Having
three files - ours in /usr/share/texmf/, a package-specific, generated
one in /var/lib/texmf with the source files in /etc/texmf/texmf.d/, and
the one for the local admin as /etc/texmf/texmf.cnf seems confusing to
me.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

dput works but dupload does not -- illegal PORT command

[Adam Kessel]

Starting some time in the past month, dupload always gives this error
after checking the package and making the initial connection to the
anonymous FTP upload queue:

 dupload fatal error: Can't upload (package).dsc: Illegal PORT command.
 at /usr/bin/dupload line 508

Yet dput works fine.

Any suggestions what's wrong? Has anyone else been having htis problem?
-- 
Adam Rosi-Kessel
http://adam.rosi-kessel.org


signature.asc
Description: Digital signature

Re: Debian based GNU/Solaris: pilot program

[Florian Weimer]

* Wouter Verhelst:

>> Lets assume you have GPL-ed project dpkg. Any change to foo.c must be
>> contributed back to the community.
>
> No, that's not true.
>
> Any *distributed* changes to foo.c must be contributed back to the
> community.

Huh?  Why do you think so?


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

Re: Debian based GNU/Solaris: pilot program

[Michael Poole]

Frank Küster writes:

> Michael Poole <[EMAIL PROTECTED]> wrote:
>
>> Andrew Suffield writes:
>>
>>> On Thu, Nov 03, 2005 at 12:48:53PM -0800, Erast Benson wrote:
 CDDL works similar way, except on per-file basis.
>>>
>>> This is incomprehensible gibberish.
>>
>> This is unsupportable hyperbole.  Erast's statement may be inapt,
>> wrong, misleading, or have any number of other flaws, but it is
>> neither incomprehensible nor gibberish.
>
> I do not comprehend what he means with "CDDL works on a per-file basis,
> GPL does not".  One can of course create a project made up of GPL'ed
> source files and other source files with different, GPL-compatible
> licenses.

The CDDL (based as it is on the MPL) allows you to mix CDDL-licensed
files in a project with files under CDDL-incompatible licenses and
distribute the resulting executable.  The GPL applies to the work as a
whole.  The relevant sections of the GPL are below; this trait is why
people say that, even though CDDL is a copyleft license, it allows
developers to create proprietary applications on top of the CDDL base.

  1.3. "Covered Software" means (a) the Original Software, or (b)
Modifications, or (c) the combination of files containing Original
Software with files containing Modifications, in each case
including portions thereof.

  1.9. "Modifications means the Source Code and Executable form of any
of the following:
A. Any file that results from an addition to, deletion from or
modification of the contents of a file containing Original
Software or previous Modifications;
B. Any new file that contains any part of the Original Software or
previous Modification; or
C. Any new file that is contributed or otherwise made available
under the terms of this License.

  1.12. "Source Code" means (a) the common form of computer software
code in which modifications are made and (b) associated
documentation included in or with such code.

  3.1. Availability of Source Code.
Any Covered Software that You distribute or otherwise make
available in Executable form must also be made available in Source
Code form and that Source Code form must be distributed only under
the terms of this License. You must include a copy of this License
with every copy of the Source Code form of the Covered Software
You distribute or otherwise make available. You must inform
recipients of any such Covered Software in Executable form as to
how they can obtain such Covered Software in Source Code form in a
reasonable manner on or through a medium customarily used for
software exchange.

Does this help?

Michael Poole

Re: per-user temp directories by default?

[Jon Dowland]

On Fri, Nov 04, 2005 at 01:00:48PM +0100, Klaus Ethgen wrote:
> With tempdir in users home all applications like for example gpg write
> temporary files to this location which ends up unencrypted on a disk

...alongside the private keys in ~/.gnupg?

-- 
Jon Dowland
http://jon.dowland.name/


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

Re: per-user temp directories by default?

[Frank Küster]

Klaus Ethgen <[EMAIL PROTECTED]> wrote:

> Am Fr den  4. Nov 2005 um  5:16 schrieb Noah Meyerhans:
>> Within the security team, there has recently been some talk of pushing
>> for per-user temp directories by default in etch.  I'd like to see what
>
> That whould be no good idea for security environment where you do
> special think to secure /tmp (make it in memory and encrypt swap). With
> tempdir in users home all applications like for example gpg write
> temporary files to this location which ends up unencrypted on a disk or,
> more bad over an unsecure NFS share to the fileserver.

What do the security people mean with per-user temp directories?  It's
clear that $HOME/tmp would be bad, but /tmp/$USERNAME/ with proper
permissions doesn't sound so awkward.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: per-user temp directories by default?

[Lars Wirzenius]

pe, 2005-11-04 kello 13:00 +0100, Klaus Ethgen kirjoitti:
> Am Fr den  4. Nov 2005 um  5:16 schrieb Noah Meyerhans:
> > Within the security team, there has recently been some talk of pushing
> > for per-user temp directories by default in etch.  I'd like to see what
> 
> That whould be no good idea for security environment where you do
> special think to secure /tmp (make it in memory and encrypt swap). With
> tempdir in users home all applications like for example gpg write
> temporary files to this location which ends up unencrypted on a disk or,
> more bad over an unsecure NFS share to the fileserver.
> 
> Please don't do this by default as it break the security of many, many
> systems!

I don't think the suggestion was to make TMP=~/tmp, but TMP=/tmp/$USER,
where /tmp/$USER is owned by the user in question and is inaccessible to
others. Or perhaps I read too much into the proposal?

-- 
Communication via acronyms is rfs.


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

Re: per-user temp directories by default?

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am Fr den  4. Nov 2005 um  5:16 schrieb Noah Meyerhans:
> Within the security team, there has recently been some talk of pushing
> for per-user temp directories by default in etch.  I'd like to see what

That whould be no good idea for security environment where you do
special think to secure /tmp (make it in memory and encrypt swap). With
tempdir in users home all applications like for example gpg write
temporary files to this location which ends up unencrypted on a disk or,
more bad over an unsecure NFS share to the fileserver.

Please don't do this by default as it break the security of many, many
systems!

Regards
   Klaus Ethgen
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]>
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iQEVAwUBQ2tNcJ+OKpjRpO3lAQIDjQf5AWUOrviF019g2c1YntGlqAJS/TzRpwhi
KhHQK/PWuRwl/NmrALidtHe2YUhyisKa58wQ/kPRqTvf9aKrIlAMRFZFK4zYENO9
1441k2AuGmjkcoxMAptLYdc/rRujDJkxeVWwxmkmTj1nzzLVriCgLJgVoJZVzC+O
FXbWa5e7JyWASvYDQqkH2aut0RZwn9g43So8Y+SQOFCRC/qSXFkRIapsOe+PeXGc
9UtMw6BFQ8NrGyAsTaQBl6/AmcSEkOiY8BaJKrBoHfDrhjz6lftBvOoDOfGIYjbB
8cAasv+2eHUiv2FgHkK2imreo5TgjGx2MoFLHu51wwjNg2qtfC7Lvg==
=eXIw
-END PGP SIGNATURE-


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

Calculating deps size - splitting a package

[Marcin Owsiany]

Hi!

ekg2 consists of a main program, and a dozen or so plugins, currently
all in one package. Most of the dependancies come from shlibs, which
investigates both the main program and the plugins.

As it is with plugins, different people use different subsets of them.
Since the current setup causes the package to pull in such stuff as X or
libsqlite3, I want to split the plugins into different packages.

However creating one package for a plugin would be an overkill. So I
want to create some sets of plugins, to achieve a compromise between the
number of packages and the size of the dependancies for an average user.

Since there are currently 16 plugins, I don't want to investigate each
one manually. Ideally, there would be a tool, which would run ldd on
each plugin in turn and show the list of all direct and indirect
dependancies (with their installed-sizes) that adding the plugin in
question to a binary package would pull in. I am interested on the total
effect to an end-user, for each plugin.

Is there something like this (or close) available?

Marcin
-- 
Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216  FE67 DA2D 0ACA FC5E 3F75  D6F6 3A0D 8AA0 60F4 1216


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

Re: Transition time: KDE, JACK, arts, sablotron, unixodbc, net-snmp, php, ...

[Steve Langasek]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Nov 03, 2005 at 12:05:07AM +0100, Henning Makholm wrote:
> Scripsit Andreas Barth <[EMAIL PROTECTED]>
> > * Anthony Towns (aj@azure.humbug.org.au) [051101 17:23]:
> >> On Tue, Nov 01, 2005 at 12:41:09PM +0100, Henning Makholm wrote:

> >> > So, would anybody object if I set up a cronjob that emails the PTS
> >> > whenever a (source) package propagates to, or is removed from, testing?

> >> it's one of the things we agreed we wanted at the Vancouver
> >> meeting. I think there was going to be a -testing-changes list or
> >> something, perhaps?

> > We agreed to both maintainer mails (but PTS might be more appropriate
> > for that), and a summary to -testing-changes.
> > IOW, whoever shows code up for any of the tasks has some bonus points :)

> I have now a frst draft of a status-change mail system running.  it
> works from the archive mirror on merkel, and sends out mail to
> @packages.debian.prg, with Bcc to the PTS (under the
> 'summary' keyword documented for this purpose). It turns turns out
> that the PTS cannot by itself send mail to the "current maintainer" in
> default of explicit subscriptions.

> It does not yet produce -testing-changes emails. The list
> does exist but seems to carry only upload announcements for
> stable-security, for reasons not totally clear to me.

These are announcements of uploads that have been propagated to
testing-proposed-updates, fwiw.

> Comments welcome.

Thanks for running with this.  Ideally, we would get this integrated on
ftp-master, so that the mails could be triggered by britney rather than
being done post-hoc; this would also let us associate package removals with
comments from britney hints files, so that they could be incorporated into
the mails.  If you're interested in making this happen I'll be happy to give
you any info I can; though tbh, if I understood this part of the system very
well, I probably would have written a patch myself already. ;)

Cheers,
- -- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDa0bEKN6ufymYLloRAgvjAKCJ2wI5ByedvrbLTYwC2T0uA8EdZwCgx6z4
MrmQ63BoEe91ggUCQI3pbs0=
=1/wL
-END PGP SIGNATURE-


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

Re: Debian

[Bartosz Fenski aka fEnIo]

On Fri, Nov 04, 2005 at 10:21:12AM +0100, Torreggiani Marcello wrote:
> hi!

Hello.
 
> I had just installed Debian-Netinst, because I would a minimal installation 
> of Debian.
> 
> I have a wish, I would add a new partition profile to the installation 
> (when the installer program askes if you want an automatic partition 
> and it displays only one choice,computer Desktop)
> 
> How can I do?

I'm not sure wether you want to add partition after installation or during
it. Anyway in both cases that's not proper mailing list for such questions.

Please post them on debian-user or debian-itialian mailing list.

regards
fEnIo

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


signature.asc
Description: Digital signature

Bug#337401: ITP: ggz -- libraries, games, and programs for network and online games

[Peter Eisentraut]

Package: wnpp
Severity: wishlist
Owner: Peter Eisentraut <[EMAIL PROTECTED]>

* Package name: ggz
  Version : 0.0.12
  Upstream Author : Josef Spillner <[EMAIL PROTECTED]>
* URL : http://www.ggzgamingzone.org/
* License : GPL
  Description : libraries, games, and programs for network and online games

GGZ (which is a recursive acronym for GGZ Gaming Zone) develops libraries,
games and game-related applications for client-server online gaming.
Player rankings, game spectators, AI players and a chat bot are part of
this effort.

The previous ggz packages were removed from Debian because of RC bugs and
a missing maintainer.  A new packaging team with upstream involvement is
going to attempt to revive this effort.


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

Re: Unnecessary "Conflicts" with imap-server packages

[Gerrit Pape]

On Mon, Aug 29, 2005 at 11:41:47PM +1000, Hamish Moffatt wrote:
> On Mon, Aug 29, 2005 at 10:29:20AM +, Gerrit Pape wrote:
> > files.  I haven't heard any reason yet why splitting the packages would
> > be a bad thing.
> > 
> > And there's more advantages: it eases usage of different service
> > managers than sysvinit and init scripts, support of a different init
> > scheme can be done through an alternative package which 'provides' the
> > default *-run package; same for services running under a superserver,
> > and corresponding alternatives; it plays well with fully automated
> > installs; it separates services from programs.
> 
> These problems should be solved by discussion and generation of a
> policy. IMHO it would be better to have a consistent approach that
> didn't solve every problem (or had some other flaw) than to have
> each individual developer generate their own scheme.

Well, as far as my experience goes, simply discussing things doesn't
work out.  It stops at some time, and almost never reaches a real
solution.  Better introduce a technical solution that actually works,
and then come up for discussion.  If you re-read this thread, you see
the different opinions on how services and conflicts should be used, and
how my recommendation, already implemented in packages I maintain,
solves all this.

I still haven't heard any reason yet why splitting the packages would
be a bad thing, and tried to show the lots of advantages.

Regards, Gerrit.


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

Re: Debian based GNU/Solaris: pilot program

[Frank Küster]

Michael Poole <[EMAIL PROTECTED]> wrote:

> Andrew Suffield writes:
>
>> On Thu, Nov 03, 2005 at 12:48:53PM -0800, Erast Benson wrote:
>>> CDDL works similar way, except on per-file basis.
>>
>> This is incomprehensible gibberish.
>
> This is unsupportable hyperbole.  Erast's statement may be inapt,
> wrong, misleading, or have any number of other flaws, but it is
> neither incomprehensible nor gibberish.

I do not comprehend what he means with "CDDL works on a per-file basis,
GPL does not".  One can of course create a project made up of GPL'ed
source files and other source files with different, GPL-compatible
licenses. 

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Debian based GNU/Solaris: pilot program

[Wouter Verhelst]

On Thu, Nov 03, 2005 at 12:48:53PM -0800, Erast Benson wrote:
> On Thu, 2005-11-03 at 12:18 -0800, Thomas Bushnell BSG wrote:
> > The GPL does not force developers to "contribute their changes back".
> > That's exactly the *point*.
> Lets assume you have GPL-ed project dpkg. Any change to foo.c must be
> contributed back to the community.

No, that's not true.

Any *distributed* changes to foo.c must be contributed back to the
community. There's a major difference here.

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


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

Re: Debian based GNU/Solaris: pilot program

[Frank Küster]

Dalibor Topic <[EMAIL PROTECTED]> wrote:

> Thank you for your contribution to Debian.

;-)

This spares me an upload today...

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Debian

[Torreggiani Marcello]

hi!
 
I had just installed Debian-Netinst, because I 
would a minimal installation of Debian.
 
I have a wish, I would add a new partition profile 
to the installation (when the installer program askes if you want an automatic 
partition and it displays only one choice,computer Desktop)
 
How can I do?
 
Thank u
Byee
-Marcello 
TorreggianiE-Mail Address: [EMAIL PROTECTED]-

Re: per-user temp directories by default?

[sean finney]

hi,

On Thu, Nov 03, 2005 at 11:16:43PM -0500, Noah Meyerhans wrote:
> Within the security team, there has recently been some talk of pushing
> for per-user temp directories by default in etch.  I'd like to see what
> people's reaction to such a proposal would be.

granted that i don't know the specifics of this module, but from
my perspective i think it would be reasonable to include this in the
default setup.

> There are a number of outstanding "insecure tempfile vulnerabilities",
> and there has been some talk that they're both too numerous and of low
> enough impact that they're not even worth releasing DSAs for.  Never the
> less, they are potentially dangerous and should be dealt with on some
> level.  We believe that using libpam_tmpdir by default should make
> nearly all of these vulnerabilities cease to be relevant (there are some

well, cease to be relevant for releases after etch, maybe... but you
still have the lifespan of woody + sarge + etch during which they
would still be relevant.  so this isn't exactly an immediate benefit :)


sean


-- 


signature.asc
Description: Digital signature

Re: per-user temp directories by default? "Thu, 3 Nov 2005 23:16:43 -0500")

[Blars Blarson]

In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>> session optional pam_tmpdir.so
>Another potential problem is if a run a suid (non-root) program that
>attempts to create a file in $TMP.  But it's suid, so it doesn't run
>under my uid, and doesn't have permissions to write to $TMP.  But I've
>never run across that -- suid programs are pretty uncommon.

Some buildds use sudo rather than fakeroot.  This could cause problems
for them...  (like the /dev/null one being discussed on #debian-devel)

-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.


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

Bug#337379: ITP: smtpguard -- smtp flow control program

[Takuo KITAME]

Package: wnpp
Severity: wishlist
Owner: Takuo KITAME <[EMAIL PROTECTED]>


o Package name: smtpguard
  Version : 1.1.0
  Upstream Author : VA Linux Systems Japan, K.K.
* URL : http://sourceforge.net/projects/flexguard/
* License : GPL
  Description : smtp flow control program

   smtpguard is a point based monitoring system built to
   protect your incoming mail servers from spammers.
   Developed with ISP's in mind, smtpguard links directly into
   the smtp server and stores data in a local db (Berkeley db 4.2).
   For each RCPT TO: in a given session, the rule file is parsed
   and points tallied.  Based on points (or specific attributes of
   the session) multiple actions can be taken.  These include:
   rejecting mail, logging, sending an alert message, and so on.

   This software provides postfix's policy service daemon to use
   smtpguard with postfix.
 

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13-1-686
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)


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

Nexenta OS (GNU/Solaris) website is now open!

[Alex Ross]

http://www.gnusolaris.org is now open.

We got an overwhelming response! We simply could not process all requests for
the Pilot membership in a timely fashion. We do hope that people waiting for the
login user/password will see this message.

The rest information is on the website. We'll keep it current.

The Pilot is over. Thank you for your patience and your support!

Nexenta Team



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