Re: Free Game Console

[Adrian von Bidder]

On Saturday 30 April 2005 07.54, Dillinger wrote:
> Hi,
> I invented Macromedia Flash.
[...]

Can I get one of those things your're smoking?

-- vbi

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


pgp2E1218gns7.pgp
Description: PGP signature

Compiling on a Debian machine

[Shaun Jackman]

Hello,

How do I use a Debian machine, such as bruckner, to test a source
package by compiling for powerpc? I see bruckner has a sarge chroot.
What's the magic command to start the build in this chroot? I know of
pbuilder -- though I haven't used it much admittedly -- but there is
no pbuilder command in the path.

Thanks,
Shaun

Re: Upgrade dependencies of a package

[Sami Haahtinen]

Shaun Jackman wrote:
> Does apt-get have a command to upgrade all the dependencies of a
> package? Currently I use 'apt-cache show package' and upgrade each of
> the dependencies one by one, but it seems to me this is a job for
> apt-get if ever there was one. If this requires a new command, perhaps
> 'apt-get upgrade package' or 'apt-get upgrade-dep package'.

Better late than newer, debfoster has a function to upgrade all depends
at once.

- S


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

Re: Compiling on a Debian machine

[Andreas Metzler]

Shaun Jackman <[EMAIL PROTECTED]> wrote:
> How do I use a Debian machine, such as bruckner, to test a source
> package by compiling for powerpc? I see bruckner has a sarge chroot.
> What's the magic command to start the build in this chroot? I know of
> pbuilder -- though I haven't used it much admittedly -- but there is
> no pbuilder command in the path.

Hello,
There is no automatic building, you have change to the sarge chroot
using dchroot and use dpkg-buildpackage or whatever. If you are
missing build-dependencies you'll need to ask debian-admin to install
them.
 cu andreas
-- 
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
   http://downhill.aus.cc/


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

Re: Compiling on a Debian machine

[Peter Samuelson]

[Andreas Metzler]
> There is no automatic building, you have change to the sarge chroot
> using dchroot and use dpkg-buildpackage or whatever.

I could have sworn I'd heard about logging into debian machines as
'username+sarge' or similar, to get into chroots.  Is this not still
generally supported?


signature.asc
Description: Digital signature

Hey remember i told you about this Madeleine

[Vance Rocha]

To: Isaac
 
 
I was checking my email and saw this advertisement in it. just like you I =
was thinking this stuff will
not work its all a gimmic.. but even with my other half telling me im wast=
ing my money I went ahead
and purchased it. and I can tell you right now with a straight face im big=
ger than I have ever been in
my life in just 2 weeks my girth and length were outstanding I could easil=
y become a laddies man now!
 
In anycase I promised the company I would tell everyone I know about this =
amazing solution and I am
going to do just that. 
 
-- Forwarded message -- 
 
Take a look -> www.bellybeggers.com

Real Customer Testimonial 7


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

Re: woody-to-sarge test upgrade

[Cesar Martinez Izquierdo]

El Sábado 30 Abril 2005 01:42, [EMAIL PROTECTED] escribió:
> On Fri, Apr 29, 2005 at 10:46:39PM +0200, Guido Heumann wrote:
> > Bill Allombert schrieb:
> > > Hello Debian developers,
> >
> > [...]
> >
> > > Before I do more testing, I would like to make sure I know the proper
> > > procedure:
> > >
> > > 1) What is the recommend way to perform such upgrade ?
> >
> > I'm not a DD, but the release notes seem to recommend aptitude for
> > upgrades:
> > http://www.debian.org/releases/testing/i386/release-notes/ch-upgrading.en
> >.html#s-upgradingpackages
>
> Ah yes, aptitude dist-upgrade works much better and is non-interactive.
> That fix the problem with the needless removal of apache, etc.
>
> Thanks!

Even Bill (who is DD) did this mistake, despite this question has appeared 
before in the list.
This makes me think that a lot of people will have problems updating from 
Sarge, because they will not read the documentation.

Could we make this aptitude recommendation more visible in any way? This might 
help.

Regards,

  César

Re: Little help about Intel865PERLL with ICH5

[Peter Samuelson]

[Ivan Adams]
> Can you explain what do you mean? Thanks allot

