Re: Marcelo Magallon (lib3ds maintainer) MIA?

[Martin Michlmayr]

* 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.
-- 
Martin Michlmayr
http://www.cyrius.com/


signature.asc
Description: Digital signature

Re: Marcelo Magallon (lib3ds maintainer) MIA?

[Miles Bader]

Martin Michlmayr <[EMAIL PROTECTED]> writes:
>> 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.

Er, does that imply that my (non-signed) message likely ended up in the
bit-bucket...?

-Miles

-- 
=
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.


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

Re: Marcelo Magallon (lib3ds maintainer) MIA?

[Martin Michlmayr]

* Miles Bader <[EMAIL PROTECTED]> [2006-07-08 17:32]:
> Er, does that imply that my (non-signed) message likely ended up in the
> bit-bucket...?

Problably not.  I sent him non-signed mail in the past and got
replies.
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Long blurbs repeated in many package descriptions considered harmful

[Enrico Zini]

Hello,

some groups of packages in Debian share introductory pieces in the
package description.  For example, most pike packages have this:

 Pike is an interpreted, object-oriented, dynamic programming language
 with a syntax similar to C. It includes many powerful data types and
 a module system that, for instance, provides image manipulation together,
 with support for graphics formats like SVG, JPG, PNG, GIF, XCF and many
 others,  database connectivity, advanced cryptography, XML/HTML parsers
 and others. To learn more about pike, please visit http://pike.ida.liu.se/

While these blurbs are informative, they provide information not
strictly related to the package itself.  As a consequence, if you do
"apt-cache search image" you get all of pike, including irrelevant
things like "pike7.6-public.network.pcap" or
"pike7.6-public.protocols.syslog".

This is not normally annoying in simple apt-cache search queries, but it
becomes nasty when trying to do some smarter text mining on the package
descriptions.  Think bayesian tools[1], or my new algorithms for mapping
a keyword search to a tag search[2].
  
Many thanks to the KDE developers for removing the similar blurb that
they used to have.  They did it nicely, and in a way that others could
follow.

Would it be worth adding a mention to this to the package description
part of the developers-reference?


Ciao,

Enrico

[1] for example, we have something cooking up as a Summer of Code
project: http://wiki.debian.org/SummerOfCode2006 (see DebtagsAI)
[2] http://lists.alioth.debian.org/pipermail/debtags-devel/2006-July/001292.html
-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Long blurbs repeated in many package descriptions considered harmful

[Lars Wirzenius]

la, 2006-07-08 kello 12:40 +0200, Enrico Zini kirjoitti:
> some groups of packages in Debian share introductory pieces in the
> package description.  For example, most pike packages have this:

I tend to like them, if they're concise and at the end of the
description. They save me from having to look up the main package for a
description of what it is all about.

-- 
You need fewer comments, if you choose your names carefully.


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

Re: Long blurbs repeated in many package descriptions considered harmful

[Mike Hommey]

On Sat, Jul 08, 2006 at 12:40:57PM +0200, Enrico Zini <[EMAIL PROTECTED]> wrote:
> Many thanks to the KDE developers for removing the similar blurb that
> they used to have.  They did it nicely, and in a way that others could
> follow.

... which is... ?


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

Re: Long blurbs repeated in many package descriptions considered harmful

[Enrico Zini]

On Sat, Jul 08, 2006 at 01:47:48PM +0200, Mike Hommey wrote:
> On Sat, Jul 08, 2006 at 12:40:57PM +0200, Enrico Zini <[EMAIL PROTECTED]> 
> wrote:
> > Many thanks to the KDE developers for removing the similar blurb that
> > they used to have.  They did it nicely, and in a way that others could
> > follow.
> ... which is... ?

You lazy one...

apt-cache show kate konqueror ... :

 This package is part of KDE, and a component of the KDE base module.
 See the 'kde' and 'kdebase' packages for more information.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Long blurbs repeated in many package descriptions considered harmful

[Enrico Zini]

