Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Bjørn Mork]

Matthew Garrett  writes:

> powertop makes various recommendations that are only useful in very
> specific circumstances. Disabling polling in hal saves you a small (and
> probably not useful in the real world) amount of power, but is required
> to get to the number of wakeups per second that Arjan was aiming for. I 
> haven't been able to measure any difference in power consumption on a 
> typical system.

I'm sure you know this, but others may not be aware of it...

Modern systems have the ability to put inactive devices in a low power
state to save power.  See for example
http://www.lesswatts.org/projects/devices-power-management/

You'll save between 0.5 and 1.5 W by enabling SATA Aggressive Link Power
Management according to http://www.lesswatts.org/tips/disks.php As this
definitely is measurable, I assume that your measurements have been done
without enabling ALPM?  Or maybe the power saving estimated by lesswatts
is based on normal hard drive usage?

Could you please share the details of what you've measured?  Which type
of drives, controllers and drivers are used in a "typical system"?  How
about a "typical laptop" (which in my world is the only system class
where this matters anyway)?  How about "modern laptop" (AHCI controller,
SATA DVD)?



Bjørn


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Bjørn Mork]

Michael Biebl  writes:

> See the hal-disable-polling man page. In short: hardware support for MMC media
> change notification is broken.

Err.  You are using the "broken firmware" argument both ways.

You should follow your own advice regarding the drives spinning up:
Implement a blacklist of devices with broken MMC media change
notification and only poll devices in this blacklist.


Bjørn



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#525192: ITP: vtg -- Vala Toys for gEdit

[Stefano Zacchiroli]