As Jacob said, what you have isn't really RAID.  It's software RAID
(meaning, all the work is done on the host CPU, not on the IDE chip),
which loads a BIOS extension so that it works automatically in MS-DOS
and derivatives.  The Windows driver is also software RAID.  If you
paid extra money for the "RAID" feature, someone cheated you. :(

See http://linux.yyz.us/sata/faq-sata-raid.html for more information.

Unless you need to access the same RAID configuration between Linux and
some other OS, like Windows XP, you are best off ignoring the "RAID"
features and running the card purely as an IDE controller.  (You can
set up native Linux software RAID, same as you would with any other set
of IDE disks.)

If you *do* need to share a RAID partition with a legacy OS, see
questions 8 and 9 on the web page above.  As far as I know, Debian
doesn't have tools packaged for either solution mentioned.


signature.asc
Description: Digital signature

Re: woody-to-sarge test upgrade

[Bill Allombert]

On Sat, Apr 30, 2005 at 12:13:23PM +0300, Cesar Martinez Izquierdo wrote:
> El Sábado 30 Abril 2005 01:42, [EMAIL PROTECTED] escribió:
> >
> > Ah yes, aptitude dist-upgrade works much better and is non-interactive.
> > That fix the problem with the needless removal of apache, etc.
> >
> > Thanks!
> 
> Even Bill (who is DD) did this mistake, despite this question has appeared 
> before in the list.
> This makes me think that a lot of people will have problems updating from 
> Sarge, because they will not read the documentation.
> 
> Could we make this aptitude recommendation more visible in any way? This 
> might 
> help.

Yes...  I did not know "aptitude dist-upgrade" was different from "apt
dist-upgrade".  The woody aptitude manpage does not mention any command
line directive, and the sid manpage does not document the dist-upgrade
target, this is bug #268697.

For woody the recommend way was to use dselect, but this is an
interactive command so I could not use it in an automated test
framework.

FWIW, upgrading with dselect works, but installs all the recommends (as
expected).

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: Status of 'sarge' for the amd64 architecture

[Goswin von Brederlow]

Adrian Bunk <[EMAIL PROTECTED]> writes:

> Sorry, but I still don't understand it:
>
> You could continue to offer the complete archive as it is today, and it 
> shouldn't be a big amount of work to offer one or more partial archives 
> (e.g. only stable or only i386) from different locations - and a mirror 
> with bandwith problems could simply switch to using a partial archive.
>
> This wouldn't be as complicated as the SCC proposal, would have exactly 
> zero impact on release management and should be implemantable within a 
> few days.

Yes it absolutely would be trivial. All it needs is a script to make a
linkfarm and sync that daily. I can even give you a script for it.

> Considering that this might make it possible to ship amd64 with sarge 
> which would have a positive effect on the reputation of Debian, could 
> you please explain which technical problems I do oversee when thinking 
> that the technical problems of such a solution were small?
>
> If such a solution would e.g. take two weeks and would have been 
> implemented at the day of the SCC announcement, it was running for one 
> month today...
>
> Could someone please enlighten me?

Back when we asked for amd64 inclusion more than a year ago some
people just ignored it, hiding the (non) problem in the process for
many month. Then the same people don't want to do anything to fix the
problem easy and quickly but rather design a grand scheme to solve a
million problems at once with the Vancouver proposal. And through all
those delays we are now at the "Now it is too late to add amd64"
stage.


So, after letting off some steam, please consider some other things
adding amd64 would affect:

1. release team

Another arch to sync. And, as with every arch, there would be some
packages that fail just there. There are still a lot of amd64 specific
FTBFS bugs (lots of them with patches) that would all become RC. The
RC count would double overnight at least for a few weeks. (yeah, it
would be back down if this had happened weeks ago)

2. security ream

Who knows about amd64? Who is able to debug code to see if security
problems also exist there? Who will maintain the amd64 security buildd
(since us Non-DDs are not allowed)? Who will get the wanna-build
admins to add the amd64 buildd? Seeing as after over 6 month there are
still 2 of the old archs without a security buildd for testing this
seems to be a realy big problem.

3. britney

One more arch, 15K more packages to consider. Britney needs more ram,
more time, gets slower overall and probably fails more often. More
hints needed costing more manual time.

4. D-I docs and CDs

There are no docs covering amd64 yet as nobody has done any work in
that regard. Since amd64 is basicaly just a i386 on steroids adapting
those docs should be easy. But it has to be done. There are also some
(hopefully minor) quircks left in debian-cd to investigate. Might be
caused by the missing docs.



I do however feel that the need of Debians users to have amd64 over
the next 2 years till etch is out far outweights the inconvenience of
adding it. That's why the amd64 team, recently with much entusiasm
from other parts of the debian foodchain, is doing the inofficial
release in parallel with sarge.

Sources are the same, cdimages will be on cdimage.d.o, security
updates will follow debian closely. All that differs for users is that
ftp.debian.org is amd64.debian.net for the main archive and /debian
becomes /debian-amd64 for mirros. Maybe at some point someone up there
will decide to embrace amd64, move the files over to ftp-master and
call it official post datum.

>> Cheers,
>> Andi
>
>
> cu
> Adrian

MfG
Goswin


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

Virus ricevuto -- Virus received

[clienti]

  Questo messaggio e` stato automaticamente generato
per informarvi che un messaggio da voi inviato
(o inviato da un virus che ha falsificato il vostro
indirizzo email) e` stato bloccato dall'antivirus
installato su questo mail server. 
  Di seguito potete trovare alcuni dettagli relativi
al messaggio bloccato:
virus trovato (virus found): Worm.SomeFool.Gen-2
mittente protocollo (envelope from): debian-devel@lists.debian.org
mittente dichiarato (header from): debian-devel@lists.debian.org
destinatario (header to): [EMAIL PROTECTED]
oggetto (subject): warning

  This message has been automatically generated to
inform you that one of your emails has been discarded
by the antivirus installed on this mail server.
  The details above refer to the message which has
been blocked. Please verify the integrity of your system.


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

Re: woody-to-sarge test upgrade

[Steve Langasek]

Hi Bill,

On Fri, Apr 29, 2005 at 07:48:00PM +0200, Bill Allombert wrote:
> Before I do more testing, I would like to make sure I know the proper
> procedure:

> 1) What is the recommend way to perform such upgrade ?

I guess you've already got the answer for this.

> 2) How can I produce useful problem report ?

If there are easily discernable upgrade problems that are package-specific,
please file bugs on those packages directly.  Otherwise, you can file a bug
on the pseudo-package upgrade-reports, including as much info as possible,
and we'll try to sort it out.  At a minimum, we would want the command line
you ran for the upgrade, the version of the packaging tool in question that
was installed at the time, and any problems that you found after upgrade
(i.e., missing packages, regressions in functionality, ...)  Ideally, if
packages were removed that you believe should not have been, we would want
to see a full transcript of the upgrade.

Bugs filed against upgrade-reports are forwarded to the debian-testing
mailing list; people interested in helping to process these reports are
encouraged to subscribe to that list.

Cheers,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

libsasl2 and libmysql* updates for sarge

[Henrique de Moraes Holschuh]

On Mon, 25 Apr 2005, Steve Langasek wrote:
> Since dovecot, libnss-mysql, and libnss-mysql-bg have already been updated to
> use libmysqlclient12, the main reason for *not* updating cyrus-sasl2, the
> MTAs, and the ftp daemons (i.e.: segfaults from mixing and matching) no
> longer applies.  I would accept an update of cyrus-sasl2 built against
> libmysqlclient12, but I would prefer to see at least exim4 and postfix
> updated first.