On Sat, Jul 08, 2006 at 01:52:57PM +0300, Lars Wirzenius wrote:
> la, 2006-07-08 kello 12:40 +0200, Enrico Zini kirjoitti:
> > some groups of packages in Debian share introductory pieces in the
> > package description.  For example, most pike packages have this:
> I tend to like them, if they're concise and at the end of the
> description. They save me from having to look up the main package for a
> description of what it is all about.

I think it is essential to provide information about acronyms and other
high-tech names, however they should be essential and they shouldn't
distort search results mentioning things that are not present in the
package.  When the pike module for pcap says what is pike, it's ok.  But
when it mentions image manipulation, database connectivity and XML
parsers, then it's strongly misleading.

For example, the pike blurb could be summarised with something like:

  Pike is an interpreted, object-oriented, dynamic programming language
  with a syntax similar to C.  To learn more about pike, see the package
  pike7.6 or visit http://pike.ida.liu.se/


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Long blurbs repeated in many package descriptions considered harmful

[Adam Borowski]

On Sat, Jul 08, 2006 at 02:18:19PM +0200, Enrico Zini wrote:
> For example, the pike blurb could be summarised with something like:
> 
>   Pike is an interpreted, object-oriented, dynamic programming language
>   with a syntax similar to C.  To learn more about pike, see the package
>   pike7.6 or visit http://pike.ida.liu.se/

For pike itself, that's a good description.  For pike-pcap, no way.

> I think it is essential to provide information about acronyms and other
> high-tech names, however they should be essential and they shouldn't
> distort search results mentioning things that are not present in the
> package.  When the pike module for pcap says what is pike, it's ok.  But
> when it mentions image manipulation, database connectivity and XML
> parsers, then it's strongly misleading.

If you want to explain what "pike" is, I think it would be best to
say "pcap is blah blah blah for the pike programming language".
^
This is exactly the amount of explanation that is due.  No less, no
more.  It tells a casual user well enough "what is pike", but doesn't
include anything not related to the library itself.

Just my 2 zorkmids,
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

confirmed, fuse really needs a start of udev after adding a group, or /dev/fuse ends up with a wrong group

[Junichi Uekawa]

reopen 368674
reassign 368674 fuse-utils
thanks

Hi,

>It works today. Now I remember I installed fuse-utils yesterday, which
>means the fuse group did not still exist when udev started. Restarting
>udev (or rebooting the system, obviously) fixes the issue.

>This behavior seems like the only one possible, so closing the bug.

I've confirmed that this really requires restart of udev after fuse install.

I guess this is a situation that might easily happen with other
packages, and we'll end up with a nonworking system until reboot, some
helpful FAQ for developers might be in order.

I think fuse-utils should restart udev in postinst if udev is used.

I'm cc'ing debian-devel to alert more widely of this behavior, I hope
that's okay.

regards,
junichi
-- 
[EMAIL PROTECTED],netfort.gr.jp}   Debian Project


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

Re: Broken applications: Could we be honest?

[Török Edvin]

On 7/8/06, Art Edwards <[EMAIL PROTECTED]> wrote:

I have been writing to the list about two applications that
are so broken on the AMD64 distribution that they render the
box pretty useless.

Did you send bugreports for those programs?
Btw, what is the appropriate severity level for a package that doesn't
work on a certain architecture at all? Is it release critical?

I'm sure one could say that two measly
applications are no big deal. However, if you do scientific computation
for a living, and two of the primary tools are broken, you now have
a rather clumsy paperweight where a computer should be.

You have the option of running 32-bit debian on the box.

You have the possibility to run a pure64 debian, _and_ create a 32-bit
chroot for applications
that don't yet work on 64bit. It is explained in the debian amd64 howto.
Using this approach you get the advantages of 64bit for applications
that "support" it (i.e. they work on it), and you can use the 32bit
chroot for the rest, there should be no slowdown,
amd64 can run 32bit instruction natively.


Unless such core pieces as the debugging tool (ddd) and the data display tool
(xmgrace) are working,

