Work-needing packages report for Jan 5, 2007

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 329 (new: 2)
Total number of packages offered up for adoption: 80 (new: 0)
Total number of packages requested help for: 38 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   apt-spy (#405297), orphaned 2 days ago
 Description: writes a sources.list file based on bandwidth tests
 Installations reported by Popcon: 884

   mkrboot (#405527), orphaned today
 Description: Make a kernel + root image bootable from one disk or
   from DOS
 Installations reported by Popcon: 156

327 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 80 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   aboot (#315592), requested 560 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot aboot-cross dfsbuild ltsp-client
 Installations reported by Popcon: 52

   apt-build (#365427), requested 250 days ago
 Description: Need new developer(s)
 Installations reported by Popcon: 512

   apt-cacher (#403584), requested 17 days ago
 Description: caching proxy system for Debian package and source
   files
 Installations reported by Popcon: 229

   apt-show-versions (#382026), requested 149 days ago
 Description: lists available package versions with distribution
 Installations reported by Popcon: 2067

   athcool (#278442), requested 800 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 230

   audacity (#397166), requested 60 days ago
 Description: looking for co-maintainer
 Installations reported by Popcon: 2285

   cdw (#398252), requested 53 days ago
 Description: Tool for burning CD's - console version
 Reverse Depends: cdw gcdw
 Installations reported by Popcon: 253

   cvs (#354176), requested 315 days ago
 Description: Concurrent Versions System
 Reverse Depends: bonsai crossvc cvs-autoreleasedeb cvs-buildpackage
   cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta (16
   more omitted)
 Installations reported by Popcon: 9959

   docbook (#358522), requested 288 days ago
 Description: standard SGML representation system for technical
   documents
 Reverse Depends: alcovebook-sgml docbook-dsssl docbook-to-man
   sgmltools-lite
 Installations reported by Popcon: 3567

   docbook-xml (#358520), requested 288 days ago
 Description: standard XML documentation system, for software and
   systems
 Reverse Depends: dblatex docbook-dsssl docbook-ebnf
   docbook-html-forms docbook-jrefentry docbook-mathml docbook-simple
   docbook-slides docbook-website docbook-xsl-stylesheets-ko (6 more
   omitted)
 Installations reported by Popcon: 15232

   dpkg (#282283), requested 775 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source apt-build apt-cross apt-src
   backuppc build-essential clamsmtp crosshurd cvs-autoreleasedeb (83
   more omitted)
 Installations reported by Popcon: 23548

   grub (#248397), requested 969 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: dfsbuild grub-splashimages replicator
 Installations reported by Popcon: 19894

   gtkpod (#319711), requested 529 days ago
 Description: manage songs and playlists on an Apple iPod
 Installations reported by Popcon: 462

   ispell-et (#391105), requested 92 days ago
 Description: Estonian dictionary for Aspell/Ispell/MySpell
 Installations reported by Popcon: 16

   lighttpd (#401575), requested 31 days ago
 Description: A fast webserver with minimal memory footprint
 Reverse Depends: lighttpd-mod-cml lighttpd-mod-magnet
   lighttpd-mod-mysql-vhost lighttpd-mod-trigger-b4-dl
   lighttpd-mod-webdav
 Installations reported by Popcon: 322

   loop-aes-modules (#385615), requested 126 days ago
 Description: loop-AES modules
 Reverse Depends: loop-aes-2.6-486 loop-aes-2.6-686
   loop-aes-2.6-686-bigmem loop-aes-2.6-alpha-generic
   loop-aes-2.6-alpha-legacy loop-aes-2.6-alpha-smp loop-aes-2.6-amd64
   loop-aes-2.6-footbridge loop-aes-2.6-iop32x loop-aes-2.6-itanium (24
   more omitted)
 Installations reported by Popcon: 38

   loop-aes-utils (#385614), re

Re: RFC: Proposal for official screenshot repo

[Hubert Chan]

Roberto C. Sanchez wrote:
> On Thu, Jan 04, 2007 at 05:41:35PM +0100, Javier Fernández-Sanguino Peña 
> wrote:
>> - Provide an HTML interface to the pool

>> If the packages names are the same I don't see the need to add yet another
>> line to the debian/control file, packages.debian.org would just need to point
>> to http://screenshots.debian.org/ and that's it.

> Good idea.  I'd not though about it that way.  We would then only need a
> default place holder for packages without screenshots.

Another thing you may want to consider is to allow for redirects.
e.g. if someone is looking for screenshots for, say, mozilla, then you
can tell them to go to the iceape page instead.

-- 
Hubert Chan <[EMAIL PROTECTED]> -- Jabber: [EMAIL PROTECTED]
PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA

Re: Troubleshooting using Debian developer machines

[Steve Langasek]

On Thu, Jan 04, 2007 at 06:28:41PM -0800, Russ Allbery wrote:
> Shaun Jackman <[EMAIL PROTECTED]> writes:

> > Monotone has a bug (#404616) that seems to only affect powerpc. I don't
> > have access to a powerpc machine myself, so I'd like to use
> > bruckner.debian.org to troubleshoot the bug. How do I use the Etch
> > chroot on bruckner to install monotone and its dependencies and run
> > monotone without root access to bruckner?

> Speaking of bruckner, my ssh public key doesn't seem to work on that
> system (but works fine on other hosts such as gluck and alioth).  I've
> been meaning to try to track down the gtimer bug that's powerpc-specific
> and ran into that.

> Am I missing something obvious, or should I mail debian-admin about that
> as well?  I don't want to bother them if it's something I can fix myself.

authorized_keys are supposed to propagate via LDAP.  If you have your public
key loaded into LDAP, and you can't get to bruckner, you'll want to contact
debian-admin since AFAICS the host isn't locked down right now.

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/


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

Bug#405628: RFP: cone -- COnsole Newsreader and Emailer (a GPL'ed pine clone)

[Axel Beckert]

Package: wnpp
Severity: wishlist

* Package name: cone
  Version : 0.69
  Upstream Author : Mr. Sam <[EMAIL PROTECTED]>
* URL or Web page : http://www.courier-mta.org/cone/
* License : GPL
  Description : COnsole Newsreader and Emailer (a GPL'ed pine clone)

According to http://www.linux.com/article.pl?sid=06/11/28/1519247 cone
is modeled after the well-known but not-so-free MUA pine and therefore
could fit into Debian as a GPL'ed pine replacement. According to its
web page it shares a lot of libraries with the Courier MTA and is
written by the same people. It's pico-clone is named leaf (Lightweight
Editor of Ascii Files).

Beyond others cone has support for PGP, GPG, UTF-8, IMAP, POP3,
incoming HTML mails, external viewers, NNTP, SOCKS 5, SSL/TLS, SASL,
LDAP and IMAP based address books, remote storable configuration,
multiple accounts (can't remember having seen that in pine), tagging
mails with several different flags, and SMAP (Simple Mail Access
Protocol, a new IMAP and POP3 replacement developed by the Courier
guys and supported by the Courier developement versions).

Cone compiles smoothly on Sarge with just "sh configure && make". It
looks like pine with some of the known enhancement patches (e.g. it's
more colorful, but still not too colorful :-) and works quite
intuitively, IMHO even more than pine does. The only thing missing on
a first glance is the capability of mutt or pine to connect to an IMAP
server by tunneling IMAP over SSH. :-)

I really wonder why it isn't in Debian yet, since the Courier MTA
seems to be well-elaborated in Debian (at least according to the
number of packages it has been split into ;-).

Kind regards, Axel
-- 
/~\| Axel Beckert
\ /  Plain Text Ribbon Campaign| [EMAIL PROTECTED]
 X   Say No to HTML in E-Mail and News | [EMAIL PROTECTED]
/ \| http://abe.home.pages.de/


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

Re: Troubleshooting using Debian developer machines

[Russ Allbery]

Shaun Jackman <[EMAIL PROTECTED]> writes:

> Monotone has a bug (#404616) that seems to only affect powerpc. I don't
> have access to a powerpc machine myself, so I'd like to use
> bruckner.debian.org to troubleshoot the bug. How do I use the Etch
> chroot on bruckner to install monotone and its dependencies and run
> monotone without root access to bruckner?

Speaking of bruckner, my ssh public key doesn't seem to work on that
system (but works fine on other hosts such as gluck and alioth).  I've
been meaning to try to track down the gtimer bug that's powerpc-specific
and ran into that.

Am I missing something obvious, or should I mail debian-admin about that
as well?  I don't want to bother them if it's something I can fix myself.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: RC bugs with (seemingly) simple fixes

[Russ Allbery]

Lars Wirzenius <[EMAIL PROTECTED]> writes:

> Likewise, #379113 has a patch and should be simple enough for someone
> with a 64-bit system to test and upload.

I'm home with my 64-bit system, so I'll get this one.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Bug#405625: ITP: omfs-source -- Optimized MPEG Filesystem (OMFS) Linux kernel driver [source]

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias <[EMAIL PROTECTED]>

* Package name: omfs-source
  Version : 0.7.2
  Upstream Author : Bob Copeland <[EMAIL PROTECTED]>
* URL : http://linux-karma.sf.net/rio-usb.html
* License : GPL2
  Programming Lang: C
  Description : Optimized MPEG Filesystem (OMFS) Linux kernel driver 
[source]

OMFS is a module for the Linux 2.6 kernel.  It is used by MythTV and
the Rio Karma digital audio player.


-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.4.27-2um
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


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

Re: etch's upgrades during life cycle

[Matthias Julius]

Luis Matos <[EMAIL PROTECTED]> writes:

>> 
>> There could be another archive called updates.debian.org where
>> selected packages go in in coordination with the security and stable
>> release teams.
> that would be nicier ... but that's a bit of volatile's purpose.
> Although it is not very used.

You are right.  It does sound a lot like volatile.  I didn't know much
abaut it up to now.  Maybe all that needs to be done is to make it
more official, have it supported by the security team and put a
commented out line for it into sources.list.

Matthias


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

Re: FSG Packaging Summit in Berlin

[Joey Hess]

Jonathan Corbet wrote:
>   Debian will get the Etch release out this year. Honest. What
>   could possibly go wrong? Thereafter, the Debian developers will
>   go back to arguing about firmware in the kernel.
> 
> Honestly, it was not my intent to insult anybody.  I'm sorry if I did.
> But, being the socially-challenged person I am, I still don't understand
> how that could be.

As I read it, there's an implication that all I, as a DD, am good for is
failing to get Debian releases out and spending all my time in pointless
discussion. I don't really feel that accurately describes me.

-- 
see shy jo, hmm


signature.asc
Description: Digital signature

Re: etch's upgrades during life cycle

[Luis Matos]

Sex, 2007-01-05 às 00:57 +0100, Daniel Baumann escreveu:
> Luis Matos wrote:
> > backports use testing as base for the packages.
> > setting up security for backports is a bit easier than for testing. Lot
> > less packages.
> > My point is, for example, when the security team lauches a DSA, it
> > always sees if both unstable and testing are afected. They already
> > monitor testing and unstable too ... it's just a question of applying
> > patches. (maybe a apt-patch package. in which he rebuilds the package
> > with the selected patch).
> > 
> > The same would do for backports, security team would patch the package
> > and send it to the buildd.
> > 
> > I know ... it's more and more work for the security team ...
> 
> thinking aloud: hypothetically assumed that (parts of) backports.org
> would get official, i could do security support for it as i do it atm
> for about half of the packages on backports.org anyway.

That was a good idea (if backports integrate debian).

The security team already monitors testing and unstable ... do, it is
only needed for someone to patch the packages.

I am not a DD ... But this could be a good step to bring backports.org
into debian for etch.

> 
> -- 
> Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
> Email:  [EMAIL PROTECTED]
> Internet:   http://people.panthera-systems.net/~daniel-baumann/
> 
> 


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

Problem with debsums and linux-modules-* packages

[Jacques Normand]

hi,

I am not sure what to do about that. The module packages carry a md5sum
for the map and dep files which are updated by depmod so when you run
debsums you get a serie of mismatch. This is a problem with tools like
bcfg2 since it triggers a reinstallation of the said package at each
run. (bcfg2 is also distributed with debian)

Now, the question is whether it should be a bug against debsums, the
linux-modules-* or more probably kernel-package. 

I am ready for your advises

jacques


signature.asc
Description: Digital signature

Re: etch's upgrades during life cycle

[Daniel Baumann]

Luis Matos wrote:
> backports use testing as base for the packages.
> setting up security for backports is a bit easier than for testing. Lot
> less packages.
> My point is, for example, when the security team lauches a DSA, it
> always sees if both unstable and testing are afected. They already
> monitor testing and unstable too ... it's just a question of applying
> patches. (maybe a apt-patch package. in which he rebuilds the package
> with the selected patch).
> 
> The same would do for backports, security team would patch the package
> and send it to the buildd.
> 
> I know ... it's more and more work for the security team ...

thinking aloud: hypothetically assumed that (parts of) backports.org
would get official, i could do security support for it as i do it atm
for about half of the packages on backports.org anyway.

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/


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

Re: FSG Packaging Summit in Berlin

[Jonathan Corbet]

Joey Hess <[EMAIL PROTECTED]> wrote:

> I'm boycotting feeding any useful information to LWN anymore until they
> retract their latest blanket insult of all DD's and stop being so biased.

Interesting.  It's usually the Fedora folks who complain about bias at
LWN.  

Honestly, I don't see what the problem is here.  The text in question is
(presumably): 

Debian will get the Etch release out this year. Honest. What
could possibly go wrong? Thereafter, the Debian developers will
go back to arguing about firmware in the kernel.

So where is the insult?  Certainly it wouldn't be "what could possibly
go wrong?"  I don't think I am the only one to notice that Debian
releases do not always happen when people think they might.  Remember
that I had previously predicted that the 2006 release date would hold.

As for the firmware comment: correct me if I'm wrong, but I do believe
that the project, via general resolution, punted the firmware issue
until after the release of Etch.  Of course it's going to come back, it
comes back every release cycle.  Is it an insult to say that?

Honestly, it was not my intent to insult anybody.  I'm sorry if I did.
But, being the socially-challenged person I am, I still don't understand
how that could be.

jon

Jonathan Corbet / LWN.net / [EMAIL PROTECTED]


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

RC bugs with (seemingly) simple fixes

[Lars Wirzenius]

On to, 2007-01-04 at 17:54 +, Lars Wirzenius wrote:
> It's too long since I've done anything for Debian. I'm going to be
> picking an RC bug tonight and damn well get it fixed.

The bug turned out to be #392940 (a build problem in kdissert). I also
closed #403356 since the submitter found out that it was due to
filesystem trouble. 

If I wasn't so nervous about building shared libraries, #404723 would
have a patch that looks correct and simple to me, so someone who
understands shared libraries should have a go at it. 

Likewise, #379113 has a patch and should be simple enough for someone
with a 64-bit system to test and upload.

Similarly, #389317 seems to have a simple patch to fix the problem, but
it's outside my comfort zone.

Continuing the theme, #404304 has a patch that seems simple enough.
Assuming the information in the bug report is correct, it should be easy
to test and upload a fixed package.

Anyone else up to fixing at least one of those?

-- 
Every time I say /quit I die a little.


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

Re: RFC: Proposal for official screenshot repo

[Luis Matos]

Qui, 2007-01-04 às 16:49 -0500, Roberto C. Sanchez escreveu:
> - Requiring a new package upload just for screenshots (If we want to
>   allow user contributed screenshots, the updates to the screenshots
>   really need to be able to happen independently of the package
> uploads. 

I think the "screenshot only" package is a good option. The packages can
be generated automatically from somewhere and uploaded to debian and
target the same version as the package.

The could be an web interface to help DD's to upload a gallery of images
and select the ones to that version (for example changing package
foo-0.3 to 0.3.1 will not change it's look, so, the DD goes to the web
interface and ask to rebuild the package for the new version).

i also think that user uploaded screenshots can be possible, but i
desagree ... or ... their upload is accepted, but, the DD has to select
the screenshot from the web interface's screenshot list.

Then, from the mirror, with the application like synaptic, it can
download the screenshot package with several screenshots and see. Always
DD controled.


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

Re: etch's upgrades during life cycle

[Luis Matos]

Qui, 2007-01-04 às 16:43 -0500, Matthias Julius escreveu:
> Luis Matos <[EMAIL PROTECTED]> writes:
> 
> > Qui, 2007-01-04 às 11:10 +, Dominic Hargreaves escreveu:
> >> 
> >> backports.org is, to my mind, a perfect solution to this problem; it
> >> allows you to selectively upgrade your favourite/important packages that
> >> you need, whilst retaining the stable base on which to run them.
> >> 
> >
> > here i agree that backports.org is the way out and that should be
> > official so maintainers could upload backports in a easier and have a
> > better security support. (and gives users other view for it if
> > backports.org is indeed in debian and recommended by debian.)
> 
> Maybe backports.org is too much and changing to frequently to provide
> security support for and to be really stable.

backports use testing as base for the packages.
setting up security for backports is a bit easier than for testing. Lot
less packages.
My point is, for example, when the security team lauches a DSA, it
always sees if both unstable and testing are afected. They already
monitor testing and unstable too ... it's just a question of applying
patches. (maybe a apt-patch package. in which he rebuilds the package
with the selected patch).

The same would do for backports, security team would patch the package
and send it to the buildd.

I know ... it's more and more work for the security team ...

> 
> There could be another archive called updates.debian.org where
> selected packages go in in coordination with the security and stable
> release teams.
that would be nicier ... but that's a bit of volatile's purpose.
Although it is not very used.

at a certain point several packages could be updated, because mainstream
releases an important release. Like mysql-5.0, or ooo 2.0 ... and they
could be addressed to backports or volatile or updates (volatile, for
me, means critical updates for debian stable ... because stable must
remain ... stable).

We definitly need something to make debian stable move while it is
stable.

Someone talked about the release cycles ... i think debian should not
move to less than one year ... we already have ubuntu and see what is
going there with the 6 months. The main problem for the year release is
desktop, because linux has suffered lots of evolution in this field in
so little time. Companies that deploy linux on desktop seem to seek for
updating contantly the desktop (or others let them to rott).

I think what debian needs is a lift in the desktop part, and the desktop
team is moving. (the desktop team needs designers or people in the
design area) 

I always compared debian stable with RHEL. They both target the same, i
think.

> 
> Matthias
> 


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

Re: RFC: Proposal for official screenshot repo

[Roberto C. Sanchez]

On Thu, Jan 04, 2007 at 08:46:40PM +, Luis Matos wrote:
> Maybe in the /debian package, there could be a package.png that is the 
> screenshot and make them available in the mirrors (pool).
> maybe creating a file such as Packages.gz or an extension to it, 
> informing that it has the screenshot available.
> 
This presents a few problems that I can see:

- Bloat of package source or .diff.gz which would also require monkeying
  around with things like uuencode/uudecode (trust me, I've had to ship
  images in the debian/ directory before).
- How would we handle miltuple screenshots?
- Requiring a new package upload just for screenshots (If we want to
  allow user contributed screenshots, the updates to the screenshots
  really need to be able to happen independently of the package uploads.
- Someone else aready suggested a way which not require any changes to
  the control file format (which would probably be necessary under your
  suggestion).

> then the user could access the pool ... or ... use some kind of client 
> that uses the apt-get database to search for screenshots.
> 
I am guessing that due to the nature of screenshots, the most likely
access method will be through some sort of package browser, like
aptitude or synaptic.  I'm not saying that others are not possible, just
that I think that those are the most likely.

> For example, a simple gtk window with a combo box with the packages' 
> names who has screenshots, and the user could:
> 1 - select the package
>  1.1 - application downloads it
> 2 - view in the application window
> 3 - full screen ( maybe using eog?)
> 
Does there exist a debian alternative for image-viewer or something
similar?  That would allow the user to use eog, kview or whatever other
image viewing application they prefer.

> i think it is simple.
> 
> Although ... the package will see it's source size increased and... 1 MB 
> for 10% of debian's packages is +/- 2 Gb more of disk space in the mirrors.
> 
Yes.  That is a concern, but I think that it is an excellent usability
aid.  I've installed lots of programs only to run them and see how ugly
or unintuitive the UI looked to only immediately purge them.  A few
screenshots would have helped me make up my mind.

> The screenshots can also use a similar process but use a package of 
> their own.
> 
> With the same process described, a package_0.3-1.dscr will have a bunch 
> of screenshots of package.
> 
I'm not sure this is a great idea.

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: etch's upgrades during life cycle

[Matthias Julius]

Luis Matos <[EMAIL PROTECTED]> writes:

> Qui, 2007-01-04 às 11:10 +, Dominic Hargreaves escreveu:
>> 
>> backports.org is, to my mind, a perfect solution to this problem; it
>> allows you to selectively upgrade your favourite/important packages that
>> you need, whilst retaining the stable base on which to run them.
>> 
>
> here i agree that backports.org is the way out and that should be
> official so maintainers could upload backports in a easier and have a
> better security support. (and gives users other view for it if
> backports.org is indeed in debian and recommended by debian.)

Maybe backports.org is too much and changing to frequently to provide
security support for and to be really stable.

There could be another archive called updates.debian.org where
selected packages go in in coordination with the security and stable
release teams.

Matthias

Re: Troubleshooting using Debian developer machines

[Arjan Oosting]

Op do, 04-01-2007 te 13:51 -0700, schreef Shaun Jackman:
> Monotone has a bug (#404616) that seems to only affect powerpc. I
> don't have access to a powerpc machine myself, so I'd like to use
> bruckner.debian.org to troubleshoot the bug. How do I use the Etch
> chroot on bruckner to install monotone and its dependencies and run
> monotone without root access to bruckner?

mail to [EMAIL PROTECTED] and wait until something has
happened.

Greetings Arjan


signature.asc
Description: Dit berichtdeel is digitaal ondertekend

Re: Troubleshooting using Debian developer machines

[Roger Leigh]

"Shaun Jackman" <[EMAIL PROTECTED]> writes:

> Monotone has a bug (#404616) that seems to only affect powerpc. I
> don't have access to a powerpc machine myself, so I'd like to use
> bruckner.debian.org to troubleshoot the bug. How do I use the Etch
> chroot on bruckner to install monotone and its dependencies and run
> monotone without root access to bruckner?

Send an email to debian-admin, and ask for it to be installed in the
chroot?

On the unlikely chance that doesn't work out, mail me your SSH public
key in a signed and encrypted mail, and I'll create you an account on
my powerpc system (but you'll need IPv6 connectivity to ssh in).


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


pgpT9JpcBqWc6.pgp
Description: PGP signature

Re: Troubleshooting using Debian developer machines

[Steve Langasek]

On Thu, Jan 04, 2007 at 01:51:25PM -0700, Shaun Jackman wrote:
> Monotone has a bug (#404616) that seems to only affect powerpc. I
> don't have access to a powerpc machine myself, so I'd like to use
> bruckner.debian.org to troubleshoot the bug. How do I use the Etch
> chroot on bruckner to install monotone and its dependencies and run
> monotone without root access to bruckner?

Email debian-admin requesting installation of monotone in the chroot.

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


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

Re: etch's upgrades during life cycle

[Luis Matos]

Qui, 2007-01-04 às 11:10 +, Dominic Hargreaves escreveu:
> On Thu, Jan 04, 2007 at 11:00:16AM +, Paul Waring wrote:
> 
> > I think the problem that many people find with Debian is that they do 
> > want the stability and security of stable, but at the same time they 
> > don't want to be a dozen releases behind upstream. I've seen many 
> > occasions where there's been a new release with useful features that has 
> > been available in upstream for months and it's still not in Debian 
> > stable, even though it is available in the package repositories of other 
> > Linux distributions. It's not so much a case of wanting to be on the 
> > bleeding edge for most people, but more that we don't want to still be 
> > powering our machines with crank handles when everyone else has moved on 
> > to electricity.
> 
> backports.org is, to my mind, a perfect solution to this problem; it
> allows you to selectively upgrade your favourite/important packages that
> you need, whilst retaining the stable base on which to run them.
> 

here i agree that backports.org is the way out and that should be
official so maintainers could upload backports in a easier and have a
better security support. (and gives users other view for it if
backports.org is indeed in debian and recommended by debian.)

> One proviso I would add to that is that it's only good so long as it
> doesn't move too much focus away from Debian's own stable releases. I
> can't see any evidence of that at present. It's also possibly the case
> that backports.org could/should made more official or at least offically
> recommended by Debian, although I understand why this isn't necessarily
> the case right now.
> 
> However, the original question was about hardware support, which is a
> rather special case. I've spent many frustrated hours getting Debian
> stable onto modern hardware using various tricks and hacks, and I'm sure
> anyone running Debian extensively in production has had similar
> experiences. This is one area where an official updated installer and
> kernel would greatly improve life, and I'm very interested by Moritz's
> comment that this is planned for etch.

oh yeah ... in the woody time, i was save by a d-i rc1, installing new
hp proliants.


> 
> Cheers,
> 
> Dominic.
> 
> -- 
> Dominic Hargreaves | http://www.larted.org.uk/~dom/
> PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
> 
> 


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

Troubleshooting using Debian developer machines

[Shaun Jackman]

Monotone has a bug (#404616) that seems to only affect powerpc. I
don't have access to a powerpc machine myself, so I'd like to use
bruckner.debian.org to troubleshoot the bug. How do I use the Etch
chroot on bruckner to install monotone and its dependencies and run
monotone without root access to bruckner?

Thanks,
Shaun


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

Re: RFC: Proposal for official screenshot repo

[Luis Matos]

Maybe in the /debian package, there could be a package.png that is the 
screenshot and make them available in the mirrors (pool).
maybe creating a file such as Packages.gz or an extension to it, 
informing that it has the screenshot available.


then the user could access the pool ... or ... use some kind of client 
that uses the apt-get database to search for screenshots.


For example, a simple gtk window with a combo box with the packages' 
names who has screenshots, and the user could:

1 - select the package
 1.1 - application downloads it
2 - view in the application window
3 - full screen ( maybe using eog?)

i think it is simple.

Although ... the package will see it's source size increased and... 1 MB 
for 10% of debian's packages is +/- 2 Gb more of disk space in the mirrors.


The screenshots can also use a similar process but use a package of 
their own.


With the same process described, a package_0.3-1.dscr will have a bunch 
of screenshots of package.


This package can be downloaded and untared for view, in the user's 
application.



What do you think?

Got lost??

Javier Fernández-Sanguino Peña wrote:

On Thu, Jan 04, 2007 at 12:05:03AM +0100, Nico Golde wrote:
  

Hi,


  this idea has been discussed recently, I just can't remember when
exactly though, I'd say in the late 6 monthes. Maybe you can grab some
names of people that were involved in the first proposal there. It may
have been proposed on -project rather than devel. But I suppose google
will know about it.
  

Maybe the following?
http://lists.debian.org/debian-devel/2006/04/msg00915.html



It's not exactly the same idea. The proposer (Gonéri Le Bouder [0]) focused
on what the layout and distribution of images [1] should be, but not on:

- who provides the screenshots? how are they uploaded and validated? (is
  there an upload queue who manages all this automatically?)

- is there a web interface to that information or it will just be used by
  package managers?

The Alioth project was named 'apt-pixmap' [1] there has been no activity
in its mailing list [2] and the original location of the "proof of concept"
[3] does not exist any longer. So I guess the project did not spark enough
attention.

Some of the information in the project as well as the threads can be used to
draft a new proposal, however.

I think that something similar to backports.org (a service where both DDs and
non-DDs could upload screenshots to) and provided a web interface to view
screenshots by package version would be really cool.

Regards


Javier

[0] Who, BTS is now the proud father of a little girl:
http://orniere-du-globe.net/blog/?p=312 :-)

[1] Based on Debian packages or TAR files so the user could download *all*
the screenshots using a specific tool. Which, BTW, I don't think is a good
idea.

[2] http://alioth.debian.org/projects/apt-pixmap/

[3] http://lists.alioth.debian.org/mailman/listinfo/apt-pixmap-repo

[4] http://gloria.rulezlan.org/debian2/
  



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

Bug#405590: ITP: libtext-vcard-perl -- parse, edit and create multiple vCards

[Neil Williams]

Package: wnpp
Severity: wishlist
Owner: Neil Williams <[EMAIL PROTECTED]>


* Package name: libtext-vcard-perl
  Version : 2.00
  Upstream Author : Leo Lapworth <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/Text-vCard
* License : GPL
  Programming Lang: Perl
  Description : parse, edit and create multiple vCards

 Text::vCard::Addressbook provides an API to reading / editing and
 creating multiple vCards. A vCard is an electronic business card.
 This package has been developed based on rfc2426.
 .
 Many applications (Apple Address book, MS Outlook, Evolution etc)
 can export and import vCards.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-powerpc
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)


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

Bug#405591: ITP: libtext-vfile-asdata-perl -- generic perl module to read and write vfile files

[Neil Williams]

Package: wnpp
Severity: wishlist
Owner: Neil Williams <[EMAIL PROTECTED]>


* Package name: libtext-vfile-asdata-perl
  Version : 0.0.5
  Upstream Author : Jay Lawrence <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/Text-vFile
* License : GPL
  Programming Lang: Perl
  Description : generic perl module to read and write vfile files

 Works with such as vCard (RFC 2426) and vCalendar (RFC 2445).
 The result of loading this data is a collection of objects which
 will grant you easy access to the properties. Then the module
 can write your objects back to a data file.

Used by libtext-vcard-perl which in turn is to be recommended by pilot-qof.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-powerpc
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)


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

Re: Marcelo Magallon (lib3ds maintainer) MIA?

[Martin Michlmayr]

* Martin Michlmayr <[EMAIL PROTECTED]> [2006-07-08 09:55]:
> * Miles Bader <[EMAIL PROTECTED]> [2006-07-08 10:33]:
> > Does anybody know if the lib3ds maintainer, Marcelo Magallon (email
> > mmagallo), is still active?
> 
> He has been busy with RL lately but things got better recently.
> Signing your messages to him with GPG helps him filter it out from all
> the spam he gets.
> 
> FWIW, he's usually receptive to offers of help/co-maintenance.

... although it seems he never responded to the GPG signed messages
I sent either and that was six months ago.

Marcelo, are you still around?
-- 
Martin Michlmayr
http://www.cyrius.com/


signature.asc
Description: Digital signature

Re: FSG Packaging Summit in Berlin

[Lars Wirzenius]

On to, 2007-01-04 at 15:23 +, Andrew Saunders wrote:
> On 1/4/07, Joey Hess <[EMAIL PROTECTED]> wrote:
> > I'm boycotting feeding any useful information to LWN anymore until they
> > retract their latest blanket insult of all DD's and stop being so biased.
> > YMMV.
> 
> Could you pretty please elaborate on this a little bit? It'd be most
> interesting to hear your views on LWN's Debian-related coverage in
> detail. Perhaps a blog post, should you consider it too off-topic for
> -devel?

Joey refers to this prediction for 2007, which is part of the LWN
editorial page predictions (there's a lot of them):

Debian will get the Etch release out this year. Honest. What
could possibly go wrong? Thereafter, the Debian developers will
go back to arguing about firmware in the kernel.
(http://lwn.net/Articles/215856/, subscriber only for a week or
two)

As contrast, their prediction for 2006 regarding Debian is rather
different in tone:

Debian 'etch' will be released in December, on schedule -- or,
at least, very close to it. The Debian developers are tired of
their reputation for unreliable release schedules and see an
opportunity to improve the situation.
(http://lwn.net/Articles/166074/, should be open to everyone)

I see the 2007 prediction more as a reaction to their wrong prediction
for 2006 than as a comment on Debian, but I can't say I feel good about
it anyway.

At this point, I think the best reaction we, the developers of Debian,
could have is to find some "sisu", and sit down and finish the work
required to get etch out.

"Sisu" is a Finnish word for a concept that does not have a direct
translation in English. The Wikipedia page has a good explanation,
however:

Sisu is a Finnish term that could be roughly translated into
English as strength of will, determination, perseverance, and
acting rationally in the face of adversity. [- - -] sisu has a
long-term element in it; it is not momentary courage, but the
ability to sustain the same.

[- - -]

Depending on context, "sisu" can refer to spunk, attitude,
self-confidence, and so on. However, sisu is not bravery, nor
strength, and needs to be distinguished from courage, especially
when talking about the military. In contrast, sisu is an ability
to finish the task and get things done, as defined by Roman
Schatz in his book From Finland with Love (2005) and
decisiveness. Usually sisu means will and decisiveness to get
the things done against impossible odds, or to succeed when
given the chinaman's chance.

(http://en.wikipedia.org/wiki/Sisu)

(That's not a quote of the entire page, I left out the non-essential
parts. You might want to read the whole page to get the full picture,
however. Sisu is not a uniquely Finnish concept, but the Finnish word is
the only one I know for it.)

When I say "we", I do mean all of us. Joey himself has done a huge
amount of work already, I do not mean to extract more out of him, but
I'm sure most people involved in Debian development could spend a few
more brain cycles.

It's too long since I've done anything for Debian. I'm going to be
picking an RC bug tonight and damn well get it fixed.

-- 
That which does not kill us makes us stranger


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

Bug#405576: ITP: python-mako -- template library written in Python

[Piotr Ozarowski]

Package: wnpp
Severity: wishlist
Owner: Piotr Ozarowski <[EMAIL PROTECTED]>

* Package name: python-mako
  Version : 0.1.0
  Upstream Author : Mike Bayer <[EMAIL PROTECTED]>
* URL : http://www.makotemplates.org
* License : MIT
  Programming Lang: Python
  Description : template library written in Python

Mako is a template library written in Python. It provides a familiar, non-XML
syntax which compiles into Python modules for maximum performance. Mako's
syntax and API borrows from the best ideas of many others, including Django
templates, Cheetah, Myghty, and Genshi. Conceptually, Mako is an embedded
Python (i.e. Python Server Page) language, which refines the familiar ideas of
componentized layout and inheritance to produce one of the most straightforward
and flexible models available, while also maintaining close ties to Python
calling and scoping semantics.

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.19
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)


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

Re: RFC: Proposal for official screenshot repo

[Roberto C. Sanchez]

On Thu, Jan 04, 2007 at 05:41:35PM +0100, Javier Fernández-Sanguino Peña wrote:
> On Wed, Jan 03, 2007 at 05:32:52PM -0500, Roberto C. Sanchez wrote:
> > I'd be interested in knowing:
> > 
> >  * Would such an idea be feasible?
> 
> Yes, it only requires somebody to code in the missing pieces (i.e. all of
> them)
> 
OK.  Give me a couple of days :-)

> >  * What would be a good way to get started? (*)
> 
> - Code in an upload queue implementing something akin to master (i.e. upload
> through anonymous ftp and put the screenshots in a pool, define a changes
> file format to describe which version is being screenshotted etc.)
> 
OK.  I'd appreciate some help with this, or some pointers, or anything.
This is probably the piece which I am least qualified to do.

> - Provide an HTML interface to the pool
> 
> If the packages names are the same I don't see the need to add yet another
> line to the debian/control file, packages.debian.org would just need to point
> to http://screenshots.debian.org/ and that's it.
> 
Good idea.  I'd not though about it that way.  We would then only need a
default place holder for packages without screenshots.

> > As far as getting started:
> > 
> >  * Would this need to start on debian.net?
> 
> Probably, until a proof of concept is working and an official domain is
> provided.
> 
OK.  Once I get something a little more concrete up and running, I'll
see about getting a DNS entry in the debian.net zone file.

> >  * What would be the requirements/limitations/guidelines?
> 
> Do you mean server requirements? I guess that it's disk and bandwidth. 
> As for limitations, if you are restricting this to DD uploads there is a
> severe limitation (i.e. users cannot 'contribute' screenshots)
> 
What about my suggestion for user contributed screenshots via bug
reports?  The BTS accepts attachments to emails, so I think that would
work.

> > I would really appreciate any comments and suggestions on this.
> 
> I say that is a good idea, but I'm not sure how screenshots.debian.org would
> help your friend. If you are talking about one-five screenshot per package
> (or per package version) that is hardly sufficient to explain how a package
> manager works. Better yet if someone wrote a package management document
> using DocBook and including screenshots and that was published in the
> website.
> 
Here is how it would help.  He wants an email client and so he searches
for one.  The list includes icedove, sylpheed, mutt, kmail, evolution
and others.  They all have descriptions, but he can't visualize what
they look like, especially not being familiar with them.  Having
screenshots available makes it so that he can compare them, at least
based on how they look.

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

RE: RFC: Proposal for official screenshot repo

[Miriam Ruiz]

--- "Roberto C. Sanchez" <[EMAIL PROTECTED]> escribió:

> I would really appreciate any comments and suggestions on this.

We discussed that idea in the Debian Games Team some time ago, and we're very
interested in it. At least for games, having screenshots is something very
important.

Greetings,
Miry

__
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis! 
Regístrate ya - http://correo.yahoo.es 


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

Re: RFC: Proposal for official screenshot repo

[Javier Fernández-Sanguino Peña]

On Thu, Jan 04, 2007 at 12:05:03AM +0100, Nico Golde wrote:
> Hi,
> >   this idea has been discussed recently, I just can't remember when
> > exactly though, I'd say in the late 6 monthes. Maybe you can grab some
> > names of people that were involved in the first proposal there. It may
> > have been proposed on -project rather than devel. But I suppose google
> > will know about it.
> 
> Maybe the following?
> http://lists.debian.org/debian-devel/2006/04/msg00915.html

It's not exactly the same idea. The proposer (Gonéri Le Bouder [0]) focused
on what the layout and distribution of images [1] should be, but not on:

- who provides the screenshots? how are they uploaded and validated? (is
  there an upload queue who manages all this automatically?)

- is there a web interface to that information or it will just be used by
  package managers?

The Alioth project was named 'apt-pixmap' [1] there has been no activity
in its mailing list [2] and the original location of the "proof of concept"
[3] does not exist any longer. So I guess the project did not spark enough
attention.

Some of the information in the project as well as the threads can be used to
draft a new proposal, however.

I think that something similar to backports.org (a service where both DDs and
non-DDs could upload screenshots to) and provided a web interface to view
screenshots by package version would be really cool.

Regards


Javier

[0] Who, BTS is now the proud father of a little girl:
http://orniere-du-globe.net/blog/?p=312 :-)

[1] Based on Debian packages or TAR files so the user could download *all*
the screenshots using a specific tool. Which, BTW, I don't think is a good
idea.

[2] http://alioth.debian.org/projects/apt-pixmap/

[3] http://lists.alioth.debian.org/mailman/listinfo/apt-pixmap-repo

[4] http://gloria.rulezlan.org/debian2/


signature.asc
Description: Digital signature

Re: RFC: Proposal for official screenshot repo

[Javier Fernández-Sanguino Peña]

On Wed, Jan 03, 2007 at 05:32:52PM -0500, Roberto C. Sanchez wrote:
> I'd be interested in knowing:
> 
>  * Would such an idea be feasible?

Yes, it only requires somebody to code in the missing pieces (i.e. all of
them)

>  * Would maintainers be willing to occasionally upload screenshots?

I would.

>  * What would be a good way to get started? (*)

- Code in an upload queue implementing something akin to master (i.e. upload
through anonymous ftp and put the screenshots in a pool, define a changes
file format to describe which version is being screenshotted etc.)

- Provide an HTML interface to the pool

If the packages names are the same I don't see the need to add yet another
line to the debian/control file, packages.debian.org would just need to point
to http://screenshots.debian.org/ and that's it.

> As far as getting started:
> 
>  * Would this need to start on debian.net?

Probably, until a proof of concept is working and an official domain is
provided.

>  * What would be the requirements/limitations/guidelines?

Do you mean server requirements? I guess that it's disk and bandwidth. 
As for limitations, if you are restricting this to DD uploads there is a
severe limitation (i.e. users cannot 'contribute' screenshots)

> I would really appreciate any comments and suggestions on this.

I say that is a good idea, but I'm not sure how screenshots.debian.org would
help your friend. If you are talking about one-five screenshot per package
(or per package version) that is hardly sufficient to explain how a package
manager works. Better yet if someone wrote a package management document
using DocBook and including screenshots and that was published in the
website.

Regards

Javier


signature.asc
Description: Digital signature

Re: db.debian.org (and related infrastructure) updates

[Miriam Ruiz]

--- Manoj Srivastava <[EMAIL PROTECTED]> escribió:

> On Thu, 4 Jan 2007 10:02:16 +0100 (CET), Miriam Ruiz
> <[EMAIL PROTECTED]> said:  
> 
> > Anyway, I don't think that classification will fit Debian's
> > needs. It's self described as "sex of a subject for clinical
> > purposes, such as the selection of sex-based grown metrics". To
> > start with, it talks about sex, and not gender.  Even more, I don't
> > think medical or clinical data should go into Debian's LDAP.
> 
> Err, so now the specification of a binary gender field is
>  unacceptable and confidential medical information that should be
>  expunged from db.d.o?

Sorry? I guess you misundestood my mail. I was answering kev's suggestion
about the standard described at
http://medical.nema.org/Dicom/CP/CPack_23/cp373_lb.pdf

Miry


__
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis! 
Regístrate ya - http://correo.yahoo.es 

__
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis! 
Regístrate ya - http://correo.yahoo.es 


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

Re: FSG Packaging Summit in Berlin

[Manoj Srivastava]

On Thu, 4 Jan 2007 05:47:58 -0800 (PST), Ottavio Caruso <[EMAIL PROTECTED]> 
said: 

> Sebastian Feltel wrote:
>> If you are aware of currently unmentioned events, news or whatever
>> please report [1] them. We (meaning the regular contributors to
> DWN)
>> cannot read every single Debian/Linux/FOSS-related mailing list or
>> website so we need your support.

> But _this_ is the point: the event was a month ago and I only
> learned about it yesterday on linuxdevices.com:
> http://www.linuxdevices.com/news/NS9555158297.html

So what precisely is the nature of your complaint?  That
 people who are already generously volunteering their time are not
 meeting your reporting standards?  I suppose you are entitled to a
 refund.

manoj
-- 
It's not whether you win or lose, it's how you place the blame.
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: db.debian.org (and related infrastructure) updates

[Manoj Srivastava]

On Thu, 4 Jan 2007 10:02:16 +0100 (CET), Miriam Ruiz
<[EMAIL PROTECTED]> said:  

> Anyway, I don't think that classification will fit Debian's
> needs. It's self described as "sex of a subject for clinical
> purposes, such as the selection of sex-based grown metrics". To
> start with, it talks about sex, and not gender.  Even more, I don't
> think medical or clinical data should go into Debian's LDAP.

Err, so now the specification of a binary gender field is
 unacceptable and confidential medical information that should be
 expunged from db.d.o?

manoj
incredulous
-- 
How much does she love you?  Less than you'll ever know.
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: FSG Packaging Summit in Berlin

[Andrew Saunders]

On 1/4/07, Joey Hess <[EMAIL PROTECTED]> wrote:

Ottavio Caruso wrote:
> There is a wide spread feeling (if you read LWN.net) that a lot that
> happens in Debian today isn't made public.

I'm boycotting feeding any useful information to LWN anymore until they
retract their latest blanket insult of all DD's and stop being so biased.
YMMV.


Could you pretty please elaborate on this a little bit? It'd be most
interesting to hear your views on LWN's Debian-related coverage in
detail. Perhaps a blog post, should you consider it too off-topic for
-devel?

Cheers,

--
Andrew Saunders


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

Re: FSG Packaging Summit in Berlin

[Joey Hess]

Ottavio Caruso wrote:
> I don't think he had a moral imperative to do it, but I can't see why
> he or any others involved shouldn't have done it

I was ill during and afterwards, and didn't have energy to mention it,
although my presentation, such as it was, is up on my wiki[3]. Anyway, I
was not invited due to being a Debian developer (neither, AFAIK, were
the other two current DD's who attended).

I also prefer not to waste energy posting about things that are
currently vaporware. If a real spec starts being developed, or code
starts being written, it will be much more appropriate for a technical
list like debian-devel (or more appropriatly, debian-dpkg). «Standards
group meets, decides to try to do something.» is fairly offtopic here,
as is «The author of yum is a cool guy and I talked about rpm a lot with
people from Red Hat.»

Anyway, Ian Murdock has blogged about the meeting extensively[1][2].
Planet Debian is an official Debian resource and received those blog
postings.

> There is a wide spread feeling (if you read LWN.net) that a lot that
> happens in Debian today isn't made public.

I'm boycotting feeding any useful information to LWN anymore until they
retract their latest blanket insult of all DD's and stop being so biased.
YMMV.

-- 
see shy jo

[1] http://ianmurdock.com/?p=388
[2] http://ianmurdock.com/?p=391
[3] http://kitenet.net/~joey/talks/alien-lsb.html


signature.asc
Description: Digital signature

Re: FSG Packaging Summit in Berlin

[Ottavio Caruso]

Sebastian Feltel wrote:
> If you are aware of currently unmentioned events, news or whatever
> please report [1] them. We (meaning the regular contributors to
DWN)
> cannot read every single Debian/Linux/FOSS-related mailing list or
> website so we need your support.

But _this_ is the point: the event was a month ago and I only learned
about it yesterday on linuxdevices.com:
http://www.linuxdevices.com/news/NS9555158297.html


-- 
Ottavio Caruso

I will not purchase any computing equipment from manufacturers that recommend 
Windows Vista™ or any other Microsoft® products.
http://www.pledgebank.com/boycottvista

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


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

Re: FSG Packaging Summit in Berlin

[Ottavio Caruso]

Kevin Mark wrote:
> Hi Ottavio,
> are you suggesting that Joey(or any DD) should have announced 
> his/her
> involvment in this type of event on a Debian mailing list? 
> Maybe the event was not open to the public?
> Is there a mailing list where DD's mention events they are 
> attending on
> behalf of Debian?

I don't think he had a moral imperative to do it, but I can't see why
he or any others involved shouldn't have done it and I think that
debian-devel, which is read not only by developers, was the right
place.

There is a wide spread feeling (if you read LWN.net) that a lot that
happens in Debian today isn't made public.

-- 
Ottavio Caruso

I will not purchase any computing equipment from manufacturers that recommend 
Windows Vista™ or any other Microsoft® products.
http://www.pledgebank.com/boycottvista

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


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

Re: etch's upgrades during life cycle

[Dominic Hargreaves]

On Thu, Jan 04, 2007 at 11:00:16AM +, Paul Waring wrote:

> I think the problem that many people find with Debian is that they do 
> want the stability and security of stable, but at the same time they 
> don't want to be a dozen releases behind upstream. I've seen many 
> occasions where there's been a new release with useful features that has 
> been available in upstream for months and it's still not in Debian 
> stable, even though it is available in the package repositories of other 
> Linux distributions. It's not so much a case of wanting to be on the 
> bleeding edge for most people, but more that we don't want to still be 
> powering our machines with crank handles when everyone else has moved on 
> to electricity.

backports.org is, to my mind, a perfect solution to this problem; it
allows you to selectively upgrade your favourite/important packages that
you need, whilst retaining the stable base on which to run them.

One proviso I would add to that is that it's only good so long as it
doesn't move too much focus away from Debian's own stable releases. I
can't see any evidence of that at present. It's also possibly the case
that backports.org could/should made more official or at least offically
recommended by Debian, although I understand why this isn't necessarily
the case right now.

However, the original question was about hardware support, which is a
rather special case. I've spent many frustrated hours getting Debian
stable onto modern hardware using various tricks and hacks, and I'm sure
anyone running Debian extensively in production has had similar
experiences. This is one area where an official updated installer and
kernel would greatly improve life, and I'm very interested by Moritz's
comment that this is planned for etch.

Cheers,

Dominic.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)


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

Re: etch's upgrades during life cycle

[Paul Waring]

Daniel Baumann wrote:

however, if you want to have latest and greatest but with stability and
security as you know it from debian stable, then you are asking for the
impossible.


I think the problem that many people find with Debian is that they do 
want the stability and security of stable, but at the same time they 
don't want to be a dozen releases behind upstream. I've seen many 
occasions where there's been a new release with useful features that has 
been available in upstream for months and it's still not in Debian 
stable, even though it is available in the package repositories of other 
Linux distributions. It's not so much a case of wanting to be on the 
bleeding edge for most people, but more that we don't want to still be 
powering our machines with crank handles when everyone else has moved on 
to electricity.


Having said that, the Debian release cycle does seem to be speeding up a 
bit, which is definitely a good thing.


Paul


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

Re: db.debian.org (and related infrastructure) updates

[Miriam Ruiz]

--- Kevin Mark <[EMAIL PROTECTED]> escribió:

> I found a document for DICOM that includes more options
> cheers,
> Kev
> [0] http://medical.nema.org/Dicom/CP/CPack_23/cp373_lb.pdf

Thanks a lot for the reference, it's a good one :)

Anyway, I don't think that classification will fit Debian's needs. It's self
described as "sex of a subject for clinical purposes, such as the selection of
sex-based grown metrics". To start with, it talks about sex, and not gender.
Even more, I don't think medical or clinical data should go into Debian's
LDAP.

Miry


__
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis! 
Regístrate ya - http://correo.yahoo.es 

__
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis! 
Regístrate ya - http://correo.yahoo.es 


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

Re: What happened to Agnula.org (DeMuDi)?

[Andrea Glorioso]

On Wed, Jan 03, 2007 at 11:44:43PM +0100, RalfGesellensetter wrote:
> Did the domain expire?
> 
> demudi.org is full of dead links now.
>  
> [EMAIL PROTECTED] is dead, too.

Due to a miscommunication (we still have to understand of whom with whom)
the domain expired and was taken by a domain squatter.  We already sent a
"kind" request to give back the domain, considering that the name AGNULA
is a registered trademark in the European Union, and we will use the UDRP
procedures if that is feasible.

In the meantime, we have registered the agnula.info domain and we are
transitioning all the services to use that domain.

Sorry for the problem,

-- 
Andrea GloriosoAssistant Researcher, Politecnico di Torino
Dipartimento di Automatica e Informatica, Internet Media Group
   Corso Duca degli Abruzzi, 24 - 10129 Torino (TO) - Italy
 T: +39-011-564-7036 M: +39-348-921-4379 F: +39-011-564-7099