Do you want an cyrus-sasl2 upload that conflicts with all packages depending
on both cyrus-sasl2 and libmysqlclient{!12} ?  I will bump the shlibdep info
as well.

I just need a list of the packages to conflict with, or a hint on how to
make such a list.

> Even if they weren't all done together, there's still a possibility of
> segfaults because of libnss-mysql right now, so it's worth transitioning as

The truth is libnss-mysql (and any other libnss-* of the sort) should
conflict with any libmysqlclient (or any other lib of the sort) it is not
linked to.  This is utter braindamage that can only be really fixed by
enforcing a versioned-symbols-or-die rule.

> Incidentally, I think cyrus-sasl2-mit's build-dep on libmysqlclient10-dev is
> spurious and should be dropped.

Please file a bug, I am not the maintainer for cyrus-sasl2-mit...

-- 
  "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: woody-to-sarge test upgrade

[Hamish Moffatt]

On Sat, Apr 30, 2005 at 11:43:49AM +0200, Bill Allombert wrote:
> Yes...  I did not know "aptitude dist-upgrade" was different from "apt
> dist-upgrade".  The woody aptitude manpage does not mention any command
> line directive, and the sid manpage does not document the dist-upgrade
> target, this is bug #268697.
> 
> For woody the recommend way was to use dselect, but this is an
> interactive command so I could not use it in an automated test
> framework.

dselect accepts command-line parameters too, but I don't know if that
would be sufficient.


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


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

Re: woody-to-sarge test upgrade

[Bill Allombert]

On Sat, Apr 30, 2005 at 11:44:38PM +1000, Hamish Moffatt wrote:
> On Sat, Apr 30, 2005 at 11:43:49AM +0200, Bill Allombert wrote:
> > Yes...  I did not know "aptitude dist-upgrade" was different from "apt
> > dist-upgrade".  The woody aptitude manpage does not mention any command
> > line directive, and the sid manpage does not document the dist-upgrade
> > target, this is bug #268697.
> > 
> > For woody the recommend way was to use dselect, but this is an
> > interactive command so I could not use it in an automated test
> > framework.
> 
> dselect accepts command-line parameters too, but I don't know if that
> would be sufficient.

Ah thanks! It looks sufficient to do 'dselect update && dselect install',
but apparently it is not better than 'apt-get dist-upgrade', so I will
stick to 'aptitude dist-upgrade'.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Bug#307079: ITP: libcarats-ruby -- Ruby Carats, the Ruby toolchest

[Paul van Tilburg]

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

* Package name: libcarats-ruby
  Version : 0.3.0
  Upstream Author : Thomas Sawyer <[EMAIL PROTECTED]> and others
* URL : http://calibre.rubyforge.org/
* License : Ruby, GPL, LGPL, MIT, or Artistic
  Description : Ruby Carats, the Ruby toolchest libraries

This library is a higher-level general purpose library which includes
classes, modules, mixins, and other assorted additions.  Examples include
an ordered hash, module macros for dynamic mixins, attribute casters, etc.

Ruby Facets is part of the Calibre project, an open API repository
project for the Ruby programming language.  You can learn more at:
http://calibre.rubyforge.com

This package is part of the Ruby library extras, a supplement to Ruby's
standard library.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (102, 'experimental')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.10-powerpc
Locale: LANG=C, [EMAIL PROTECTED] (charmap=UTF-8)


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

Bug#307078: ITP: libfacets-ruby -- Ruby Fantasic Atomic Core Extensions library

[Paul van Tilburg]

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

* Package name: libfacets-ruby
  Version : 0.7.0
  Upstream Author : Thomas Sawyer <[EMAIL PROTECTED]>
* URL : http://calibre.rubyforge.org/
* License : GPL/Ruby (dual-licensed)
  Description : Ruby Fantasic Atomic Core Extensions libraries

This Ruby library set is a growing collection of extension methods for
Ruby's core and standard library.  It is an atomic library in that the
methods are, to the greatest degree reaonable, requirable individually so
that each can be required independently.

Ruby Facets is part of the Calibre project, an open API repository
project for the Ruby programming language.  You can learn more at:
http://calibre.rubyforge.com

This package is part of the Ruby library extras, a supplement to Ruby's
standard library.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (102, 'experimental')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.10-powerpc
Locale: LANG=C, [EMAIL PROTECTED] (charmap=UTF-8)


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

Bug#307080: ITP: libbreakpoint-ruby -- Ruby library for adding breakpoints to Ruby program

[Paul van Tilburg]

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

* Package name: libbreakpoint-ruby
  Version : 0.5.0
  Upstream Author : Florian Gross <[EMAIL PROTECTED]>
* URL : http://ruby-breakpoint.rubyforge.org/
* License : GPL/Ruby (dual-licensed)
  Description : Ruby library for adding breakpoints to Ruby program

Ruby-breakpoint lets you inspect and modify state at run time.  This
allows you to diagnose bugs, patch applications and more all via IRB by
simply doing a method call at the place you want to investigate.

This package is part of the Ruby library extras, a supplement to Ruby's
standard library.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (102, 'experimental')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.10-powerpc
Locale: LANG=C, [EMAIL PROTECTED] (charmap=UTF-8)


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

PHP/WebApp policy/mailing list

[Neil McGovern]

Hi all,

There's been a bit of discussion[0] recently on the debian-security list
with regards to how include()ed files should be handled.

I think that, due to the large number of packages that are webapps, a
policy shoudl be created on how we handle these.
To do this, it would be a good idea IMO to have a maining list. This has
already been suggested[1][2], and I agree that a debian-webapp list
should be created.
Before I retitle this bug, I'd like opinions on if this is a good idea
or not.

There seems to be some work already completed on a php policy[3] but I'm
not sure what progress has been made recently :)

All the best,
Neil McGovern
[0] http://lists.debian.org/debian-security/2005/04/msg00103.html
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=264069
[2] http://lists.debian.org/debian-devel/2004/08/msg01976.html
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265113
-- 
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?
gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li B345BDD3