I am not trying to tell you to use other tools, but here it is what I
use for debugging, and
it works on amd64:
I am using clewn [http://clewn.sourceforge.net/], and I am very happy with it.
It display the source code in gvim, and allows you to issue gdb
commands, either from vim, or from the gdb "console". It has support
for watches, etc. IMHO it is worth checking out.


it is dishonest to pretend that the 64-bit version
is ready for testing.

Did you mean "testing" as in "debian testing distro, aka etch"?


It would be very nice if you, and other distro's, were
to put appropriate caveats on the websites, saying that 64-bit is really not
ready for the prime-time desktop. That way, we could make better purchasing
decisions.

You can still run those apps in 32-bit chroot, so you didn't spend
your money in vain.


Cheers,
Edwin


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

Broken applications: Could we be honest?

[Art Edwards]

I have been writing to the list about two applications that
are so broken on the AMD64 distribution that they render the
box pretty useless. I'm sure one could say that two measly
applications are no big deal. However, if you do scientific computation 
for a living, and two of the primary tools are broken, you now have
a rather clumsy paperweight where a computer should be. You could
argue that we should simply learn new tools, and we could, but we 
should really be doing science instead.

This brought up the question, who uses 64 bit Linux anyway?
Surely gamers do not drive the 64-bit linux community. It can't be the desktop
community, seeing that the standard office tool doesn't really 
work for 64-bit. I would think that scientific and engineering 
users would drive this community. Besides the instruction set, which 
can probably give some speed, but wouldn't justify the cost, the address
space in 64-bit OS's mean that we can solve much larger problems. Unles you're
not doing some heavy-duty, memory-intensive computation, 64-bits seems
to be simply a status symbol.

For compute servers the amd64 distribution is fine. All you really need are 
languages (compilers), libraries and decent MPICH. We run our small, 32 bit
Beowulf on debian with abandon, and from my experience, I look forward to
converting it to amd64 ... with a 32-bit node where things actually work.

Unless such core pieces as the debugging tool (ddd) and the data display tool
(xmgrace) are working, it is dishonest to pretend that the 64-bit version 
is ready for testing. It would be very nice if you, and other distro's, were 
to put appropriate caveats on the websites, saying that 64-bit is really not 
ready for the prime-time desktop. That way, we could make better purchasing 
decisions.


Art Edwards


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

Re: Broken applications: Could we be honest?

[Jimmy Tang]

On 7/8/06, Art Edwards <[EMAIL PROTECTED]> wrote:
I have been writing to the list about two applications thatare so broken on the AMD64 distribution that they render thebox pretty useless. I'm sure one could say that two measlyapplications are no big deal. However, if you do scientific computation
for a living, and two of the primary tools are broken, you now havea rather clumsy paperweight where a computer should be. You couldargue that we should simply learn new tools, and we could, but weshould really be doing science instead.
This brought up the question, who uses 64 bit Linux anyway?Surely gamers do not drive the 64-bit linux community. It can't be the desktopcommunity, seeing that the standard office tool doesn't reallywork for 64-bit. I would think that scientific and engineering
users would drive this community. Besides the instruction set, whichcan probably give some speed, but wouldn't justify the cost, the addressspace in 64-bit OS's mean that we can solve much larger problems. Unles you're
not doing some heavy-duty, memory-intensive computation, 64-bits seemsto be simply a status symbol.For compute servers the amd64 distribution is fine. All you really need arelanguages (compilers), libraries and decent MPICH. We run our small, 32 bit
Beowulf on debian with abandon, and from my experience, I look forward toconverting it to amd64 ... with a 32-bit node where things actually work.Unless such core pieces as the debugging tool (ddd) and the data display tool
(xmgrace) are working, it is dishonest to pretend that the 64-bit versionis ready for testing. It would be very nice if you, and other distro's, wereto put appropriate caveats on the websites, saying that 64-bit is really not
ready for the prime-time desktop. That way, we could make better purchasingdecisions.At the risk of imposing what we do at our work place onto your work flow, i find that users generally should have access to better debuggers/profilers than what ships with standard gnu distros. presumably if you are doing scientific computations, you probably have access to a commercial compiler? i know that the portland group compilers ship with a fairly good gui debugger if you are not satisfied with gdb (in parallel attached to each running process)
also shouldnt users be using programs like xmgrace on their local workstations? again with out trying to impose my workflow to yours, i find sometimes users do silly things on the head node on clusters, and I tend to try and get my users to do post analysis etc... stuff that can run serially on their own desktops whenever possible.
Jim-- Jimmy TangTrinity Centre for High Performance Computing,Lloyd Building, Trinity College Dublin.http://www.tchpc.tcd.ie/ 

Re: Broken applications: Could we be honest?

[Roger Leigh]

Art Edwards <[EMAIL PROTECTED]> writes:

> I have been writing to the list about two applications that are so
> broken on the AMD64 distribution that they render the box pretty
> useless.

From the look of things, we are talking about a single bug in a single
library.  So the system is hardly "useless".  We just need to fix that
bug.

Please start by filing a bug report.  I can't see anything here:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=lesstif2

A new version was released a month ago, but hasn't yet been packaged.
It may be that it has already been found and fixed upstream.

http://www.lesstif.org/ReleaseNotes.html

You could try building it yourself to find out.

[...]
> Unless such core pieces as the debugging tool (ddd) and the data
> display tool (xmgrace) are working, it is dishonest to pretend that
> the 64-bit version is ready for testing. It would be very nice if
> you, and other distro's, were to put appropriate caveats on the
> websites, saying that 64-bit is really not ready for the prime-time
> desktop. That way, we could make better purchasing decisions.

I don't think anyone is being dishonest, but you are exaggerating the
seriousness of the situation.  Once a bug is found, please report it
and it will get fixed.  It can't be fixed if the maintainer is not
made aware that there is a problem.


Regards,
Roger

-- 
Roger Leigh
Printing on GNU/Linux?  http://gutenprint.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.


pgpgmaIxeoQRh.pgp
Description: PGP signature

Re: Broken applications: Could we be honest?

[Oliver Rother]

Art Edwards wrote:


Unless such core pieces as the debugging tool (ddd) and the data display tool
(xmgrace) are working, it is dishonest to pretend that the 64-bit version 
is ready for testing. 


ddd and grace are in Debian testing (etch) amd64 and work fine. So where 
exactly is the issue?


We use an mixture of testing and unstable here with the following 
priority setting /etc/apt/preferences:


Package: *
Pin: release a=testing
Pin-Priority: -1
Package: *
Pin: release a=unstable
Pin-Priority: -2

So, if a package is still brocken in testing (as parts of gnome at least 
at box installation time), we take it from unstable with


apt-get install PACKAGE -t unstable,

including its dependencies.

So far, we observerd no major issues.

--
Oliver Rother, Department of Space Physics,
University of Kiel, Leibnizstr. 11/505a, D-24118 Kiel
phone: +49 (0)431 880 4802, fax: +49 (0)431 880 3968
[EMAIL PROTECTED]  www.ieap.uni-kiel.de/et


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

Re: Broken applications: Could we be honest?

[Oliver Rother]

Jimmy Tang wrote:

At the risk of imposing what we do at our work place onto your work 
flow, i find that users generally should have access to better 
debuggers/profilers than what ships with standard gnu distros. 


Well, if you intend to start a flame war on the lists... but enough on that.


presumably if you are doing scientific computations, you probably have
access to a commercial compiler? 


Oh, we do. Consider an project with a timeline of many years or even 
decades of years. would you choose a non onepn source (commercial) 
compiler/debugger for that project? I'm pretty sure, you won't.


also shouldnt users be using programs like xmgrace 


Talking about commerical applications from your point of view - why use 
free software for data analysis when powerful commercial packages like 
IDL are available?


Olli

--
Oliver Rother, Department of Space Physics,
University of Kiel, Leibnizstr. 11/505a, D-24118 Kiel
phone: +49 (0)431 880 4802, fax: +49 (0)431 880 3968
[EMAIL PROTECTED]  www.ieap.uni-kiel.de/et


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

Re: Broken applications: Could we be honest?

[Jimmy Tang]

Hi,


On 7/8/06, Oliver Rother <[EMAIL PROTECTED]> wrote:

> At the risk of imposing what we do at our work place onto your work
> flow, i find that users generally should have access to better
> debuggers/profilers than what ships with standard gnu distros.

Well, if you intend to start a flame war on the lists... but enough on that.


Nope, I have no intentions of any flame wars, i guess i didnt phrase
my initial comments very well (i pretty much meant that from a point
of view that some of our users fortran90 codes that some of our users
need to compile happily breaks different compilers and it just happens
we favour a certain toolchain for certain/most things). i apologise
for that.

also is it necessary to be cross posting to so many lists?



> presumably if you are doing scientific computations, you probably have
> access to a commercial compiler?

Oh, we do. Consider an project with a timeline of many years or even
decades of years. would you choose a non onepn source (commercial)
compiler/debugger for that project? I'm pretty sure, you won't.



again my comments were from the point of view of various codes at our
site uses just breaks different compilers or have different
requirements. and im quite happy to use whatever program/applications
that is available that is suited to a task. i guess im agonistic in my
approach at using the appropriate tool for my tasks that i do.


> also shouldnt users be using programs like xmgrace

Talking about commerical applications from your point of view - why use
free software for data analysis when powerful commercial packages like
IDL are available?



i think you misread that comment. i just made a comment on how users
probably should run things like xmgrace/gnuplot etc... at the end of
their job runs on their own workstations whenever possible.


--
Jimmy Tang
Trinity Centre for High Performance Computing,
Lloyd Building, Trinity College Dublin.
http://www.tchpc.tcd.ie/


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

Testing and honesty

[Ben Armstrong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Art Edwards wrote:
> Unless such core pieces as the debugging tool (ddd) and the data
display tool
> (xmgrace) are working, it is dishonest to pretend that the 64-bit version
> is ready for testing.
It seems your expectations for our "testing" distribution do not match
what we have already stated clearly on our website.  Please read this:

http://www.debian.org/doc/FAQ/ch-ftparchives#s-testing

"Packages are installed into the `testing' directory after they have
undergone some degree of testing in unstable
.

They must be in sync on all architectures where they have been built
and mustn't have dependencies that make them uninstallable; they also
have to have fewer release-critical bugs than the versions currently
in testing. This way, we hope that `testing' is always close to being
a release candidate."

In particular, no guarantees are made that the entire distribution
will be 100% release-critical bug-free.  All we can assure you is that
packages have undergone "some degree of testing" and have fewer
release-critical bugs than the versions currently in testing.  The way
in which the whole system is kept "honest" is by users filing bug
reports, which in turn keeps the RC bug count in testing down to as
few as possible given the resources available to our project.

For a more detailed description of this process, see:

http://www.debian.org/devel/testing

Now, I understand your frustration and disappointment, but I think
before using testing, you should have made it your business to read
and make sure you understood what we have publicly posted about its
readiness for use.  Your rant indicates to me that you haven't, or if
you have, you have seriously misunderstood what you read.

Ben

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEr/V0WpTzygsnE8gRAr61AKCeicxB/AJ4i2wW76/jIN7fb35kVgCgg3EP
hzVwE/Ze7ZeoRIUcw4cIgmc=
=Pf7J
-END PGP SIGNATURE-


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

Bug#377402: ITP: oss-compat -- OSS compatibility package

[Robert Millan]

Package: wnpp
Severity: wishlist
Owner: Robert Millan <[EMAIL PROTECTED]>

* Package name: oss-compat
* URL : http://aybabtu.com/rmh/deb/
* License : GPL
  Description : OSS compatibility package

 This package ensures that OSS support is provided in some way.  On Linux, it
 enables the ALSA compatibility modules.  On other kernels where OSS is the
 default interface, no action is taken.
 .
 The purpose of this package is for applications that only support OSS to depend
 on it, hence preventing common "/dev/dsp not found" errors that would confuse
 unexperienced users.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-1-amd64-k8
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)


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

Re: Bug#368674: confirmed, fuse really needs a start of udev after adding a group, or /dev/fuse ends up with a wrong group

[Marco d'Itri]

On Jul 08, Junichi Uekawa <[EMAIL PROTECTED]> wrote:

> I've confirmed that this really requires restart of udev after fuse install.
No, nothing requires restarting udevd.

The problem is that for performance reasons udevd resolves users and
groups only when loading the rules files. Since the rule referencing
group fuse is installed by the udev package but the group will not
exist until the fuse package is installed, it will be not work as
expected until the next time the rules files are read.

A workaround for packages which do not install their own rules file
(and usually they should not) but use non-standard users or groups is:

[ -x /sbin/udevcontrol ] && udevcontrol reload_rules

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: header sanity check?

[Marc 'HE' Brockschmidt]

Tyler MacDonald <[EMAIL PROTECTED]> writes:
[...]
>   1. If you #include a header directly, you have to depend on that
> package.
[...]
>   4. If you #include a header that doesn't belong to *any* package
> (including the source package you're currently building), that's just
> outright evil.
>
> I also think that #1 and #4 would be easy (trivial, even) to catch in some
> automated way, and that would make an excellent addition to lintian and/or
> linda...

No. lintian checks packages for policy compliance, it does not run
checks on the whole archive (which would be needed to implement checks
for the issues you listed).

Marc
-- 
Fachbegriffe der Informatik - Einfach erklärt
239: MacOS X
   Unix für Weicheier. (Manfred Worm Schäfer)


pgpr6URVFDVzC.pgp
Description: PGP signature

Re: Bug#368674: confirmed, fuse really needs a start of udev after adding a group, or /dev/fuse ends up with a wrong group

[Hamish Moffatt]

On Sat, Jul 08, 2006 at 09:21:09PM +0200, Marco d'Itri wrote:
> On Jul 08, Junichi Uekawa <[EMAIL PROTECTED]> wrote:
> 
> > I've confirmed that this really requires restart of udev after fuse install.
> No, nothing requires restarting udevd.
> 
> The problem is that for performance reasons udevd resolves users and
> groups only when loading the rules files. Since the rule referencing
> group fuse is installed by the udev package but the group will not
> exist until the fuse package is installed, it will be not work as
> expected until the next time the rules files are read.
> 
> A workaround for packages which do not install their own rules file
> (and usually they should not) but use non-standard users or groups is:
> 
> [ -x /sbin/udevcontrol ] && udevcontrol reload_rules

Could you provide an "/etc/init.d/udev reload" function that would
accomplish this, so that other packages don't need to know how?


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


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

select() to /dev/rtc to wait for clock tick timed out. : a different solution

[Junichi Uekawa]

Hi,

I've been worried about this small bug where hwclock waits for timeout in while 
booting, 
with a message:

select() to /dev/rtc to wait for clock tick timed out. 

The machine is a MacBook, and I see references to this message on
dual-core Intel processors, so it looks like a generic problem.

People seem to be working around by 

1. disabling APIC / ACPI? 

2. adding --directisa to hwclock.

of course, there is another real option

3. making the kernel work.



I've noticed that this message appears when I am using 'rtc.ko' for controlling 
RTC. 
There are apparently three drivers for RTC in Linux kernel, 

1. rtc (the old rtc driver)
2. genrtc (generic RTC emulation)
3. rtc-dev (new RTC class framework)

unloading rtc and loading either of genrtc/rtc-dev allowed hwclock to
work on my system.


The question I have is how to accomplish this.  It looks like hotplug
is loading stuff at boot-time, and it's not quite clear as how to make
it not load rtc.

I have tried not loading rtc with blacklisting, but apparently that
makes my system hang after hotplug does its job. Modules set to load
in modconf seems to get loaded very much later than hotplug.


Anyone suffering the same problem?




regards,
junichi
-- 
[EMAIL PROTECTED],netfort.gr.jp}   Debian Project


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

Re: failure notice

[Junichi Uekawa]

Hi,

MD, Please fix.

regards,
junichi

At 8 Jul 2006 16:27:28 -,
[EMAIL PROTECTED] wrote:
> 
> Hi. This is the qmail-send program at viper2.netfort.gr.jp.
> I'm afraid I wasn't able to deliver your message to the following addresses.
> This is a permanent error; I've given up. Sorry it didn't work out.
> 
> <[EMAIL PROTECTED]>:
> 213.254.12.146 does not like recipient.
> Remote host said: 554 Service unavailable; Client host [219.75.232.131] 
> blocked using dul.dnsbl.sorbs.net; Dynamic IP Addresses See: 
> http://www.sorbs.net/lookup.shtml?219.75.232.131
> Giving up on 213.254.12.146.
> 
> --- Below this line is a copy of the message.
> 
> Return-Path: <[EMAIL PROTECTED]>
> Received: (qmail 15734 invoked from network); 8 Jul 2006 16:27:16 -
> Received: from unknown (HELO dancer64.netfort.gr.jp.netfort.gr.jp) (127.0.0.1)
>   by viper2.netfort.gr.jp with SMTP; 8 Jul 2006 16:27:16 -
> Date: Sun, 09 Jul 2006 01:27:18 +0900
> Message-ID: <[EMAIL PROTECTED]>
> From: Junichi Uekawa <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] (Marco d'Itri)
> Cc: Junichi Uekawa <[EMAIL PROTECTED]>,
>   [EMAIL PROTECTED]
> Subject: Re: Bug#377384: udev is ignoring group ownership: sshfs does not 
> work under normal user
> In-Reply-To: <[EMAIL PROTECTED]>
> References: <[EMAIL PROTECTED]>
>   <[EMAIL PROTECTED]>
> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8
>  (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/21.4 (x86_64-pc-linux-gnu)
>  MULE/5.0 (SAKAKI)
> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
> Content-Type: text/plain; charset=US-ASCII
> 
> Hi,
> 
> > > /dev/fuse is created, but it isn't set group permission for fuse; what
> > > might be wrong?
> > Does /etc/udev/rules.d/020_permissions.rules exist?
> > Try to debug this using "udevtest /class/fuse" (or whatever the correct
> > $DEVPATH is).
> 
> It was an already-reported but unfixed bug.
> 
> fuse group isn't reflected to udev since udev isn't restarted since
> fuse user was added.
> 
> I've reassigned the bugs to fuse.
> 
> regards,
>   junichi
> -- 
> [EMAIL PROTECTED],netfort.gr.jp}   Debian Project
> 


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

Re: Broken applications: Could we be honest?

[Charles Plessy]

Le Sat, Jul 08, 2006 at 10:09:56AM -0600, Art Edwards a écrit :

> It would be very nice if you, and other distro's, were 
> to put appropriate caveats on the websites, saying that 64-bit is really not 
> ready for the prime-time desktop. That way, we could make better purchasing 
> decisions.

Dear Art,

others already answered why such a caveat would be a very pessimistic
overstatement. I just would like to add that there is a mailing list for
the scientific communauty using and developping Debian, which can
provide insightful comments on the state of scientific computing in
Debian when you are preparing a purchase order.

http://lists.debian.org/debian-science/

"Discussion of issues relating to the use of Debian for science
research, including useful packages, particular problems faced by
scientists using Debian, how to make Debian more useful to scientists,
etc."

Have a nice day,

-- 
Charles Plessy
Wako, Saitama, Japan


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

Re: greylisting on debian.org?

[Thomas Bushnell BSG]

martin f krafft <[EMAIL PROTECTED]> writes:

> This has been brought up. Basically I don't think people were
> opposed to it, but there was noone available to implement it.

There were people opposed to it, in fact.


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

Re: greylisting on debian.org?

[Christian Perrier]

Quoting Thomas Bushnell BSG ([EMAIL PROTECTED]):
> martin f krafft <[EMAIL PROTECTED]> writes:
> 
> > This has been brought up. Basically I don't think people were
> > opposed to it, but there was noone available to implement it.
> 
> There were people opposed to it, in fact.


What were their arguments?




signature.asc
Description: Digital signature