On Thu, Apr 23, 2009 at 12:44:24AM +0300, Marc-André Lureau wrote:
> 2009/4/23 Josselin Mouette :
> > The package name doesn’t sound really helpful. How about something like
> > gedit-plugins-vala?
> 
> I fully agree. However, upstream name is vtg. I am not familiar with
> policy about upstream package name, and whether we can rename them (I
> guess it's not a so good idea).

Well, "vtg" does not look like particularly conflict prone to me, so
it can probably stay at the *source* package name. On the contrary,
"gedit-plugins-vala" looks like a way better *binary* package name,
which is what users see.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Bits from the 2nd Debian Groupware Meeting

[Sune Vuorela]

On 2009-04-23, Olivier Berger  wrote:
> Hi.
>
> Le mercredi 22 avril 2009 à 22:52 +0200, Guido Günther a écrit :
>> On Wed, Apr 22, 2009 at 10:11:16PM +0200, Bernd Zeimetz wrote:
>
>> > sure - but where was this meeting announced? I was pretty surprised by the
>> We contacted the various groupware maintainers as well as the groupware
>> related clients (e.g. [1]) and it's been on the wiki page[2].
>
>> [1]: 
>> http://www.mail-archive.com/pkg-evolution-maintain...@lists.alioth.debian.org/msg03370.html
>
> Well... as maintainer of phpgroupware, I probably missed the
> invitation... or you failed to send it ? :-/

And kontact (kolab klient) maintainers at least missed it if invited ..
(I don't remember seeing it though)

I would like some cooperation with groupware "server" people about some
of the more groupware related issues of kontact (kmail, korganizer,
kaddressbook, ...)

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux-libre for Debian Lenny

[Bernd Zeimetz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robert Millan wrote:
> Hi,
> 
> As you probably know, back in December last year it was decided [1] that the
> Linux package shipped with Debian Lenny would include non-free code in it
> (so-called "blobs" of binary-only firmware).

This still does NOT warrant to post such things on debian-devel-announce. It is
more than offtopic there.


Bernd

- --
 Bernd Zeimetz   Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEUEARECAAYFAknwOm0ACgkQBnqtBMk7/3lCjACfRM4ApP0MFNfOGzaXJjbAFWfs
PpQAl3mS+fzMU/XTa1cN8n8Lsxt1GpI=
=67t2
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bits from the 2nd Debian Groupware Meeting

[Olivier Berger]

Hi.

Le mercredi 22 avril 2009 à 22:52 +0200, Guido Günther a écrit :
> On Wed, Apr 22, 2009 at 10:11:16PM +0200, Bernd Zeimetz wrote:

> > sure - but where was this meeting announced? I was pretty surprised by the
> We contacted the various groupware maintainers as well as the groupware
> related clients (e.g. [1]) and it's been on the wiki page[2].

> [1]: 
> http://www.mail-archive.com/pkg-evolution-maintain...@lists.alioth.debian.org/msg03370.html

Well... as maintainer of phpgroupware, I probably missed the
invitation... or you failed to send it ? :-/

Anyway, not such a big deal.

Regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux-libre for Debian Lenny

[maximilian attems]

On Thu, Apr 23, 2009 at 11:21:56AM +0200, Robert Millan wrote:
> 
> As you probably know, back in December last year it was decided [1] that the
> Linux package shipped with Debian Lenny would include non-free code in it
> (so-called "blobs" of binary-only firmware).
> 
> While the majority of the project supported this decision, it is still true
> that many of us users and developers feel strongly committed to freedom, and
> would rather reject the practical benefit of that code than submit ourselves
> to the restrictions that come with it.
> 
> This is to announce that Debian packages of Linux-libre [2] are now available
> for Lenny users who want to use them:
> 
[snipp links]

no point in posting that to devel announce.
this work is pointless and has no review at all by the debian kernel team.

if you want a working and dfsg free converging linux-2.6 use our sid packages.
we are actively working with upstream in getting allmost all drivers
using request_firmware() and providing the corresponding linux-firmware
in non-free. see http://wiki.debian.org/KernelFirmwareLicensing for
status. excluding drivers/staging 2.6.29 is allmost there, upcoming
2.6.30 has further request_firmware() and dfsg improvements.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux-libre for Debian Lenny

[Paul Wise]

On Thu, Apr 23, 2009 at 5:36 PM, maximilian attems  wrote:

> no point in posting that to devel announce.

Agreed.

> this work is pointless

Only if you think FSF-free is pointless, obviously that isn't everyone.

> if you want a working and dfsg free converging linux-2.6 use our sid packages.
> we are actively working with upstream in getting allmost all drivers
> using request_firmware() and providing the corresponding linux-firmware
> in non-free. see http://wiki.debian.org/KernelFirmwareLicensing for
> status. excluding drivers/staging 2.6.29 is allmost there, upcoming
> 2.6.30 has further request_firmware() and dfsg improvements.

linux-libre goes further and removes even the request_firmware calls
for non-free firmware:

http://static.fsf.org/nosvn/Alexandre_Olivia_-_Linux_Libre_-_LibrePlanet_2009.spx
http://groups.fsf.org/index.php/Alexandre_Oliva_%28LP09%29

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux-libre for Debian Lenny

[Robert Millan]

On Thu, Apr 23, 2009 at 11:52:45AM +0200, Bernd Zeimetz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Robert Millan wrote:
> > Hi,
> > 
> > As you probably know, back in December last year it was decided [1] that the
> > Linux package shipped with Debian Lenny would include non-free code in it
> > (so-called "blobs" of binary-only firmware).
> 
> This still does NOT warrant to post such things on debian-devel-announce. It 
> is
> more than offtopic there.

Hi Bernd

The decision to include non-free firmware in Lenny concerns the whole project.

Providing support for some of our users who would have otherwise been excluded
by this decision is, therefore, something that concerns the whole project as
well.

In spite that you don't, I'm certain many of our users will appreciate this.

Love,

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux-libre for Debian Lenny

[Peter Palfrader]

On Thu, 23 Apr 2009, Robert Millan wrote:

> In spite that you don't, I'm certain many of our users will appreciate this.

Be that as it may, debian-*DEVEL*-announce is not the way to contact our
users.  Instead it's the only must-read list for our developers to keep
informed of stuff that's important for every dd to know.  The advent of
yet another package on ppl.d.o is not that.

-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Consistent formating long descriptions as input data

[Stefano Zacchiroli]

On Wed, Apr 22, 2009 at 10:22:15AM -0500, Manoj Srivastava wrote:
> On Wed, Apr 22 2009, Stefano Zacchiroli wrote:
> > On Tue, Apr 21, 2009 at 11:36:31PM +0200, Vincent Danjean wrote:
> >> No. Adding blank lines before lists is also required.
> > ... so, agreed. The extra price to pay to use Markdown would be that
> > additional line insertion.
> And this is like 6 lines of Pseudo code, and less in compact
>  languages like Perl. A fairly trivial exercise in basic CS logic.

Did I say anywhere that it was difficult or not worth doing? I was
just pointing out a fact, which was clarified in the discussion.

FWIW, I consider it totally worth to gain the benefit of having some
expressive, yet readable, language such as Markdown.

Considering all this thread, can you please summarize the point of
view of policy maintainers on the issue? (which is why I added back
the -policy Cc: in the first place)

TIA,
Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Linux-libre for Debian Lenny

[Ben Finney]

Robert Millan  writes:

> The decision to include non-free firmware in Lenny concerns the whole
> project.
> 
> Providing support for some of our users who would have otherwise been
> excluded by this decision is, therefore, something that concerns the
> whole project as well.

Thanks for providing these packages.

I understand that this packages Linux Libre, which is somewhat different
from the Debian ‘linux-image’ kernel. What is the likelihood that this
work will make its way into Debian main as a supported option?

-- 
 \ “If you pick up a starving dog and make him prosperous, he will |
  `\  not bite you. This is the principal difference between a dog |
_o__)and a man.” —Mark Twain, _Pudd'n'head Wilson_ |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux-libre for Debian Lenny

[Marco d'Itri]

On Apr 23, Robert Millan  wrote:

> In spite that you don't, I'm certain many of our users will appreciate this.
Lurkers told you so in private mails?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: AVR32 port - config.{sub,guess} bug filing

[Michael Tautschnig]

> Hi,
> 
> As some of you may be aware, myself and a few others are working towards
> an AVR32 port of Debian, which is now making good progress. One problem
> we've come across is since AVR32 is such a new architecture, a fair few
> packages have config.{sub,guess} files that are missing the architecture
> and hence fail to build. Since things are coming along nicely now, I feel
> it might be appropriate to start filing wishlist bugs for these, but since
> there are quite a large number of packages with this problem, it could
> easily be regarded as mass filing. So I thought I'd ask here first for
> people's thoughts comments on this matter. Thanks.
> 

I guess the proper solution is copying config.{sub,guess} from /usr/share/misc/
and removing them in clean. If that is the case, wouldn't the list of possibly 
buggy
packages be [1]?

Best,
Michael

[1] http://lintian.debian.org/tags/outdated-autotools-helper-file.html




pgpq1GG7qv7ds.pgp
Description: PGP signature

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Giacomo Catenazzi]

Emilio Pozuelo Monfort wrote:
> Giacomo A. Catenazzi wrote:
>> Emilio Pozuelo Monfort wrote:
>>> Giacomo A. Catenazzi wrote:
 Michael Biebl wrote:
> Giacomo Catenazzi wrote:
>
>> For these two reason (power and security), I think Debian should offer
>> a debconf question, (medium priority), about disabling pooling.
> Sorry, but this is certainly not going to happen.
 Why not?  Is it so bad to give user a choice?
>>> No, it's bad to misuse debconf though.
>> powertop recommend to disable hal polling.
>> (note: powertop is not a school project)
> 
> Then *maybe* it should be disabled by default, but that's not an excuse to
> misuse debconf IMHO.


Sorry, but I don't understand the misuse. I really think it is legitimate.
I don't say to have it as high priority. Why misuse? (so maybe I solve
the misunderstanding.

An other case: polling is useful only on desktop.

> The blacklist for faulty drives on the other hand, installed by
> default, might
> indeed be a good idea though.
 but a blacklist is only a helper, it would not have the complete list of
 broken hardware, and updates on stable are slow.
 So users need to override (easily) the decision (e.g. with the debconf
 question).
>>> No, users should file bugs if their HW is broken so that those can be
>>> blacklisted too.
>> Are you joking?
> 
> No
> 
>> For one year that user could not use debian stable?
> 
> a) There are point releases.
> b) The user can still disable polling even without a debconf question.

how? ;-)  It seems that hal try harder to discourage such polling.
Some low level and dangerous parameters are set in /etc/default,
we can twek easily also the kernel parameters via sysctl, but
hal doesn't use these nice feature.

ciao
cate


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

AVR32 port - config.{sub,guess} bug filing

[Bradley Smith]

Hi,

As some of you may be aware, myself and a few others are working towards
an AVR32 port of Debian, which is now making good progress. One problem
we've come across is since AVR32 is such a new architecture, a fair few
packages have config.{sub,guess} files that are missing the architecture
and hence fail to build. Since things are coming along nicely now, I feel
it might be appropriate to start filing wishlist bugs for these, but since
there are quite a large number of packages with this problem, it could
easily be regarded as mass filing. So I thought I'd ask here first for
people's thoughts comments on this matter. Thanks.

Regards,
Bradley Smith

-- 
Bradley Smith b...@brad-smith.co.uk
Debian GNU/Linux Developer bradsm...@debian.org
GPG: 0xC718D347   D201 7274 2FE1 A92A C45C EFAB 8F70 629A C718 D347


signature.asc
Description: PGP signature

Re: AVR32 port - config.{sub,guess} bug filing

[Bradley Smith]

On Thu, 23 Apr 2009 12:41:52 +0200
Michael Tautschnig  wrote:

> I guess the proper solution is copying config.{sub,guess}
> from /usr/share/misc/ and removing them in clean. If that is the case,
> wouldn't the list of possibly buggy packages be [1]?

That's certainly some of them yes, but lintian only seems to check for
files from earlier than 2004, however AVR32 was only added on 6/6/2006, so
there are certainly considerably more than those.

Regards,
Bradley Smith


-- 
Bradley Smith b...@brad-smith.co.uk
Debian GNU/Linux Developer bradsm...@debian.org
GPG: 0xC718D347   D201 7274 2FE1 A92A C45C EFAB 8F70 629A C718 D347


signature.asc
Description: PGP signature

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Giacomo Catenazzi]

Didier Raboud wrote:
> Giacomo A. Catenazzi wrote:
>> Emilio Pozuelo Monfort wrote:
>>> No, users should file bugs if their HW is broken so that those can be
>>> blacklisted too.
>> Are you joking?
>> For one year that user could not use debian stable?
>>
>> BTW for one reported bug, there are 10 unreported bugs.
>> I try hard to convince people to report bugs and I help
>> translating and explaining how to report bugs.
>> Anyway some user will no report the bug, and you can
>> immagine the people that doesn't hit me ;-)
>>
>> It is also a misuse of bug reports ;-)  because it is
>> required "by design".
>>
>> ciao
>> cate
> 
> Okay. Now reporting bugs for errors in software is a misuse…

read carefully ;-)

These are not errors in software. We are not correcting bugs,
but are telling our users:
- We know that on some hardware this feature has a bad interaction
  with hardware.
- So we put to you (user) the burden to discovery bad hardware
  and telling us.  We will correct it in future. BTW we try harder
  not to let you to disable such feature. So wait next release!

so these are real bug reporting?

BTW polling is not needed on correct software. It is a workaround
for other (but most common) hardwares.

for this reason I think waiting bug report is not a solution
but only a workaround.

ciao
cate


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Giacomo Catenazzi]

Gunnar Wolf wrote:
> Roger Leigh dijo [Wed, Apr 22, 2009 at 03:49:54PM +0100]:
>>> How shall I answer that?
>>> I know that I myself use auto-mounting extensively and also don't expect my
>>> father to type someting like "mount /dev/hdc /mnt/cdrom"
>> Absolutely, but this is a separate issue.  You can still, in any desktop
>> environment, click on a CDROM icon in the filemanager/desktop/wherever,
>> and have the CDROM automounted.  That's done with pmount.
>>
>> This is only /automatic/ mounting on CDROM insertion, where it pops up
>> a window or runs a program on insertion.  Without this automatic HAL
>> notification, you can still easily access the CD without any manual
>> "mount" command.
> 
> ...Which sadly matches user expectations. Since we deactivated the
> autorun facility for a laboratory of Windows machines I have nearby,
> users regularly knock at my door asking why their CDs don't work
> anymore. 

yes, you are right!

[offtopic]

On the other hand, it took few time for windows user to learn
about proper "ejecting" of USB pen.

Users can be educated more easily than developers ;-)

Grandmas know how to "umount" and eject USB keys more
easily that I had with floppy disk on early time in Linux.
We know about hardware, low level disk command, but
we tended to forget how good was the Linux write caching ;-)

so yes, we should be able to handle such user expectation
(but also maybe try to convince user to use better methods,
thus that inserting USB pen and CD should be like ejecting
it (with an extra user action)

ciao
cate


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Giacomo Catenazzi]

Bjørn Mork wrote:
> Michael Biebl  writes:
> 
>> See the hal-disable-polling man page. In short: hardware support for MMC 
>> media
>> change notification is broken.
> 
> Err.  You are using the "broken firmware" argument both ways.
> 
> You should follow your own advice regarding the drives spinning up:
> Implement a blacklist of devices with broken MMC media change
> notification and only poll devices in this blacklist.

Jocking ;-)

Yes, I agree ;-)  Thus we should enable polling only on broken
MMC media, which doesn't support media insertion notification ;-)
Who starts such blacklist? :-)

ciao
cate


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: AVR32 port - config.{sub,guess} bug filing

[Cyril Brulebois]

Bradley Smith  (23/04/2009):
> That's certainly some of them yes, but lintian only seems to check for
> files from earlier than 2004, however AVR32 was only added on
> 6/6/2006, so there are certainly considerably more than those.

Seems like a valid reason to request bumping the date check in lintian.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Linux-libre for Debian Lenny

[Ben Hutchings]

On Thu, 2009-04-23 at 20:32 +1000, Ben Finney wrote:
> Robert Millan  writes:
> 
> > The decision to include non-free firmware in Lenny concerns the whole
> > project.
> > 
> > Providing support for some of our users who would have otherwise been
> > excluded by this decision is, therefore, something that concerns the
> > whole project as well.
> 
> Thanks for providing these packages.
> 
> I understand that this packages Linux Libre, which is somewhat different
> from the Debian ‘linux-image’ kernel. What is the likelihood that this
> work will make its way into Debian main as a supported option?

I believe all the changes Robert made are already in sid, as Maximilian
Attems said.  Although I can't easily tell because there is no diff.gz
that I can quickly download and the changelog just says:

> linux-2.6 (2.6.26-libre2-13lenny2) stable-security; urgency=low
> 
>   * deblob, etc.
> 
>  -- Robert Millan   Tue, 21 Apr 2009 23:04:37 +0200

(stable-security, WTF?)

Ben.



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

Re: Linux-libre for Debian Lenny

[Ben Hutchings]

On Thu, 2009-04-23 at 18:13 +0800, Paul Wise wrote:
[...]
> linux-libre goes further and removes even the request_firmware calls
> for non-free firmware:
> 
> http://static.fsf.org/nosvn/Alexandre_Olivia_-_Linux_Libre_-_LibrePlanet_2009.spx
> http://groups.fsf.org/index.php/Alexandre_Oliva_%28LP09%29

So much for freedom.  Why even keep the drivers in that case?

Ben.



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

Re: Linux-libre for Debian Lenny

[Ben Hutchings]

Robert Millan  wrote:
[...]
> This is to announce that Debian packages of Linux-libre [2] are now available
> for Lenny users who want to use them:
> 
>   deb http://people.debian.org/~rmh/linux-libre lenny main
> 
> Archive key is attached in this signed mail;  it is also available from:
> 
>   http://people.debian.org/~rmh/linux-libre/archive-key.asc
> 
> Builds for i386, amd64 and powerpc are available.  They're based on the Linux
> 2.6.26 version that came with Lenny, which I plan to regularly resync with
> the latest version from the Security Team (as time permits).
[...]

Please change the "Maintainer" field and the distribution field in the
changelog to avoid implying any connection with the kernel or security
teams.

Ben.



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

Bug#525278: ITP: libinfinity -- infinote-based collaborative editing

[Philipp Kern]

Package: wnpp
Severity: wishlist
Owner: Philipp Kern 

* Package name: libinfinity
  Version : 0.3.0 (to be released soon)
  Upstream Author : Armin Burgmeier 
* URL : http://gobby.0x539.de
* License : LGPL
  Programming Lang: C
  Description : infinote-based collaborative editing

libinfinity is the core collaborative editing library for the upcoming
new Gobby version 0.5 and the soon-to-be-released Kooby, and thus the successor
to the obby library currently in the archive.  It implements the so-called
infinote protocol.  I already got packages ready and just need to wait for
the 0.3 release which contains fixes to get multiple library versions
co-installable.

Its protocol and API/ABI is still a bit in flux, thus it will be uploaded
to experimental until it has stabilized.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: AVR32 port - config.{sub,guess} bug filing

[Mike Hommey]

On Thu, Apr 23, 2009 at 12:41:52PM +0200, Michael Tautschnig  
wrote:
> > Hi,
> > 
> > As some of you may be aware, myself and a few others are working towards
> > an AVR32 port of Debian, which is now making good progress. One problem
> > we've come across is since AVR32 is such a new architecture, a fair few
> > packages have config.{sub,guess} files that are missing the architecture
> > and hence fail to build. Since things are coming along nicely now, I feel
> > it might be appropriate to start filing wishlist bugs for these, but since
> > there are quite a large number of packages with this problem, it could
> > easily be regarded as mass filing. So I thought I'd ask here first for
> > people's thoughts comments on this matter. Thanks.
> > 
> 
> I guess the proper solution is copying config.{sub,guess} from 
> /usr/share/misc/
> and removing them in clean. If that is the case, wouldn't the list of 
> possibly buggy
> packages be [1]?

Note that this list can hide some truth, such as packages depending on
autotools-dev but either not using its files, not putting them in the
proper place, or putting them in a place which is not proper anymore.

The last two happened to me, though the packages are now fixed
(one because there were several sets of config.{guess,sub} files used
during build, and another because upstream moved the files)

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bits from the 2nd Debian Groupware Meeting

[Guido Günther]

On Thu, Apr 23, 2009 at 09:38:07AM +, Sune Vuorela wrote:
> On 2009-04-23, Olivier Berger  wrote:
> > Hi.
> >
> > Le mercredi 22 avril 2009 à 22:52 +0200, Guido Günther a écrit :
> >> On Wed, Apr 22, 2009 at 10:11:16PM +0200, Bernd Zeimetz wrote:
> >
> >> > sure - but where was this meeting announced? I was pretty surprised by 
> >> > the
> >> We contacted the various groupware maintainers as well as the groupware
> >> related clients (e.g. [1]) and it's been on the wiki page[2].
> >
> >> [1]: 
> >> http://www.mail-archive.com/pkg-evolution-maintain...@lists.alioth.debian.org/msg03370.html
> >
> > Well... as maintainer of phpgroupware, I probably missed the
> > invitation... or you failed to send it ? :-/
> 
> And kontact (kolab klient) maintainers at least missed it if invited ..
> (I don't remember seeing it though)
> 
> I would like some cooperation with groupware "server" people about some
> of the more groupware related issues of kontact (kmail, korganizer,
> kaddressbook, ...)
I've just added calenderserver-dic...@lists.alioth.debian.org[1] which
we can use for for these kind of "cross groupware server/client"
discussions. I'll add an item to the DeveloperNews[2], hopefully this
way we'll get a list where most of the groupware folks in Debian meet
and exchange ideas.
Cheers,
 -- Guido

[1] http://lists.alioth.debian.org/mailman/listinfo/calendarserver-discuss
[2] http://wiki.debian.org/DeveloperNews


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Matthew Garrett]

 wrote:

>You'll save between 0.5 and 1.5 W by enabling SATA Aggressive Link Power
>Management according to http://www.lesswatts.org/tips/disks.php As this
>definitely is measurable, I assume that your measurements have been done
>without enabling ALPM?  Or maybe the power saving estimated by lesswatts
>is based on normal hard drive usage?

ALPM is only relevant for AHCI and native SATA drives. The majority of
native SATA drives support asynchronous notification, so in that case 
there won't be any polling.

>Could you please share the details of what you've measured?  Which type
>of drives, controllers and drivers are used in a "typical system"?  How
>about a "typical laptop" (which in my world is the only system class
>where this matters anyway)?  How about "modern laptop" (AHCI controller,
>SATA DVD)?

Standard PATA optical drives, typically connected to an Intel 
southbridge running in piix mode.

-- 
Matthew Garrett | mjg59-chiark.mail.debian.de...@srcf.ucam.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Matthew Garrett]

 wrote:
>Michael Biebl  writes:
>
>> See the hal-disable-polling man page. In short: hardware support for MMC 
>> media
>> change notification is broken.
>
>Err.  You are using the "broken firmware" argument both ways.
>
>You should follow your own advice regarding the drives spinning up:
>Implement a blacklist of devices with broken MMC media change
>notification and only poll devices in this blacklist.

The majority of drives would be in that blacklist. This is clearly not a 
scalable approach. I'm not aware of any PATA drives that provide 
notification of media change without any polling being involved.

-- 
Matthew Garrett | mjg59-chiark.mail.debian.de...@srcf.ucam.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux-libre for Debian Lenny

[Ben Finney]

Ben Hutchings  writes:

> On Thu, 2009-04-23 at 20:32 +1000, Ben Finney wrote:
> > I understand that this packages Linux Libre, which is somewhat
> > different from the Debian ‘linux-image’ kernel. What is the
> > likelihood that this work will make its way into Debian main as a
> > supported option?
> 
> I believe all the changes Robert made are already in sid, as
> Maximilian Attems said.

I don't understand that statement. As I understand it, Robert Millan has
packaged someone *else*'s changes: those changes that result in Linux
Libre http://directory.fsf.org/project/linux/>.

If you're saying that Robert's *packaging* of Linux Libre has already
been applied to Debian sid's Linux, I don't see how that makes sense,
since AFAIK Linux Libre isn't in sid.

Are you saying Robert's changes made not only the Debian packaging of
Linux Libre, but also made Linux Libre itself? And that the difference
between Debian's Linux and Linux Libre are now applied in sid?

Or are you saying that there's *no* difference between Debian's Linux
and Linux Libre, except the packaging?

Or something else?

-- 
 \“If it ain't bust don't fix it is a very sound principle and |
  `\  remains so despite the fact that I have slavishly ignored it |
_o__) all my life.” —Douglas Adams |
Ben Finney


pgpA3FEzKYDvx.pgp
Description: PGP signature

Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support

[Emilio Pozuelo Monfort]

Giacomo Catenazzi wrote:
> Emilio Pozuelo Monfort wrote:
>> Giacomo A. Catenazzi wrote:
>>> Emilio Pozuelo Monfort wrote:
 Giacomo A. Catenazzi wrote:
> Michael Biebl wrote:
>> Giacomo Catenazzi wrote:
>>
>>> For these two reason (power and security), I think Debian should offer
>>> a debconf question, (medium priority), about disabling pooling.
>> Sorry, but this is certainly not going to happen.
> Why not?  Is it so bad to give user a choice?
 No, it's bad to misuse debconf though.
>>> powertop recommend to disable hal polling.
>>> (note: powertop is not a school project)
>> Then *maybe* it should be disabled by default, but that's not an excuse to
>> misuse debconf IMHO.
> 
> 
> Sorry, but I don't understand the misuse. I really think it is legitimate.
> I don't say to have it as high priority. Why misuse? (so maybe I solve
> the misunderstanding.

I don't think Debconf is here to workaround bugs. This is like if we start
asking questions in every package asking questions because something *could* go
wrong.

Either polling works fine for almost everybody, and for those who don't we
blacklist the hardware, or if it doesn't work for too many people, we can
whitelist those who work, or we disable polling completely if it were so broken.

But let's not ask questions to disable a feature that most people won't need,
specially when we can solve it by other means.

> An other case: polling is useful only on desktop.

Why?

>> The blacklist for faulty drives on the other hand, installed by
>> default, might
>> indeed be a good idea though.
> but a blacklist is only a helper, it would not have the complete list of
> broken hardware, and updates on stable are slow.
> So users need to override (easily) the decision (e.g. with the debconf
> question).
 No, users should file bugs if their HW is broken so that those can be
 blacklisted too.
>>> Are you joking?
>> No
>>
>>> For one year that user could not use debian stable?
>> a) There are point releases.
>> b) The user can still disable polling even without a debconf question.
> 
> how? ;-)