signature.asc
Description: Digital signature

Re: PHP/WebApp policy/mailing list

[sean finney]

On Sat, Apr 30, 2005 at 05:32:35PM +0100, Neil McGovern wrote:
> There's been a bit of discussion[0] recently on the debian-security list
> with regards to how include()ed files should be handled.

and this for the most part is a good practice.  if the file does not
need to be directly accessed by web clients, it should not be underneath
the web accessible directories.  that said, there are a lot of projects
in which that distinction is blurred, and in some cases it may not be
at all feasible.

i think a general guideline should be that any "include" files are
either impotent if fetched remotely (naming most php inlcude files to
end in php can often achieve this), or better, restricted from being
accessed at all via web server access controls (htaccess for apache)
or placed outside of a fetchable root[1].  this is in order of least
to most preference.

> I think that, due to the large number of packages that are webapps, a
> policy shoudl be created on how we handle these.

some time ago i wrote a rough outline of a policy[2], though there
remains much to be added to this.  at the time i decided it was a bit
too much work and too broad of a subject to be tackled at once, so
i then decided to focus on the database-specific portion of it[3],
thinking that the practices, trends, tools, and development methods could
be extrapolated.  

> To do this, it would be a good idea IMO to have a maining list. This has
> already been suggested[1][2], and I agree that a debian-webapp list
> should be created.

i also think such an idea would be very useful, and i would certainly
join up in said list.


sean

-- 
[1] prepending to php_include_path in a debian-centric config file is an easy
way to achieve this for php pages.
[2] http://people.debian.org/~seanius/policy/webapp-policy.html
[3] http://people.debian.org/~seanius/policy/dbapp-policy.html


signature.asc
Description: Digital signature

Re: PHP/WebApp policy/mailing list

[Jeroen van Wolffelaar]

On Sat, Apr 30, 2005 at 01:00:18PM -0400, sean finney wrote:
> On Sat, Apr 30, 2005 at 05:32:35PM +0100, Neil McGovern wrote:
> > There's been a bit of discussion[0] recently on the debian-security list
> > with regards to how include()ed files should be handled.
> 
> and this for the most part is a good practice.

Please, this mail is about whether to start a mailinglist, not to rehash
a discussion going on elsewhere already.

Ontopic -- yeah, I think it's a good idea for having a web application
mailinglist, as also has been suggested at least several times in the
past.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl

Re: PHP/WebApp policy/mailing list

[Alexis Sukrieh]

Neil McGovern a écrit :
To do this, it would be a good idea IMO to have a maining list. This has
already been suggested[1][2], and I agree that a debian-webapp list
should be created.
I also think this is a good idea. Several times in the past I'd loved to 
mail such a mailing list when I faced webapp packaging issues.

Before I retitle this bug, I'd like opinions on if this is a good idea
or not.
I think this is a good idea.
I also think that we should have a specific  section in the Debian 
Policy for answering common questions such as:
  - where should I put CGI files if they're not architecture dependant?
(such as PHP or Perl scripts).
  - Should we provide template files as conffiles?

We also might strongly suggest the use of wwwconfig and dbconfig in such 
a policy section...

Anyway, if such a mailing list arise, I'll be in the party ;)
--
Alexis Sukrieh

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

Re: PHP/WebApp policy/mailing list

[Stephen Gran]

This one time, at band camp, Alexis Sukrieh said:
> Neil McGovern a écrit :
> 
> >To do this, it would be a good idea IMO to have a maining list. This has
> >already been suggested[1][2], and I agree that a debian-webapp list
> >should be created.
> 
> I also think this is a good idea. Several times in the past I'd loved to 
> mail such a mailing list when I faced webapp packaging issues.
> 
> >Before I retitle this bug, I'd like opinions on if this is a good idea
> >or not.
> 
> I think this is a good idea.
> 
> I also think that we should have a specific  section in the Debian 
> Policy for answering common questions such as:
>   - where should I put CGI files if they're not architecture dependant?
> (such as PHP or Perl scripts).
>   - Should we provide template files as conffiles?
> 
> We also might strongly suggest the use of wwwconfig and dbconfig in such 
> a policy section...
> 
> Anyway, if such a mailing list arise, I'll be in the party ;)

I'm happy to host it until it gets onto a debian.org machine.  If people
feel like there's a need, let me know.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


pgpJFY5J8rXvz.pgp
Description: PGP signature

Outrageous Maintainer

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

this is a maybe bit OT mail to this List but I think as improoving the
quality of debian is a bit toppic of the list.

The problem is that I do not know how to handle with a bug. The
maintainer of this bug is not in the mood to fix the bug he rather
slight the submitters (not only me) in the bugreport and also by private
mail.

The according bug is #306608.

I honore the work, maintainers do. But this subject do not increase the
trust in debian as whole and in the packages of him specialy. I thought
that there is a minimum of social competence to get debian maintainer
but I have to see that this was a wrong assument. :-(

Regards
   Klaus
- -- 
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.0 (GNU/Linux)

iQEVAwUBQnPOzp+OKpjRpO3lAQLhcQgAqUUVlUmjGxUXi7Wg6fJ6Wa5Fc1Lbtq3X
XWczK9l/i7IJPOMb7jnAan6slZSIQVxj9DsP73SQfSf05KhLLtEmwyOhyjZO4cLt
pkq5SZaQ9nw/RdmQpp/tO1ddzf7BrH/HNknFnI4qZOyQeBEeNY9xSZtkuOitvgmL
lTqafk4vv2SyBJN8pJzGtlk7DqA/ae+ayhLXVNAFIbP67JVnHjzLQPPWkTpo6hUd
60AFx80a0PtIWEO5Dsq9Iiss6NjBITp52s0txxIf239HcPFST2tUMNbVlsMqb7Di
HEiqh7YmfZ/L2TsNKClllDmV4NRJSuaI9NYsA6gTPUB5nlRpp9fn2w==
=04JX
-END PGP SIGNATURE-


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

Re: Outrageous Maintainer

[sean finney]

On Sat, Apr 30, 2005 at 08:30:38PM +0200, Klaus Ethgen wrote:
> The according bug is #306608.

having read through the bug report, it seems to me the appropriate thing
to have done all along was add a Conflicts statement, which really does
no harm and does resolve the issue.

HOWEVER, that said, the maintainer seems set in his ways, and maybe
there's something i don't know.  if you really feel the maintainer should
be forced to fix the problem as was proposed, there does exist a means
of arbitrating this argument[1][2].


sean

-- 
[1] 
http://www.nl.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-bug-housekeeping
[2] i don't know if this applies to non-dd's, but you could find a
sponsor for it if it did.


signature.asc
Description: Digital signature

Re: Outrageous Maintainer

[Josselin Mouette]

Le samedi 30 avril 2005 à 15:06 -0400, sean finney a écrit :
> On Sat, Apr 30, 2005 at 08:30:38PM +0200, Klaus Ethgen wrote:
> > The according bug is #306608.
> 
> having read through the bug report, it seems to me the appropriate thing
> to have done all along was add a Conflicts statement, which really does
> no harm and does resolve the issue.

As I understand the issue, I have to agree with the maintainer: the
conflict statement should be added in the wxwidgets 2.5 packages, not
the 2.4 ones. Adding it in the 2.4 packages is completely useless upon
upgrades.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

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: Outrageous Maintainer

[Henrique de Moraes Holschuh]

(reply to public mail sent to d-devel).

On Sat, 30 Apr 2005, Klaus Ethgen wrote:
> The problem is that I do not know how to handle with a bug. The
> maintainer of this bug is not in the mood to fix the bug he rather
> slight the submitters (not only me) in the bugreport and also by private
> mail.

If I were him, I would not adopt the requested fix either, as it is wrong.

If the 2.5 package replaces the 2.4 packages, it *MUST* conflict with it and
that's the beginning and end of it.  Replaces: without Conflicts: is used in
special circunstances (most of the time versioned), e.g., to move files from
a package to another.  And in that case, it *always* must be coordinated
between the two packages, which evidendly is not the case here.

> I honore the work, maintainers do. But this subject do not increase the
> trust in debian as whole and in the packages of him specialy. I thought
> that there is a minimum of social competence to get debian maintainer
> but I have to see that this was a wrong assument. :-(

He is only human, therefore he has a finite ammount of patience, that
apparently run out.  That's a shame, of course, he should have known better
than to let it get to him, or to let a BTS thread degrade to such levels.
Every time a DD talks back insultingly to an user, he has lost the argument.

Ron, please, the next time you feel like insulting someone while wearing
your Debian Developer hat (and regardless of whether they deserve it or
not), DON'T.  And the wontfix tag exists just for the kind of issue you had
on that bug report, so please consider using it (after reassigning one of
the bugs, or them all, to the offending package).

As for you, Klaus, what were you thinking when you replied in a tone like
that to someone that was obviously pretty much pissed off?  Regardless of
whether he should have replied to you in an insulting tone or not, you *did*
ask for trouble.  Let the matter drop, you are not helping.


-- 
  "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: Outrageous Maintainer

[Henrique de Moraes Holschuh]

On Sat, 30 Apr 2005, sean finney wrote:
> having read through the bug report, it seems to me the appropriate thing
> to have done all along was add a Conflicts statement, which really does
> no harm and does resolve the issue.

Wrong.  The other package has a broken replaces header, without the required
conflicts header it needs to have.

-- 
  "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: Outrageous Maintainer

[sean finney]

On Sat, Apr 30, 2005 at 04:36:29PM -0300, Henrique de Moraes Holschuh wrote:
> Wrong.  The other package has a broken replaces header, without the required
> conflicts header it needs to have.

yeah, looks like i was.  that said, the rest of my response (this should
be forwarded to the tech committee if he really cares) still holds.

sean

-- 


signature.asc
Description: Digital signature

Re: Outrageous Maintainer

[Adam M.]

Anthony DeRobertis wrote:

>Klaus Ethgen wrote:
>
>  
>
>>The according bug is #306608.
>>
>>
>
>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.
>  
>

I haven't read the bug report, but when a newer package replaces an
older one, you need to have add a
Conflicts: 
Replaces: 
To the new package. I think apt-get, dselect and others have been set up
in this manner.

It is not correct to put Conflicts in the 2.4 package because it is 2.5
that *caused* the conflict. It came on the scene AFTER 2.4, right?

- Adam



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

Re: Outrageous Maintainer

[Goswin von Brederlow]

Anthony DeRobertis <[EMAIL PROTECTED]> writes:

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

wxpython2.5.3 replaces libwxgtk2.4-python. It may thus overwrite files
also present in libwxgtk2.4-python.

The reverse is not true. libwxgtk2.4-python does not replace
wxpython2.5.3 and may not overwrite files of wxpython2.5.3. Not even
files it formerly owned. dpkg doesn't know what files got replaced.

A Replaces without a Conflicts is I think always wrong. If you replace
something you MUST make sure the other package gets updated to a
version without the file. Otherwise you run into problems just like
this one. The other one is that removing wxpython2.5.e will remove
files of libwxgtk2.4-python leaving it broken.


So the maintainer has a bit of a point there.

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

I think the right solution is to reassign the bug to "wxpython2.5.3,
libwxgtk2.4-python". That way there is only one bug about the problem
and it shows up on both packages bug list. Everyone can see whats
going on and the wxpython2.5.3 maintainer gets all the complaints from
libwxgtk2.4-python users too.

MfG
Goswin


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

Re: Compiling on a Debian machine

[Shaun Jackman]

On 4/30/05, Peter Samuelson <[EMAIL PROTECTED]> wrote:
> 
> [Andreas Metzler]
> > There is no automatic building, you have change to the sarge chroot
> > using dchroot and use dpkg-buildpackage or whatever.
> 
> I could have sworn I'd heard about logging into debian machines as
> 'username+sarge' or similar, to get into chroots.  Is this not still
> generally supported?

ssh [EMAIL PROTECTED] didn't work for me, but that
would be very cool!

Cheers,
Shaun

Re: Compiling on a Debian machine

[Shaun Jackman]

On 4/30/05, Andreas Metzler <[EMAIL PROTECTED]> wrote:
> Shaun Jackman <[EMAIL PROTECTED]> wrote:
> > How do I use a Debian machine, such as bruckner, to test a source
> > package by compiling for powerpc? I see bruckner has a sarge chroot.
> > What's the magic command to start the build in this chroot? I know of
> > pbuilder -- though I haven't used it much admittedly -- but there is
> > no pbuilder command in the path.
> 
> Hello,
> There is no automatic building, you have change to the sarge chroot
> using dchroot and use dpkg-buildpackage or whatever. If you are
> missing build-dependencies you'll need to ask debian-admin to install
> them.
>  cu andreas

Thanks! Worked like a charm.

Cheers,
Shaun

Re: Outrageous Maintainer

[Steve Langasek]

On Sat, Apr 30, 2005 at 03:06:31PM -0400, sean finney wrote:
> On Sat, Apr 30, 2005 at 08:30:38PM +0200, Klaus Ethgen wrote:
> > The according bug is #306608.

> having read through the bug report, it seems to me the appropriate thing
> to have done all along was add a Conflicts statement, which really does
> no harm and does resolve the issue.

Sorry, but insisting that a maintainer add a Conflicts: against a separately
RC-buggy package which is not in testing and will shortly be removed from
unstable is just silly.  It can be done, but for the most part this bug is
going to resolve itself, and there's no reason the maintainer should treat
adding this conflict as a high priority under the circumstances.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Free Game Console

[Michelle Konzack]

Am 2005-04-30 09:51:09, schrieb Adrian von Bidder:
> On Saturday 30 April 2005 07.54, Dillinger wrote:
> > Hi,
> > I invented Macromedia Flash.
> [...]
> 
> Can I get one of those things your're smoking?

No Adrian, please, keep clean...
You need your brain for better things.

> -- vbi

Greetings
Michelle

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: Outrageous Maintainer

[Otavio Salvador]

> "steve" == Steve Langasek <[EMAIL PROTECTED]> writes:

steve> On Sat, Apr 30, 2005 at 03:06:31PM -0400, sean finney
steve> wrote:
>> On Sat, Apr 30, 2005 at 08:30:38PM +0200, Klaus Ethgen wrote: >
>> The according bug is #306608.

>> having read through the bug report, it seems to me the
>> appropriate thing to have done all along was add a Conflicts
>> statement, which really does no harm and does resolve the
>> issue.

steve> Sorry, but insisting that a maintainer add a Conflicts:
steve> against a separately RC-buggy package which is not in
steve> testing and will shortly be removed from unstable is just
steve> silly.  It can be done, but for the most part this bug is
steve> going to resolve itself, and there's no reason the
steve> maintainer should treat adding this conflict as a high
steve> priority under the circumstances.

But you remove the package from testing doesn't mean we won't have
users with it installed since it was present there so, IMHO, the
Conflict is need.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


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

Re: Outrageous Maintainer

[Jeroen van Wolffelaar]

On Sat, Apr 30, 2005 at 06:45:26PM -0300, Otavio Salvador wrote:
> But you remove the package from testing doesn't mean we won't have
> users with it installed since it was present there so, IMHO, the
> Conflict is need.

The bug is in the other package, packages are not required to work
around other bugs in other packages, that'd be a gigantic mess of
workarounds. If dash breaks using my package for whatever reason, I'm
not going to add a conflict: dash (with non-fixed version or whatever),
dash needs to fix it.

Ditto here, and the fix is removing the package.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


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

transcode

[Frederico Rodrigues Abraham]

   having problems installing trancode on debian testing
   -- Fred
ike:~# apt-get install transcode
Reading Package Lists... Done
Building Dependency Tree... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
Since you only requested a single operation it is extremely likely that
the package is simply not installable and a bug report against
that package should be filed.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
 transcode: Depends: libavifile-0.7c102 (>= 1:0.7.38.20030710-1.2) but 
it is not installable
E: Broken packages

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

Re: transcode

[Josselin Mouette]

Le samedi 30 avril 2005 à 20:22 -0300, Frederico Rodrigues Abraham a
écrit :
> having problems installing trancode on debian testing
> -- Fred
> 
> ike:~# apt-get install transcode

This package isn't in the official Debian archive. You should probably
contact directly the one who's providing it.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

Re: libsasl2 and libmysql* updates for sarge

[Steve Langasek]

On Sat, Apr 30, 2005 at 10:03:01AM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 25 Apr 2005, Steve Langasek wrote:
> > Since dovecot, libnss-mysql, and libnss-mysql-bg have already been updated 
> > to
> > use libmysqlclient12, the main reason for *not* updating cyrus-sasl2, the
> > MTAs, and the ftp daemons (i.e.: segfaults from mixing and matching) no
> > longer applies.  I would accept an update of cyrus-sasl2 built against
> > libmysqlclient12, but I would prefer to see at least exim4 and postfix
> > updated first.

> Do you want an cyrus-sasl2 upload that conflicts with all packages depending
> on both cyrus-sasl2 and libmysqlclient{!12} ?  I will bump the shlibdep info
> as well.

I'd rather not have either conflicts or a shlibdep bump here, because I
think there's a diminishing-returns argument against it: conflicts in
particular make upgrades painful, and shlibdeps have no bearing on plugins.

> > Even if they weren't all done together, there's still a possibility of
> > segfaults because of libnss-mysql right now, so it's worth transitioning as

> The truth is libnss-mysql (and any other libnss-* of the sort) should
> conflict with any libmysqlclient (or any other lib of the sort) it is not
> linked to.  This is utter braindamage that can only be really fixed by
> enforcing a versioned-symbols-or-die rule.

It's braindamage that we've lived with for a while, without major incident;
while I want to eliminate as much of it as possible, it doesn't seem to be
enough of a problem in practice to justify making it harder to upgrade in
the general case.

> > Incidentally, I think cyrus-sasl2-mit's build-dep on libmysqlclient10-dev is
> > spurious and should be dropped.

> Please file a bug, I am not the maintainer for cyrus-sasl2-mit...

Oh, but you offered to take care of it, I thought :)

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: transcode

[Stephen Cormier]

On April 30, 2005 08:22 pm, Frederico Rodrigues Abraham wrote:
>  apt-get install transcode
Try  apt-get install transcode libavifile-0.7c102/unstable and see if 
that helps.

Stephen
-- 
Debian the choice of a GNU generation.

GPG Public Key: http://users.eastlink.ca/~stephencormier/publickey.asc


pgphA0qLv7g8r.pgp
Description: PGP signature

Ubuntu and its "appropriation" of Debian maintainers

[Adam Majer]

Hi,

I just search Google for me and I found this,

https://launchpad.ubuntu.com/people/adamm/

Now, I never signed up to be a maintainer for Ubuntu. I don't understand
why I am part of "people of Ubuntu" or why I am listed as a maintainer
of any package on Ubuntu's website? I know Ubuntu is using my packages
as part of their distribution. I have no problem with that. What I do
have a problem is the use of my name and my resources (time) in
association with Ubuntu *without* my permission.


Well, at least on pages like,

http://packages.ubuntu.com/hoary/misc/mysql-query-browser

They have "Adam Majer is responsible for this Debian package" with a
link to Debian's QA. This reference I find acceptable, but better
wording would be "Adam Majer is responsible for the Debian version of
this package".


Then I also found,
http://ubuntu.linux-server.org/mysql-query-browser/mysql-query-browser_1.1.4-1ubuntu2.dsc

[EMAIL PROTECTED]:/tmp$ gpg --verify mysql-query-browser_1.1.4-1ubuntu2.dsc
gpg: Signature made Tue 19 Apr 2005 10:06:56 AM CDT using DSA key ID
C098EFA8
gpg: please do a --check-trustdb
gpg: Good signature from "[EMAIL PROTECTED] <[EMAIL PROTECTED]>"
gpg: aka "shermann <[EMAIL PROTECTED]>"
gpg: aka "Stephan Hermann <[EMAIL PROTECTED]>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 3D8B 5138 0852 DA7A B83F  DCCB C189 E733 C098 EFA8

This package was modified from the Debian package (probably as simple as
just rebuilding the automake files because they were quite old). I don't
understand how I could remain as the maintainer of such a package. It is
my belief that if the source code is changed, then the Maintainer field
should be changed as well.

In Debian we do this all the time (NMUs), but Ubuntu is not Debian and
the upload was not to Debian. If there are problems with the Ubuntu
package I cannot fix it yet the problem will be attributed to me (as I'm
the "maintainer").


Anyway, the bottom line is,
1. I'm a Debian Developer and chose to be associated with Debian
2. I have not chosen or gave permission to be associated with
modified/unmodified packages of other distributions (that may or may not
derive from Debian).

What do other DDs think about this problem (or is it even a problem?)?
Personally, I believe Ubuntu must either change the Maintainer field of
all packages such that it points to Ubuntu Developers *or* get
permission to keep the Maintainer field as is from the Debian package
maintainer.

- Adam

PS. This is not a troll against Ubuntu.

PPS. This is not like writing software where the author has a copyright
on the source code and have it displayed. There is a fundamental
difference between "copyright holder" and "maintainer", so please don't
confuse the two.



signature.asc
Description: OpenPGP digital signature

Re: transcode

[John Hasler]

Transcode is not in Debian because the codecs are not DFSG-compliant.
Look at  for an unofficial package.
-- 
John Hasler


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

Re: Key Signing in Vancouver, BC

[ms419]

Alright! Let's all meet at 12:30 on Wednesday, May 4th at Kirin Sushi - 
across the street from the New Westminster SkyTrain station - 31 8th St 
- (604) 521-1833

Remember photo id & your gpg fingerprint
http://cgi.sfu.ca/~jdbates/moin/moin.cgi/KeySigningParty
Pete Lypkie is organizing another key signing party on Thursday, May 
5th at 7:00 at the SFU campus pub - 
http://www.sfu.ca/~plypkie/keysigning.html

See you there!
Jack
On Apr 26, 2005, at 6:49 PM, Shaun Jackman wrote:
I can definitely recommend Kirin Sushi, which is across the street
from the Skytrain station. There is also the Spaghetti Factory next
door. Not quite as convenient, but up the street is Hon's Won Ton
House and a tasty little Indian restaurant. I can meet for lunch any
day next week.
Cheers,
Shaun
On 4/26/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hey! Shaun Jackman generously offered to meet in New Westminister over
lunch to exchange gpg signatures
Meeting other debian/linux/open source folks would be totally awesome!
I can be in New West at lunch time every day next week - is anyone 
less
available?

Can someone recommend a convenient, easy-to-find location where we
(everyone interested!) can meet? I know New West only casually - but
someplace close to the Sky Train where the people can enjoy lunch 
would
probably be good : )