I dunno, but surely if you can do it through Debconf, you can do it manually. If
it's not trivial, there's a manpage that could be expanded.

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: Linux-libre for Debian Lenny

[Karl Goetz]

On Thu, 23 Apr 2009 12:45:11 +0200
m...@linux.it (Marco d'Itri) wrote:

> On Apr 23, Robert Millan  wrote:
> 
> > In spite that you don't, I'm certain many of our users will
> > appreciate this.
> Lurkers told you so in private mails?

Its not like you appreciate them (users/lurkers, call them what you
will) announcing it on -dev ... (Your not a DD, so STFU etc)

> 

Thanks for the packages Robert!
kk

-- 
Karl Goetz, (Kamping_Kaiser / VK5FOSS)
Debian user / gNewSense contributor
http://www.kgoetz.id.au
No, I won't join your social networking group


signature.asc
Description: PGP signature

Bug#525300: ITP: libmodule-cpants-analyse-perl -- Perl module to generate Kwalitee ratings for a distribution

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 

* Package name: libmodule-cpants-analyse-perl
  Version : 0.82
  Upstream Author : Thomas Klausner , http://domm.zsi.at
* URL : http://search.cpan.org/dist/Module-CPANTS-Analyse/
* License : Perl
  Programming Lang: Perl
  Description : Perl module to generate Kwalitee ratings for a distribution

Kwalitee is an automatically-measurable gauge of how good your software is.
That's very different from quality, which a computer really can't measure in
a general sense. (If you can, you've solved a hard problem in computer
science.)

In the world of the CPAN, the CPANTS project (CPAN Testing Service; also a
funny acronym on its own) measures Kwalitee with several metrics. If you plan
to release a distribution to the CPAN -- or even within your own organization
-- testing its Kwalitee before creating a release can help you improve your
quality as well.

I intend to maintain this module within the Debian Perl Group.
It is needed as a dependency for Test::Kwalitee (ITP #519768).

-- 
Peter Pentchev  r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
If you think this sentence is confusing, then change one pig.


pgpvSyFFMeevV.pgp
Description: PGP signature

Bug#525302: ITP: libsoftware-license-perl -- Perl module that provides templated software licenses

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 

* Package name: libsoftware-license-perl
  Version : 0.009
  Upstream Author : Ricardo Signes 
* URL : http://search.cpan.org/dist/Software-License/
* License : Perl
  Programming Lang: Perl
  Description : Perl module that provides templated software licenses

The Software::License Perl module is used by various tools for
module building, installation, and distribution to provide a simple
way of referencing popular free and open-source software licenses.

I intend to maintain this module within the Debian Perl Group.
It is needed as a dependency for Module::CPANTS::Analyse (ITP #525300).

-- 
Peter Pentchev  r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
I am jealous of the first word in this sentence.


pgpIAH4EQTU6j.pgp
Description: PGP signature

Bug#525304: ITP: libmodule-extractuse-perl -- Perl module to find out modules used by the specified Perl source

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 

* Package name: libmodule-extractuse-perl
  Version : 0.23
  Upstream Author : Thomas Klausner 
* URL : http://search.cpan.org/dist/Module-ExtractUse/
* License : Perl
  Programming Lang: Perl
  Description : Perl module to find out modules used by the specified Perl 
source

Module::ExtractUse is basically a Parse::RecDescent grammar to parse Perl
code. It tries very hard to find all modules (whether pragmas, Core, or
from CPAN) used by the parsed code.

I intend to maintain this module within the Debian Perl Group.
It is needed as a dependency for Module::CPANTS::Analyse (ITP #XX).

-- 
Peter Pentchev  r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
This sentence every third, but it still comprehensible.


pgp6CRekehGSC.pgp
Description: PGP signature

Bug#525303: ITP: libarray-diff-perl -- Perl module to find the differences between two arrays

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 

* Package name: libarray-diff-perl
  Version : 0.05
  Upstream Author : Daisuke Murase 
* URL : http://search.cpan.org/dist/Array-Diff/
* License : Perl
  Programming Lang: Perl
  Description : Perl module to find the differences between two arrays

The Array::Diff module compares two arrays and determines which elements
have been removed or added.

I intend to maintain this module within the Debian Perl Group.
It is needed as a dependency for Module::CPANTS::Analyse (ITP #525300).

-- 
Peter Pentchev  r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
This sentence contains exactly threee erors.


pgptRchGHQMR3.pgp
Description: PGP signature

Bug#525306: ITP: libdata-section-perl -- Perl module to read chunks of data from a module's DATA section

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 

* Package name: libdata-section-perl
  Version : 0.005
  Upstream Author : Ricardo SIGNES 
* URL : http://search.cpan.org/dist/Data-Section/
* License : Perl
  Programming Lang: Perl
  Description : Perl module to read chunks of data from a module's DATA 
section

Data::Section provides an easy way to access multiple named chunks of
line-oriented data in your module's DATA section.  It was written to
allow modules to store their own templates, but probably has other
uses.

I intend to maintain this module within the Debian Perl Group.
It is needed as a dependency for Software::License (ITP #525302).

-- 
Peter Pentchev  r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
This sentence claims to be an Epimenides paradox, but it is lying.


pgpkUkLSDClMF.pgp
Description: PGP signature

Re: Linux-libre for Debian Lenny

[Michael Meskes]

On Fri, Apr 24, 2009 at 12:12:21AM +0930, Karl Goetz wrote:
> On Thu, 23 Apr 2009 12:45:11 +0200
> m...@linux.it (Marco d'Itri) wrote:
> ...
> > Lurkers told you so in private mails?
> 
> Its not like you appreciate them (users/lurkers, call them what you
> will) announcing it on -dev ... (Your not a DD, so STFU etc)

Ehem, Marco is not a DD? 

Even if he wasn't why isn't he allowed to voice this question here? Are you a
DD? Do you post here?

Sorry, I simply don't get it.

Michael

-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: mes...@jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux-libre for Debian Lenny

[Karl Goetz]

On Thu, 23 Apr 2009 17:11:42 +0200
Michael Meskes  wrote:

> On Fri, Apr 24, 2009 at 12:12:21AM +0930, Karl Goetz wrote:
> > On Thu, 23 Apr 2009 12:45:11 +0200
> > m...@linux.it (Marco d'Itri) wrote:
> > ...
> > > Lurkers told you so in private mails?
> > 
> > Its not like you appreciate them (users/lurkers, call them what you
> > will) announcing it on -dev ... (Your not a DD, so STFU etc)
> 
> Ehem, Marco is not a DD? 

No, I believe he is :)

> 
> Even if he wasn't why isn't he allowed to voice this question here?
> Are you a DD? Do you post here?

No, I'm not a DD, and I suspect a number of people who agree with
Robert/would like his packages are not DDs.
This list is particularly famous for telling people who are not DDs to
go and be quiet (in my words, I'm sure the emails don't say that
exactly...)

> 
> Sorry, I simply don't get it.

Sorry, guess I was to terse.
kk

> 
> Michael
> 


-- 
Karl Goetz, (Kamping_Kaiser / VK5FOSS)
Debian user / gNewSense contributor
http://www.kgoetz.id.au
No, I won't join your social networking group


signature.asc
Description: PGP signature

Considering the removal of ntpdate

[Peter Eisentraut]

As described in bug #514318 and elsewhere, the upstream NTP Project has 
deprecated the ntpdate program a long time ago, and it may be time to drop it 
from the Debian distribution.

Most of the functionality of ntpdate is now provided by ntpd (stepping the 
clock without threshold, stepping the clock and exiting without running the 
server).  The only exception that I'm aware of is that ntpd doesn't support 
the use of an outgoing unprivileged port (ntpdate -u).

On the other hand, ntpdate is not developed anymore and has lots of bugs and 
inconveniences, and more lightweight alternatives such as rdate are available 
now as well.

Nevertheless, since ntpdate used to be quite popular, I figured I'd better ask 
here for objections.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Considering the removal of ntpdate

[Stefan Ott]

On Thu, Apr 23, 2009 at 17:45, Peter Eisentraut  wrote:

> Nevertheless, since ntpdate used to be quite popular, I figured I'd better ask
> here for objections.

I still use it when a system's clock is way off and I just want it to
be set to the right time, right now. I guess there are options to ntpd
to do that, so maybe a little wrapper script (telling the user about
the appropriate ntpd command, similar to 822-date) might be a nice
idea.

cheers
-- 
Stefan Ott
http://www.ott.net/

"Tobacco is my favorite vegetable."  -- Frank Zappa


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Considering the removal of ntpdate

[Norbert Preining]

On Do, 23 Apr 2009, Stefan Ott wrote:
> On Thu, Apr 23, 2009 at 17:45, Peter Eisentraut  wrote:
> 
> > Nevertheless, since ntpdate used to be quite popular, I figured I'd better 
> > ask
> > here for objections.
> 
> I still use it when a system's clock is way off and I just want it to

Sorry for chiming in so late.

AFAIR there was a move to even remove ntp, now ntpdate. That is not a
good idea.

> be set to the right time, right now. I guess there are options to ntpd
> to do that, so maybe a little wrapper script (telling the user about
> the appropriate ntpd command, similar to 822-date) might be a nice
> idea.

Good option. But what about the ntp removal?

Best wishes

Norbert

---
Dr. Norbert Preining Vienna University of Technology
Debian Developer  Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
ZAPHOD  Hey, this rock...
FORDMarble...
ZAPHOD  Marble...
FORDIce-covered marble...
ZAPHOD  Right... it's as slippery as... as... What's the slipperiest
thing you can think of?
FORDAt the moment? This marble.
ZAPHOD  Right. This marble is as slippery as this marble.
 --- Zaphod and Ford trying to get a grip on things in
 --- Brontitall, Fit the Tenth.
 --- Douglas Adams, The Hitchhikers Guide to the Galaxy


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Considering the removal of ntpdate

[Peter Palfrader]

On Thu, 23 Apr 2009, Peter Eisentraut wrote:

> As described in bug #514318 and elsewhere, the upstream NTP Project has 
> deprecated the ntpdate program a long time ago, and it may be time to drop it 
> from the Debian distribution.

> Most of the functionality of ntpdate is now provided by ntpd (stepping the 
> clock without threshold, stepping the clock and exiting without running the 
> server).  The only exception that I'm aware of is that ntpd doesn't support 
> the use of an outgoing unprivileged port (ntpdate -u).

I regularly* use ntpdate -u -q -d (unpriv, query, debug).  It's useful
for debugging or just querying other ntp servers.  Does the ntpd suite
provide anything with similar functionality?

Cheers,
weasel

* well, occassionally
-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Consistent formating long descriptions as input data

[Manoj Srivastava]

On Thu, Apr 23 2009, Stefano Zacchiroli wrote:


> Considering all this thread, can you please summarize the point of
> view of policy maintainers on the issue? (which is why I added back
> the -policy Cc: in the first place)

While I can't speak for the policy team (I have not been
 re-delegated yet), I suspect the answer might be to get a working
 implementation out in the wild (it does not have to be packages.d.o or
 anything official -- even a standalone software that takes the output
 from grep-dctrl or parses a Packages file will suffice). This will
 allow us to see what changes to policy might be needed, if any, for
 package descriptions.

Once we ahve a working implementation, and a clear idea of what
 might need to be changed in package descriptions (for example, we
 already know that packages using 'o' as a bullet in unordered lists
 will have to be changed to use one of +.-. or *), we can scan the
 package descriptions to see how many packages would be affected, and
 then decide how to introduce that language into policy (more package
 affected, the more the need for a transition plan)

I do not see any reason this proposal should not become policy,
 eventually, since this deals with the core charter of the technical
 policy: standards that packages need to follow to allow for better
 integration. 

manoj
-- 
Diplomacy is the art of letting the other party have things your
way. Daniele Vare
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Considering the removal of ntpdate

[Marco d'Itri]

On Apr 23, Peter Eisentraut  wrote:

> Nevertheless, since ntpdate used to be quite popular, I figured I'd better 
> ask 
> here for objections.
If it's going to removed from the upstream package then we should follow.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Linux-libre for Debian Lenny

[Josselin Mouette]

Le vendredi 24 avril 2009 à 00:12 +0930, Karl Goetz a écrit :
> Its not like you appreciate them (users/lurkers, call them what you
> will) announcing it on -dev ... (Your not a DD, so STFU etc)

You must be mistaking Marco with a former DPL.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: Linux-libre for Debian Lenny

[Adeodato Simó]

+ Paul Wise (Thu, 23 Apr 2009 18:13:11 +0800):

> linux-libre goes further and removes even the request_firmware calls
> for non-free firmware:

To an hypothetical person that would deeply care about not running
non-free software, does that provide any real gain/benefit/improvement
over running a kernel full of request_firmware() calls, and never
installing a firmware package from non-free in their systems? Honest
question.

-- 
- Are you sure we're good?
- Always.
-- Rory and Lorelai


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Considering the removal of ntpdate

[Harald Braumann]

On Thu, 23 Apr 2009 18:19:07 +0200
Stefan Ott  wrote:

> On Thu, Apr 23, 2009 at 17:45, Peter Eisentraut 
> wrote:
> 
> > Nevertheless, since ntpdate used to be quite popular, I figured I'd
> > better ask here for objections.
> 
> I still use it when a system's clock is way off and I just want it to
> be set to the right time, right now. I guess there are options to ntpd
> to do that, so maybe a little wrapper script (telling the user about
> the appropriate ntpd command, similar to 822-date) might be a nice
> idea.

It's `ntpd -q'. Possibly you'll also need option `-g'.

harry


signature.asc
Description: PGP signature

Re: Consistent formating long descriptions as input data

[Andreas Tille]

On Thu, 23 Apr 2009, Manoj Srivastava wrote:


   While I can't speak for the policy team (I have not been
re-delegated yet), I suspect the answer might be to get a working
implementation out in the wild (it does not have to be packages.d.o or
anything official -- even a standalone software that takes the output
from grep-dctrl or parses a Packages file will suffice). This will
allow us to see what changes to policy might be needed, if any, for
package descriptions.


Would you consider the tasks pages I announced yesterday [1] as such
an implementation.  I continued to work a bit on this and have two
additions to the preprocessor:

   1. The inlist flag has to be unset not only if a line starts
  in the second column again but also if there is an empty line.
   2. You need to escape '#' signs if they appear as first
  character.

See the implementation at the end of this mail.


   Once we ahve a working implementation, and a clear idea of what
might need to be changed in package descriptions (for example, we
already know that packages using 'o' as a bullet in unordered lists
will have to be changed to use one of +.-. or *), we can scan the
package descriptions to see how many packages would be affected, and
then decide how to introduce that language into policy (more package
affected, the more the need for a transition plan)


I tried to detect some examples which need some changes.  You might
like to have a look at my "Debugging Blend":

   http://blends.debian.net/debug/tasks

Some issues are mentioned there - I intend to add some better
documentation if needed but some issues become clear.


   I do not see any reason this proposal should not become policy,
eventually, since this deals with the core charter of the technical
policy: standards that packages need to follow to allow for better
integration.


After dealing with the issue I would do the following resume:

  1. The preprocessing you have to do for markdown is basically
 the same I did for turning description text into html
 programmatically myself.  There is no real benefit if your
 main target is only HTML - however, other output formats
 might benefit from using the preprocessing + markup step.
  2. Markdown is probably better in detecting second level lists
 thank I would have done it programmatically - so here is
 a benefit.  On the other hand there are some strange false
 positives for second level lists.
  3. If we really are doing preprocessing it would be cheap to
 use 's/\so\s/ * /' and even this marker might be detected
 as list marker.  This would be perfectly in contrast to my
 initial suggestion - but consequent if you prefer
 preprocessing anyway.  BTW, I even detected non-ASCII
 bullets in the burn package and because it is QA maintained
 anyway I took the chance to change this while fixing bug
 #517793.  I think we should catch things like this quite
 quickly because even apt-cache show failed to disply
 the description of burn correctly and so I've though
 fixing the problem myself instead of adding another bug
 to a QA maintained package seems reasonable.
  4. I expect more not yet detected needs for preprocessing.
  5. I expect the lintian checks for the markdown format rather
 complicated because there is a lot more freedom in the
 format (which might be an advantage for the editors) and
 some valid markdown input might be successfully rendered
 but into something which conflicts the intention of the
 author.  Compared to my suggestion of formating the
 long descriptions according to stricter rules this adds
 another level of complecity while the lintien checks
 which would be needed for my suggestions would have been
 really cheap.  I'd consider this as a disadvantage.

I might note that I'm not happy that in the case of pure and
simple ASCII output of long descriptions as it is done by current
tools more or less we will have a rendering which does not fit my
taste at all - but I accept that I probably belong to a minority
and if markdown is widely accepted it leads to my initial goal
(tasks pages) as well.

Kind regards

   Andreas.

[1] http://lists.debian.org/debian-devel/2009/04/msg00815.html

Python implementation:

detect_list_start_re = re.compile("^\s+[-*+]\s+")
detect_code_start_re = re.compile("^\s")
detect_code_end_re   = re.compile("^[^\s]")
detect_url_re= re.compile("[fh]t?tp://")

def PrepareMarkdownInput(lines):
ret= ''
inlist = 0
incode = 0
for line in lines:
# strip leading space from description as well as useless trailing
line = re.sub('^ ', '', line.rstrip())
# a '^\.$' marks in descriptions a new paragraph, markdown uses an 
empty line here
line = re.sub('^\.$', '', line)

if detect_code_start_re.search(line):
if incode == 0: # If a list or verbatim mode starts MarkDown needs 
an empty line

Bug#525334: ITP: libmath-random-isaac-perl -- Perl interface to the ISAAC Random Number Generator

[Jonathan Yu]

Package: wnpp
Severity: wishlist
Owner: Jonathan Yu 


* Package name: libmath-random-isaac-perl
  Version : 1.0.2
  Upstream Author : Jonathan Yu 
* URL : 
http://search.cpan.org/~frequency/Math-Random-ISAAC-XS-1.0.2/lib/Math/Random/ISAAC/XS.pm
* License : Public Domain or Artistic/GPL
  Programming Lang: Perl
  Description : Perl interface to the ISAAC Random Number Generator

As with other Pseudo-Random Number Generator (PRNG) algorithms like the 
Mersenne Twister (see Math::Random::MT),
this  algorithm is designed to take some seed information and produce seemingly 
random results as output.

However, ISAAC (Indirection, Shift, Accumulate, Add, and Count) has different 
goals than these commonly used
algorithms. In particular, it's really fast - on average, it requires only 
18.75 machine cycles to generate a
32-bit value. This makes it suitable for applications where a significant 
amount of random data needs to be produced 
quickly, such solving using the Monte Carlo method or for games.

The results are uniformly distributed, unbiased, and unpredictable unless you 
know the seed. The algorithm was
published by Bob Jenkins in the late 90s and despite the best efforts of many 
security researchers, no feasible attacks
have been found to date.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux-libre for Debian Lenny

[Marco d'Itri]

On Apr 23, Adeodato Simó  wrote:

> To an hypothetical person that would deeply care about not running
> non-free software, does that provide any real gain/benefit/improvement
> over running a kernel full of request_firmware() calls, and never
> installing a firmware package from non-free in their systems? Honest
> question.
By removing the means of sinning, they will not be tempted.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Considering the removal of ntpdate

[Christian Perrier]

Quoting Peter Eisentraut (pet...@debian.org):

> Nevertheless, since ntpdate used to be quite popular, I figured I'd better 
> ask 
> here for objections.


Would there be a possibility to prove some kind of wrapper for those
among our users who might have various local stuff that are using
ntpdate ?




signature.asc
Description: Digital signature

Re: Considering the removal of ntpdate

[José Luis Tallón]

Christian Perrier wrote:
> Quoting Peter Eisentraut (pet...@debian.org):
>   
>> Nevertheless, since ntpdate used to be quite popular, I figured I'd better 
>> ask 
>> here for objections.
>>
>> Would there be a possibility to prove some kind of wrapper for those
>> among our users who might have various local stuff that are using
>> ntpdate ?
>> 
>From what was said in this thread, a quite feasible solution could be:
 - For Squeeze: a package "ntpdate" which depends on rdate and
provides a wrapper script, used to emulate ntpdate's main functionality
(set the system's clock) in terms of rdate and mark it as deprecated

- For Squeeze+1: just drop it


* I do use ntpdate "regularly" --every time I fiddle with my  system's
clock or check a customer's older server-- for the same purpose that
weasel gave before.


Regards,

J.L.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Work-needing packages report for Apr 24, 2009

[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: 407 (new: 8)
Total number of packages offered up for adoption: 120 (new: 2)
Total number of packages requested help for: 53 (new: 0)

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



The following packages have been orphaned:

   aspell-tl (#524934), orphaned 3 days ago
 Description: The Tagalog dictionary for GNU Aspell
 Installations reported by Popcon: 38

   bogofilter (#524743), orphaned 4 days ago
 Description: a fast Bayesian spam filter (dummy package)
 Reverse Depends: bogofilter bogofilter-bdb bogofilter-qdbm
   bogofilter-sqlite bogofilter-tokyocabinet claws-mail-bogofilter
 Installations reported by Popcon: 4901

   emcast (#525295), orphaned today
 Description: multicast toolkit
 Installations reported by Popcon: 78

   fte (#525314), orphaned today
 Description: Text editor for programmers - base package
 Reverse Depends: fte fte-console fte-docs fte-terminal fte-xwindow
 Installations reported by Popcon: 244

   ispell-tl (#524935), orphaned 3 days ago
 Description: A Tagalog dictionary for Ispell
 Installations reported by Popcon: 12

   mbrowse (#525297), orphaned today
 Description: a SNMP MIB browser
 Installations reported by Popcon: 317

   mktemp (#524755), orphaned 4 days ago
 Description: tool for creating temporary files
 Installations reported by Popcon: 84509

   pmock (#524936), orphaned 3 days ago
 Description: Python module for unit testing using mock objects
 Installations reported by Popcon: 43

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



The following packages have been given up for adoption:

   pycallgraph (#524937), offered 3 days ago
 Description: Python library that creates call graphs for Python
   programs
 Installations reported by Popcon: 43

   python-glpk (#524938), offered 3 days ago
 Description: Python bindings to the GNU Linear Programming Kit
 Installations reported by Popcon: 41

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



For the following packages help is requested:

   apache2 (#470795), requested 406 days ago
 Description: Co-maintainer wanted
 Reverse Depends: ampache apache2 apache2-dbg apache2-mpm-event
   apache2-mpm-itk apache2-mpm-prefork apache2-mpm-worker
   apache2-prefork-dev apache2-suexec apache2-suexec-custom (159 more
   omitted)
 Installations reported by Popcon: 43998

   ara (#450876), requested 529 days ago
 Description: utility for searching the Debian package database
 Installations reported by Popcon: 117

   asymptote (#517342), requested 55 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 385

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

   boinc (#511243), requested 105 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc-app-milkyway boinc-app-seti boinc-dbg
 Installations reported by Popcon: 1592

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

   dctrl-tools (#448284), requested 544 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies dlocate haskell-devscripts
   hg-buildpackage ia32-archive ia32-libs-tools mlmmj sbuild simple-cdd
 Installations reported by Popcon: 11471

   dpkg (#282283), requested 1614 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source apt-build apt-cross apt-src
   backuppc biblatex-dw build-essential bzr-builddeb cacao-oj6-dbg (217
   more omitted)
 Installations reported by Popcon: 85205

   drscheme (#402589), requested 864 days ago
 Description: PLT scheme programming environment
 Reverse Depends: drscheme minlog proofgeneral-minlog
 Installations reported by Popcon: 311

   elvis (#432298), requested 654 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console el

Re: Linux-libre for Debian Lenny

[Ben Finney]

Adeodato Simó  writes:

> To an hypothetical person that would deeply care about not running
> non-free software, does that provide any real gain/benefit/improvement
> over running a kernel full of request_firmware() calls, and never
> installing a firmware package from non-free in their systems? Honest
> question.

Jokes about “sin” aside: It's a whole lot easier to *discover* such
non-free pieces if one can be confident that, even if installed by
mistake, they will fail to load.

Think of it as “defense in depth”, ensuring that there is more than
one barrier to undesirable elements.

-- 
 \“During my service in the United States Congress, I took the |
  `\initiative in creating the Internet.” —Al Gore |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Work-needing packages report for Apr 24, 2009

[Xavier Oswald]

On 00:27 Fri 24 Apr , w...@debian.org wrote:
>fte (#525314), orphaned today
>  Description: Text editor for programmers - base package
>  Reverse Depends: fte fte-console fte-docs fte-terminal fte-xwindow
>  Installations reported by Popcon: 244

Im about to package eFTE[1], which I think we can say as a replacement of FTE.
What do you think about removing FTE ?

[1]http://efte.cowgar.com/

Greetings,
-- 
  ,''`.  Xavier Oswald
 : :' :  GNU/LINUX Debian Developer
 `. `'   GnuPG Key ID 0x88BBB51E
   `-938D D715 6915 8860 9679  4A0C A430 C6AA 88BB B51E 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Consistent formating long descriptions as input data

[Manoj Srivastava]

On Thu, Apr 23 2009, Andreas Tille wrote:

> On Thu, 23 Apr 2009, Manoj Srivastava wrote:
>
>>While I can't speak for the policy team (I have not been
>> re-delegated yet), I suspect the answer might be to get a working
>> implementation out in the wild (it does not have to be packages.d.o or
>> anything official -- even a standalone software that takes the output
>> from grep-dctrl or parses a Packages file will suffice). This will
>> allow us to see what changes to policy might be needed, if any, for
>> package descriptions.
>
> Would you consider the tasks pages I announced yesterday [1] as such
> an implementation.

Sure. It would be great to have another implementation, perhaps
 one that people can play with (something that, for example, one can
 pipe the output of a grep-dctrl command to, and get an html snippet
 from (hey, that can then be packaged as an ikiwiki plugin).

But the task pages should count as an implementation.
>
> I tried to detect some examples which need some changes.  You might
> like to have a look at my "Debugging Blend":
>
>http://blends.debian.net/debug/tasks
>
> Some issues are mentioned there - I intend to add some better
> documentation if needed but some issues become clear.

Thanks. Once you are through, perhaps some  directives for long
 description policy can be derived from that.

>   1. The preprocessing you have to do for markdown is basically
>  the same I did for turning description text into html
>  programmatically myself.  There is no real benefit if your
>  main target is only HTML - however, other output formats
>  might benefit from using the preprocessing + markup step.

>   2. Markdown is probably better in detecting second level lists
>  thank I would have done it programmatically - so here is
>  a benefit.  On the other hand there are some strange false
>  positives for second level lists.

These should be something we can look at to provide a policy
 recommendation so these false positives can be reduced. 

>   3. If we really are doing preprocessing it would be cheap to
>  use 's/\so\s/ * /' and even this marker might be detected
>  as list marker.  This would be perfectly in contrast to my
>  initial suggestion - but consequent if you prefer
>  preprocessing anyway.  BTW, I even detected non-ASCII
>  bullets in the burn package and because it is QA maintained
>  anyway I took the chance to change this while fixing bug
>  #517793.  I think we should catch things like this quite
>  quickly because even apt-cache show failed to disply
>  the description of burn correctly and so I've though
>  fixing the problem myself instead of adding another bug
>  to a QA maintained package seems reasonable.

I like the idea of  's/^(\s*)o\s+/$1* /' (to preserve the leading
 indentation, in case this was a second level item) as a preprocessing
 step in the interim, in the long term this usage should go down as
 policy starts to deprecate it.

>   4. I expect more not yet detected needs for preprocessing.

Thanks for working on this.

>   5. I expect the lintian checks for the markdown format rather
>  complicated because there is a lot more freedom in the
>  format (which might be an advantage for the editors) and
>  some valid markdown input might be successfully rendered
>  but into something which conflicts the intention of the
>  author.  Compared to my suggestion of formating the
>  long descriptions according to stricter rules this adds
>  another level of complecity while the lintien checks
>  which would be needed for my suggestions would have been
>  really cheap.  I'd consider this as a disadvantage.


> I might note that I'm not happy that in the case of pure and
> simple ASCII output of long descriptions as it is done by current
> tools more or less we will have a rendering which does not fit my
> taste at all - but I accept that I probably belong to a minority
> and if markdown is widely accepted it leads to my initial goal
> (tasks pages) as well.

manoj
-- 
Hartley's First Law: You can lead a horse to water, but if you can get
him to float on his back, you've got something.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux-libre for Debian Lenny

[Ben Hutchings]

On Thu, 2009-04-23 at 23:37 +1000, Ben Finney wrote:
> Ben Hutchings  writes:
> 
> > On Thu, 2009-04-23 at 20:32 +1000, Ben Finney wrote:
> > > I understand that this packages Linux Libre, which is somewhat
> > > different from the Debian ‘linux-image’ kernel. What is the
> > > likelihood that this work will make its way into Debian main as a
> > > supported option?
> > 
> > I believe all the changes Robert made are already in sid, as
> > Maximilian Attems said.
> 
> I don't understand that statement. As I understand it, Robert Millan has
> packaged someone *else*'s changes:

Since Robert was so enthusiastic about the patches I created or adapted
in the run up to the lenny release, and since he prepended to the
changelog for the existing Debian kernel, I assumed he was using those.

> those changes that result in Linux Libre
> http://directory.fsf.org/project/linux/>.

Which appears to be scripted using something like:
http://www.fsfla.org/svn/fsfla/software/linux-libre/scripts/deblob-2.6.26

[...]
> Or are you saying that there's *no* difference between Debian's Linux
> and Linux Libre, except the packaging?

No.

> Or something else?

What I meant was that all the firmware blobs reported as bugs in the
lenny kernel are gone in sid, either through upstream changes or new
Debian patches.  A few more, found later, will be gone in the 2.6.30
package.

(There are three more blobs I spotted in a recent search, which I will
try to separate out when I have the time.  It looks like Linux Libre
already got those.  It still has the blob in
arch/powerpc/sysdev/micropatch.c, though.)

Ben.



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

Re: Linux-libre for Debian Lenny

[Ben Finney]

Ben Hutchings  writes:

> What I meant was that all the firmware blobs reported as bugs in the
> lenny kernel are gone in sid, either through upstream changes or new
> Debian patches.  A few more, found later, will be gone in the 2.6.30
> package.

Right. So we agree than what Robert has announced here is not equal to
the changes that have so far been made to Debian's Linux in sid.

> (There are three more blobs I spotted in a recent search, which I will
> try to separate out when I have the time. It looks like Linux Libre
> already got those. It still has the blob in
> arch/powerpc/sysdev/micropatch.c, though.)

Okay. So I take it then that you would be against separate packaging for
Linux-Libre for Debian, and prefer instead to apply all its changes to
Debian's Linux?

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\  Brain, but how will we get the Spice Girls into the paella?” |
_o__)   —_Pinky and The Brain_ |
Ben Finney


pgp36xIixF4ZT.pgp
Description: PGP signature

Re: Linux-libre for Debian Lenny

[Russ Allbery]

Ben Finney  writes:

> Okay. So I take it then that you would be against separate packaging
> for Linux-Libre for Debian, and prefer instead to apply all its
> changes to Debian's Linux?

I know this wasn't addressed to me, but I feel the urge to weigh in.

I think the removal of even the ability to load non-free firmware is
stupid and self-defeating and certainly don't think that should be done
in Debian, in either the main Linux kernel packages or, for that matter,
in a separate package.  (I'm sure the security team doesn't want to do
twice as many kernel security builds just to support that particular
exercise.)

Whatever other work the Linux-Libre folks, or anyone else for that
matter, do to cleanly separate firmware from the Linux kernel (even for
free firmware, as far as I'm concerned) seems like a good thing to
adopt.

As with any other Debian package, the best approach for adoption is to
get the patches adopted upstream so that everyone can benefit and we
don't have to maintain local divergences.  It sounds like Ben Hutchings
and the Debian kernel team have been doing great work in this area, and
I can only stand and applaud their excellent, constructive resolution of
this problem in a way that's consistent with all of our ideals.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Considering the removal of ntpdate

[Bernd Eckenfels]

In article <20090423163842.ge7...@anguilla.noreply.org> you wrote:
> I regularly* use ntpdate -u -q -d (unpriv, query, debug).  It's useful
> for debugging or just querying other ntp servers.  Does the ntpd suite
> provide anything with similar functionality?

I think ntpdc can provide most of that:

$ ntpdc -c sysinfo pool.ntp.org
system peer:  ntps1-1.cs.tu-berlin.de
system peer mode: client
leap indicator:   00
stratum:  2
precision:-20
root distance:0.01495 s
root dispersion:  0.03755 s
reference ID: [130.149.17.8]
reference time:   cd9b909c.32397ba9  Fri, Apr 24 2009  3:13:00.196
system flags: auth monitor ntp kernel stats
jitter:   0.006210 s
stability:0.000 ppm
broadcastdelay:   0.003998 s
authdelay:0.01 s

Gruss
Bernd


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Work-needing packages report for Apr 24, 2009

[Charles Plessy]

Le Fri, Apr 24, 2009 at 12:27:32AM +, w...@debian.org a écrit :
> 
>mktemp (#524755), orphaned 4 days ago
>  Description: tool for creating temporary files
>  Installations reported by Popcon: 84509

Hi Clint,

you wrote in the WNPP bug:

  I intend to orphan the mktemp package.
  
  The package description is:
   This package provides a utility designed to make temporary
   file handling in shell scripts simple and secure.
  
  It should be replaced entirely by the mktemp in coreutils.

Wouldn't a request for removal be more suitable in that case? (provided that
the corutils maintainers start to distribute mktemp in their binary packages).

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux-libre for Debian Lenny

[Ben Finney]

Russ Allbery  writes:

> As with any other Debian package, the best approach for adoption is to
> get the patches adopted upstream so that everyone can benefit and we
> don't have to maintain local divergences. It sounds like Ben Hutchings
> and the Debian kernel team have been doing great work in this area,
> and I can only stand and applaud their excellent, constructive
> resolution of this problem in a way that's consistent with all of our
> ideals.

I've always been in hearty agreement with all of this.

-- 
 \  “When we talk to God, we're praying. When God talks to us, |
  `\ we're schizophrenic.” —Jane Wagner, via Lily Tomlin, 1985 |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: AVR32 port - config.{sub,guess} bug filing

[Paul Wise]

On Thu, Apr 23, 2009 at 6:27 PM, Bradley Smith  wrote:

> As some of you may be aware, myself and a few others are working towards
> an AVR32 port of Debian, which is now making good progress. One problem
> we've come across is since AVR32 is such a new architecture, a fair few
> packages have config.{sub,guess} files that are missing the architecture
> and hence fail to build.

I'd like to see this problem go away once and for all.

How about the scripts check for newer versions of themselves in the
following paths and run those scripts instead of returning the
information directly? Then the buildds for new architectures could
simply install the required version of autotools-dev and be happy.

/usr/share/automake/
/usr/local/share/automake/
~/.automake/

Some non-FHS compliant paths could be added for platforms that need them.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Aprenda con 1enGoogle.com - Novedades de Abril :: Dattatec.com

[Anuncios - Dattatec . com]

Estimado cliente,

Este es un mensaje de Dattatec.com que seguramente será de su interés.

Temas tratados en el E-mail:
"Presentamos a las ganadoras del fin de semana en Cancún para 2 personas
con todo pago"
"Presentamos 2 nuevos sitios TrabajeEnDattatec.com y 1enGoogle.com"
"Seleccionamos los dominios más hot para Usted."

Por favor, siga este link para poder acceder.
http://dattatec.com/emails/email-21-04-09.html

Departamento de Marketing
Dattatec.com :: Soluciones de Hosting
Su Hosting hecho Simple..!

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

[Daniel Burrows]

On Tue, Apr 21, 2009 at 09:31:31AM +0200, Andreas Tille  was 
heard to say:
> Moreover I see no reason to bind anybody to a certain library
> like markdown.  My experience has shown that people will insist
> on their very own way to do things.  Do you think apt, aptitude,
> synaptic etc. developers would be happy if you start filing bug
> reports to make them use markdown?  So my suggestion leaves
> perfectly space for using markdown as well as even raw text
> output - which would look also better with consistent formatting.

  I'm happy to support whatever markup language people want to use.

  My only concern with markdown is that I use it for my blog, and I
periodically run into weird cases where the formatting doesn't work as
expected.  It seems to be especially bad when you start nesting
formatting elements inside each other (quoted text inside a list inside
a list is one example I found in the past).  I've made a Markdown
version of the release notes for aptitude releases for the last year or
so and I always seem to find myself randomly adjusting indents until it
stops producing the wrong HTML.  For the sorts of markup our
descriptions have now it'll be fine, but it's my experience that when
you give people a hammer they start hitting everything that's vaguely
nail-shaped with it. :-)

  But if people want to use markdown, I'll render it.

  Daniel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: AVR32 port - config.{sub,guess} bug filing

[Mike Hommey]

On Fri, Apr 24, 2009 at 11:22:24AM +0800, Paul Wise wrote:
> On Thu, Apr 23, 2009 at 6:27 PM, Bradley Smith  wrote:
> 
> > As some of you may be aware, myself and a few others are working towards
> > an AVR32 port of Debian, which is now making good progress. One problem
> > we've come across is since AVR32 is such a new architecture, a fair few
> > packages have config.{sub,guess} files that are missing the architecture
> > and hence fail to build.
> 
> I'd like to see this problem go away once and for all.
> 
> How about the scripts check for newer versions of themselves in the
> following paths and run those scripts instead of returning the
> information directly? Then the buildds for new architectures could
> simply install the required version of autotools-dev and be happy.
> 
> /usr/share/automake/
> /usr/local/share/automake/
> ~/.automake/
> 
> Some non-FHS compliant paths could be added for platforms that need them.

It unfortunately wouldn't work for the same reason config.{guess,sub}
updates don't work, and more. It would need to be incorporated upstream,
and all debian sources using config.{guess,sub} should be updated to
these newer versions. That sounds like something that's never going to
happen.

The best debian can do is enforce dpkg-buildpackage or some other dpkg
binary involved in the source extraction or build startup to replace or
hack the config.{guess,sub} files itself[1] before the build.

Mike

1. I, for one, run this before configure:
sed -i '2!b;/^#/ i\exec "/usr/share/misc/'$$file'" "$$@"' $$dir/$$file
and this in clean:
sed -i '2!b;/^exec "/ d' $$dir/$$file
where dir iterates over the directories containing these files and file
iterating over config.{sub,guess}.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: AVR32 port - config.{sub,guess} bug filing

[Paul Wise]

On Fri, Apr 24, 2009 at 1:18 PM, Mike Hommey  wrote:

> It unfortunately wouldn't work for the same reason config.{guess,sub}
> updates don't work, and more. It would need to be incorporated upstream,
> and all debian sources using config.{guess,sub} should be updated to
> these newer versions. That sounds like something that's never going to
> happen.

You don't think upstream would accept the patch? Once they do and the
updates trickle down into new upstreams then this will become more and
more of a non-issue. Obviously it will be a long time before that
happens, probably many years.

Here is what I plan to send upstream:

cur_v=`echo "$timestamp" | sed s/-//g`

for path in \
  "$HOME/.config/automake" \
  /usr/local/share/automake \
  /usr/local/share/misc \
  /usr/share/automake \
  /usr/share/misc \
; do

if test -x "$path/config.sub" ; then
  v=`"$path/config.sub" --time-stamp | sed s/-//g`
  if test "$v" -gt "$cur_v" ; then
"$path/config.sub" $*
exit $?
  fi
fi
done

> The best debian can do is enforce dpkg-buildpackage or some other dpkg
> binary involved in the source extraction or build startup to replace or
> hack the config.{guess,sub} files itself[1] before the build.

That was suggested on IRC the other night, sounds like a good solution
as long as the buildd admins are notified so that they can file bugs.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: AVR32 port - config.{sub,guess} bug filing

[Russ Allbery]

Paul Wise  writes:

> Here is what I plan to send upstream:
>
> cur_v=`echo "$timestamp" | sed s/-//g`
>
> for path in \
>   "$HOME/.config/automake" \
>   /usr/local/share/automake \
>   /usr/local/share/misc \
>   /usr/share/automake \
>   /usr/share/misc \
> ; do
>
> if test -x "$path/config.sub" ; then
>   v=`"$path/config.sub" --time-stamp | sed s/-//g`
>   if test "$v" -gt "$cur_v" ; then
> "$path/config.sub" $*

  case $# in
  0) "$path/config.sub";;
  *) "$path/config.sub" "$@";;
  esac

instead.  $* doesn't quote its arguments, and the above works around a
portability problem with $@ (see the Autoconf manual).

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: AVR32 port - config.{sub,guess} bug filing

[Paul Wise]

On Fri, Apr 24, 2009 at 1:42 PM, Russ Allbery  wrote:

> instead.  $* doesn't quote its arguments, and the above works around a
> portability problem with $@ (see the Autoconf manual).

Thanks, added.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Consistent formating long descriptions as input data (Was: RFC: Better formatting for long descriptions)

[Andreas Tille]

On Thu, 23 Apr 2009, Daniel Burrows wrote:


For the sorts of markup our
descriptions have now it'll be fine, but it's my experience that when
you give people a hammer they start hitting everything that's vaguely
nail-shaped with it. :-)


ROFL.
The whole time of discussion was well spent just for this quote. ;-)
I took the freedom to put a German translation into the fortunes-de.


 But if people want to use markdown, I'll render it.


Same for me

   Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Consistent formating long descriptions as input data

[Andreas Tille]

On Thu, 23 Apr 2009, Manoj Srivastava wrote:


   Sure. It would be great to have another implementation, perhaps
one that people can play with (something that, for example, one can
pipe the output of a grep-dctrl command to, and get an html snippet
from (hey, that can then be packaged as an ikiwiki plugin).


As I said inclusion of the preprocessing code into python-apt or
any other reasonable place where you could turn it into a general
tool makes perfectly sense.  IMHO it makes sense if I continue with
the tests for a while and than offer it for adoption.


   But the task pages should count as an implementation.


I tried to detect some examples which need some changes.  You might
like to have a look at my "Debugging Blend":

   http://blends.debian.net/debug/tasks

Some issues are mentioned there - I intend to add some better
documentation if needed but some issues become clear.


   Thanks. Once you are through, perhaps some  directives for long
description policy can be derived from that.


Yesterday I had the idea to add a "Remarks of Blends-team" feature
which I will "missuse" to add a verbose output of `apt-cache show`
to the packages in question on the page above.  This should enable
an easy way to see the problems quickly.  I'll announce here once
it is finished.


  2. Markdown is probably better in detecting second level lists
 thank I would have done it programmatically - so here is
 a benefit.  On the other hand there are some strange false
 positives for second level lists.


   These should be something we can look at to provide a policy
recommendation so these false positives can be reduced.


Yes, that's the idea.  On the other hand looking at some examples
I have the feeling that sometime markup has a strange way to handle
some lists.  I'll come up with examples once I implemented the
"Remarks feature" so you can easily see what I mean.


   I like the idea of  's/^(\s*)o\s+/$1* /' (to preserve the leading
indentation, in case this was a second level item) as a preprocessing
step in the interim, in the long term this usage should go down as
policy starts to deprecate it.


OK.


  4. I expect more not yet detected needs for preprocessing.


   Thanks for working on this.


Sure.  I startet this thread not just for the sake of havin fun in a
discussion. ;-)

Kind regards

 Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org