Best wishes!
Jack

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

Re: Ubuntu and its "appropriation" of Debian maintainers

[John Hasler]

Adam Majer writes:
> I just search Google for me and I found this,

> https://launchpad.ubuntu.com/people/adamm/

They have a similar page for me.  Nothing there indicates that I am not an
Ubuntu employee.

> Well, at least on pages like,

> http://packages.ubuntu.com/hoary/misc/mysql-query-browser

> They have "Adam Majer is responsible for this Debian package" with a
> link to Debian's QA.

For me they have:

"John Hasler is the maintainer of the following distribution packages:
Ubuntu Linux :: hoary :: pppconfig"

> Anyway, the bottom line is,
>1. I'm a Debian Developer and chose to be associated with Debian
>2. I have not chosen or gave permission to be associated with
> modified/unmodified packages of other distributions (that may or may not
> derive from Debian).

> What do other DDs think about this problem (or is it even a problem?)?
> Personally, I believe Ubuntu must either change the Maintainer field of
> all packages such that it points to Ubuntu Developers *or* get
> permission to keep the Maintainer field as is from the Debian package
> maintainer.

I mostly agree with you.  I don't mind at all if they want to identify me
as the upstream _Debian_ maintainer (or author in some cases) of my
packages, but if I'm an Ubuntu maintainer where is my paycheck?
-- 
John Hasler


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

Re: transcode

[Raphaël 'SurcouF' Bordet]

Le samedi 30 avril 2005 Ã 20:22 -0300, Frederico Rodrigues Abraham a
Ãcrit :
> having problems installing trancode on debian testing
> -- Fred
> 
> ike:~# apt-get install transcode

transcode isn't an official debian package.
I guess you have marillat's apt repository in
your /etc/apt/sources.list. Send him an email.

Regards,

-- 
RaphaÃl 'SurcouF' Bordet
http://debianfr.net/ | surcouf at debianfr dot net

Re: python-mysqldb in sarge and python2.2 support (for zope-mysqlda)

[Steve Langasek]

Hi Jonas,

On Fri, Apr 29, 2005 at 04:51:17PM +0200, Jonas Meurer wrote:
> i've a problem with packaging python-mysqldb. version 1.2 is already
> uploaded to unstable, and has no bugs while version 1.1.6
> - currently in testing - has a rc bug: #306906

> on the other side python-mysqldb 1.2 lacks python2.2 support, and
> thus no python2.2-mysqldb package exists any longer.
> the problem with that is, that zope-mysqlda depends on python2.2-mysqldb,
> and really requires it, as zope (2.6) doesn't run with python != 2.2.

> the only possibilities i see are
> 1. remove zope-mysqlda from the archive and push python-mysqldb 1.2
>[without python2.2 support] into sarge, but i don't like that idea
>too much.
>for this solution i've already prepared zope2.7-mysqlda packages that
>use python2.3-mysqldb to provide at least a mysql db adapter for
>zope2.7 even if none will be included for zope2.6.

> 2. backport the fixes for bug#306906 from 1.2 to 1.1.6 and prepare a
>sarge release with python2.2. i do like this idea but up to now i
>couldn't find out which one is the corresponding code change in
>python-mysqldb to fix #306906.

Release-wise, whichever of these options that you believe is most
appropriate would be acceptable.

Thanks,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: SE Linux in Etch - was Release sarge now, or discuss etch issues?

[Manoj Srivastava]

On Wed, 20 Apr 2005 10:13:54 +1000, Russell Coker <[EMAIL PROTECTED]> said: 

> On Tuesday 15 March 2005 09:32, Joey Hess <[EMAIL PROTECTED]> wrote:
>> The fact that the release team now sees the light at the end of the
>> tunnel for the release of sarge means that now is the time we need
>> to begin planning for etch. Allowing unstable development to pick
>> back up after a release with no clear plan for the next release has
>> been shown time and time again to delay the next release by one to
>> two *years*.  The rest follows from that.

> Currently we plan to have libselinux in base for Etch.  SE Linux
> code is in cron and logrotate which can be simply recompiled for
> full SE support.  Fcron already is compiled with SE Linux support.
> The maintainer of sysvinit has agreed in concept to compile with SE
> support once libselinux is in base.

> We can basically make SE Linux usable by most people with a small
> amount of work once the above changes are made.

> I would like to see a general goal for Etch to have SE Linux as an
> option at install time.  

In pursuance of that goal, I have made available a patched
 branch of dpkg-devel which has support for SELinux. Please pull from  
 [EMAIL PROTECTED]/dpkg--selinux--1.13
  (http://arch.debian.org/arch/private/srivasta/archive-2005-selinux)

This branch should have a small, very non-intrusive patch that
 does not have a performance hit on a non-SELinux system. It does add
 a dependency on libselinux1 for dpkg.

Please see
 http://www.golden-gryphon.com/software/security/selinux.xhtml
  for details.

You may browse the repository at
 http://www.golden-gryphon.com/cgi-bin/archzoom.cgi/[EMAIL PROTECTED]/?expand

If you want to try out this selinux aware dpkg, as well as
 Greg T. Norris' selinux patched coreutils  package, please point apt
 at: 

 deb http://people.debian.org/~srivasta/ packages/
 deb-src http://people.debian.org/~srivasta/ packages/source/

manoj

Repository links

dpkg--stable
The stable upstream DPKG branch, meant for Sarge. 
dpkg--devel
The upstream development branch for dpkg. This is meant for Etch
-- and since Etch can promote libselinux1 to an essential
priority, this branch of dpkg could be linked against libselinux1.  
dpkg--selinux-old
Russell Coker's modifications to dpkg, which introduce
{pre,post}{inst,rm}.d/ directories to label installed package
files correctly, using setfiles. Unfortunately, these changes were
deemed too far reaching, and really suboptimal, by dpkg authors,
since they were not comfortable introducing the general purpose
hook directories, which could lead to non-deterministic behaviour,
and could be open to all kinds of abuse.  
dpkg--selinux
A new modification of dpkg, using SELinux library calls
(matchpathcon and {l,f}setfilecon) to set the security context of
component files just after unpacking. This approach may be more
acceptable, since it does not create a whole set of directories
that are open to potential abuse, and fits in with the chown/chmod
calls that dpkg already makes. 


-- 
What is food to one, is to others bitter poison. Titus Lucretius Carus
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]