Bug#444108: ITP: verilog-mode -- Emacs mode for editing Verilog HDL

[NIIBE Yutaka]

Package: wnpp
Severity: wishlist
Owner: NIIBE Yutaka <[EMAIL PROTECTED]>


* Package name: verilog-mode
  Version : 357
  Upstream Author : Michael McNamara <[EMAIL PROTECTED]>
* URL : http://www.verilog.com
* License : GPL
  Programming Lang: Emacs Lisp
  Description : Emacs mode for editing Verilog HDL

The emacs major mode for editing code of Verilog HDL.
Supports syntax highlighting, automatic indentation.



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

Re: Bug#443769: rt2500-source: Missing dependency on bzip2

[Bastian Blank]

On Tue, Sep 25, 2007 at 06:25:19PM -0500, Manoj Srivastava wrote:
> Not good enough.  What if I am using m-a with kernel.org kernel
>  sources? I won't have a kernel-headers package installed (I don't).  If
>  you need something, depend upon it.

You already built the kernel and therefor have a compiler installed.

Bastian

-- 
Extreme feminine beauty is always disturbing.
-- Spock, "The Cloud Minders", stardate 5818.4


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

Bug#444115: general: network interface (eth0) gets undetected after restrat checked using ifconfig -a

[Antano Solar]

Package: general
Severity: important

When the cmos battery is removed and power unplugged and the system booted . 
I press f2(load defaults) in the cmos screen and the syetm boots very slowly 
and detects my lan card. i.e ifconfig -a lists eth0.
But after this if I shut down the computer and start again or even restart 
it , the network card is not detected . when the network card goes undetected 
even if I boot into windows it remains undetected in windows also. To make 
the netowrk card appear again I need to rerun the procedure of removing the 
batters and unplugging power cable. 

It seems like when shutting down the system the OS is setting some flag or 
something like that in the bios which makes the network card go undetected.

I have tried this in debian etch  , lenny and sidux. 

The results are the same irrespective of the debian distribution.

havent checked it with other distributions yet.

Also about booting up , when I restart or shutdown and start the computer it 
boots prettu fast , but when I clear the bios and boot it takes nearly 3 - 5 
minutes to boot.



-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.22.3-rc1-slh-smp-2 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: Bug#443769: rt2500-source: Missing dependency on bzip2

[Patrick Schoenfeld]

Romain Beauxis wrote:
> Let's say that it's the quantitative approach. Other approaches are just 
> chatty chatty.

Well, quantitative must not always be the best thing. And if it should
be an argument one should create *proper* stats.

> (This search is not adequate, it matches non-module packages like 
> ocaml-search)

Yeah, you name it. I think we should not depend on too much half-baken
stats, that might not be true. I have refined your stats by searching
only with the list of m-a packages and yes the number of bz2 tarballs is
actually higher then the number of gz tarballs.

Stats are:
Total number of packages that could be analyzed: 43
bz2 Packages: 26
gz Packages: 17

So the real percentage seems to be 60% vs. 40%.

> So that makes roughtly 75% of bzip2 tarballs and 25 % of gz tarballs.
> That number would mean to me that it is more likely to have a recommends than 
> a depends.

Yes, thats what I first said. And if that is the better way then
installing it from within module-assistant (what I agree with after
all), then thats the way it should be done with build-essential, too.
That is for consistency reasons.

> For instance, should module-source package also depends on module-assistant ? 

That would not make much sense, but a "Suggests:" would make sense.

> This is the case for many packages but I don't think module-assistant is 
> required to build a package, isn't it an *assistant* ?

It is not required. Yes it is an assistant.

> A simple policy like "source packages must recommend module-assistant and 
> should provide gzip tarballs" would give a common answer, given that it's not 
> a technical issue as far as I see it...

Agreed. A policy defining which tarball to choose and which recommends
to setup would ease a lot.

Regards,

Patrick


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

Re: Bug#443769: rt2500-source: Missing dependency on bzip2

[Patrick Schoenfeld]

Bastian Blank wrote:
> You already built the kernel and therefor have a compiler installed.

But m-a would install all the clutter anyways, wouldn't it?

Regards,
Patrick


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

Bug#444115: general: network interface (eth0) gets undetected after restrat checked using ifconfig -a

[Josselin Mouette]

Le mercredi 26 septembre 2007 à 12:49 +0530, Antano Solar a écrit :
> When the cmos battery is removed and power unplugged and the system booted . 
> I press f2(load defaults) in the cmos screen and the syetm boots very slowly 
> and detects my lan card. i.e ifconfig -a lists eth0.
> But after this if I shut down the computer and start again or even restart 
> it , the network card is not detected . when the network card goes undetected 
> even if I boot into windows it remains undetected in windows also. To make 
> the netowrk card appear again I need to rerun the procedure of removing the 
> batters and unplugging power cable. 

If the problem appears in other operating systems, it sounds like it is
caused by the hardware or the firmware - either the BIOS or the network
card's.

-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

dpkg-shlibdeps and private libraries

[Raphael Hertzog]

Hello,

_rene_ reported me a failure with openoffice and the new dpkg-shlibdeps.


Scanning debian/openoffice.org-writer/usr/lib/openoffice/program/libswui680lp.so
(for Depends field)
dpkg-shlibdeps: failure: couldn't find library libsw680lp.so (note: only 
packages with 'shlibs' files are looked into).


The problem is that libswui680lp.so has libsw680lp.so in NEEDED and thus
dpkg-shlibdeps will try to find that library. I made it a failure when I'm
not able to find the library as dpkg-shlibdeps is supposed to behave like
ld.so and try to use the same mechanism to find out where the lib is.

libswui680lp.so has an RPATH set to $ORIGIN ... which is an environment
variable apparently defined by the openoffice startup script/program. 
This variable is not set a build time (and the code wasn't expecting
variables at that place anyway).

Given this info, I would suggest _rene_ to use LD_LIBRARY_PATH to override
the directories that are looked into and be done with it, however while
discussing with him we wondered if ld.so didn't lookup in the directory 
of the object being loaded as well ?

If that's the case, then I should modify dpkg-shlibdeps to also look into
the directory containing the binary that's currently analyzed...

Can anyone confirm or infirm this ?

On the other hand, maybe I should just be less picky for shared objects
without SONAME... I'm not sure about it.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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

Re: AM status for Krystian Wlosek?

[Don Armstrong]

On Tue, 25 Sep 2007, Piotr Roszatycki wrote:
> I suppose that everyone are busy today, so do I. I'm a little tired
> with sponsoring his packages and I know he could to upload his
> packages by his own.
> 
> I really don't undestand why new developers are checked so precisely.
> I think it is much harder to join Debian than i.e. Google or
> Microsoft. It is ridiculous. I understand, the developers should have
> a good knowledge of unix systems and our ogranization but... that's
> going too far!

The reason why maintainers may be checked far more thoroughly is
because the average employee of Google or Microsoft can't make changes
to any piece of software company wide, nor do they vote on the
direction of the entire company. [It's also far easier to fire someone
than it is to remove a Developer.]

If you feel that the checks are unreasonable or to thorough, then feel
free to make specific recommendations for places where they should be
relaxed, ideally by helping with the NM process.


Don Armstrong

-- 
Clothes make the man. Naked people have little or no influence on
society.
 -- Mark Twain 

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: dpkg-shlibdeps and private libraries

[Francesco P. Lovergine]

On Wed, Sep 26, 2007 at 11:30:27AM +0200, Raphael Hertzog wrote:
> On the other hand, maybe I should just be less picky for shared objects
> without SONAME... I'm not sure about it.
> 

I would suggest that, there are a few programs out there which use
many internal use shlibs without a soname and a more complex
tree of dirs to pick up their stuff than a single directory. 

-- 
Francesco P. Lovergine


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

Re: semi-virtual packages?

[Bruce Sass]

On Tue September 25 2007 09:22:02 am Manoj Srivastava wrote:
> On Tue, 25 Sep 2007 02:36:24 -0600, Bruce Sass <[EMAIL PROTECTED]> said:
> > On Sun September 23 2007 03:08:59 pm Manoj Srivastava wrote:
> >> On Sun, 23 Sep 2007 14:26:29 -0600, Bruce Sass <[EMAIL PROTECTED]> said:

[I've cut a lot of duplication. If I cut something which doesn't get addressed 
below, feel free to bring it back.]

> > The scheme I described was under the written assumption there
> > are no such situations which would not already have a virtual
> > package.
>
> Ah.  That assumption turns out to be incorrect.

Haha. There is nothing wrong with the assumption. That is kinda like saying 
pylint is incorrect for spitting out errors when given a correct perl program. 
You ignored a sign which would have taken you down a different path, and now 
appear to be complaining because the path you ended up on took you to the wrong 
place---neither the sign or paths are incorrect, you just didn't pay attention 
and got lost.

> > Why would you think any of that scheme was applicable to the case
> > you were thinking of if it is a case in which there is no virtual
> > package?
>
> I am not sure how to answer that.  I assumed that the scheme
>  under discussion was going to be universal (or else it does not seem
> to be much good, really -- it would still leave files around that are
> not associated with anything).

I don't see why it would need to be universal, "one size" stuff often doesn't 
fit anyone very well and it is not like being universal is pervasive and this 
would stand out as a wart.

I think I see where you are getting confused though.

On the one hand you seem to be saying there are files that should be orphans 
(e.g.: /etc/kernel-img.conf), yet you criticize the scheme for not being 
universal. Why does not being universal "not seem to be much good" if you 
actually don't want universality because you know of files which shouldn't or 
can't be owned by a package?

You did the same sorta thing earlier. Your initial post seemed to be *faulting* 
a scheme to append paths to .list for not addressing "the case of a 
file shared by many packages but really owned by none", yet later on you state: 
"my use case merely says that we should be able to have a situation where we 
have a configuration file that does not belong to a package". Why should a 
scheme to add files generated by a package to its own .list need to 
address the case of files without packages that don't want to be owned?

The way I see it, from a logical pov, you can resolve the contradictions by 
giving up the premise of universality. Once you do that, the opt-in nature of 
the mechanism takes care of /etc/kernel-img.conf and like, trivially (nothing 
more trivial than doing nothing, eh).


> What use case _is_ "knowing what package a file belongs to" a part of?

"dpkg -S" (and any programs which use it) , cruft, idle curiosity, ...

> >> Now, I suppose you are only worried about files in /etc and sch;
> >> and not files under /var (no way to associate a lot of those files
> >> with the packages that contain the entities that created them).
> >
> > I wasn't worried at all about where the files created by Maintainer
> > scripts would reside, just that they were being created and there
> > was a virtual package which could be given a real presence to claim
> > ownership of them via info/.list.
>
> And in case there is no virtual package?

status quo

> > I had considered that files under /etc which are owned by a
> > semi-virtual package may need special handling, but could not think
> > of a case for which simply not-purging the previous version before
> > upgrading to the next wouldn't be an adequate solution. Since that
> > is how dpkg currently behaves I saw no need to bring it up. The
> > same would apply to files under (say) /usr/share/doc/ > package>.
>
> Ah. This is not anything I was talking to.

I knew that. It is just more info which may help resolve the problems.

> But I see the problem: if anything were to depend on a
> changed format of /etc/kernel-img.conf; there would be no pre-defined
> way to manage that. No matter what you purge, that file does not go
> away.

[ignoring that kernel-img.conf doesn't have to opt-in, so handling that 
situation could be as it is now]

Uhm, that is only a problem if a file is not owned by a package. This thread 
has been about a mechanism which could add such orphan files to a package so 
they can be listed, search for, removed, purged, or whatever else one (admin or 
program) does with that relationship.

Maybe this wasn't as clear as I thought:
A semi-virtual package is virtual to Debian and real on a user's system, so an 
admin always has the option of manually remove/purge-ing whatever they end up 
owning. During normal operation that sort of thing would be handled 
automatically as the packages Provide:-ing the semi-virtual ones get 
manipulated.

> What I would end u

Re: dpkg-shlibdeps and private libraries

[Michael Koch]

On Wed, Sep 26, 2007 at 11:56:39AM +0200, Francesco P. Lovergine wrote:
> On Wed, Sep 26, 2007 at 11:30:27AM +0200, Raphael Hertzog wrote:
> > On the other hand, maybe I should just be less picky for shared objects
> > without SONAME... I'm not sure about it.
> > 
> 
> I would suggest that, there are a few programs out there which use
> many internal use shlibs without a soname and a more complex
> tree of dirs to pick up their stuff than a single directory. 

Also all Java JNI libraries dont use SONAMEs. I guess these can be
problematic for new dpkg-shlibdeps too.


Cheers,
Michael


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

Re: Maintainer of package joystick may be missing

[Aníbal Monsalve Salazar]

On Tue, Sep 25, 2007 at 05:24:14PM +0200, laszlo kajan wrote:
>Please show me the way I can have my patch included in jscal.c of the
>joystick package. I believe it is useful and I immediately wanted to
>share it with others.

Please file a bug report (including the patch) against the joystick
package.

Aníbal Monsalve Salazar
-- 
http://v7w.com/anibal


signature.asc
Description: Digital signature

Re: dpkg-shlibdeps and private libraries

[Reinhard Tartler]

Raphael Hertzog <[EMAIL PROTECTED]> writes:

> libswui680lp.so has an RPATH set to $ORIGIN ... which is an environment
> variable apparently defined by the openoffice startup script/program. 
> This variable is not set a build time (and the code wasn't expecting
> variables at that place anyway).

I don't think $ORIGIN is an environment variable. AFAIK, the sun linker
is using that keyword to specify that you want to use an RPATH relative
to the location of the binary, which is pretty handy for
deploying/moving not packaged local software that is dynamically linked.

According to http://linuxreviews.org/man/ld.so/, the linux ld.so
supports the same feature. However, I did not find this piece in the
debian manpage, nor in the upstream documentation.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


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

Re: dpkg-shlibdeps and private libraries

[Mike Hommey]

On Wed, Sep 26, 2007 at 11:30:27AM +0200, Raphael Hertzog <[EMAIL PROTECTED]> 
wrote:
> Hello,
> 
> _rene_ reported me a failure with openoffice and the new dpkg-shlibdeps.
> 
> 
> Scanning 
> debian/openoffice.org-writer/usr/lib/openoffice/program/libswui680lp.so
> (for Depends field)
> dpkg-shlibdeps: failure: couldn't find library libsw680lp.so (note: only 
> packages with 'shlibs' files are looked into).
> 
> 
> The problem is that libswui680lp.so has libsw680lp.so in NEEDED and thus
> dpkg-shlibdeps will try to find that library. I made it a failure when I'm
> not able to find the library as dpkg-shlibdeps is supposed to behave like
> ld.so and try to use the same mechanism to find out where the lib is.
> 
> libswui680lp.so has an RPATH set to $ORIGIN ... which is an environment
> variable apparently defined by the openoffice startup script/program. 
> This variable is not set a build time (and the code wasn't expecting
> variables at that place anyway).

$ORIGIN in rpath is not an environment variable. It is used to have
directories relative to the current file in the rpath.

Typical use is something like $ORIGIN/../lib for software coming in a 
$DESTDIR/bin/ directory when the libraries are in $DESTDIR/lib/. It makes
software work wherever they are installed to.

$ORIGIN alone just tells the dynamic loader to also look in the directory
where the library/binary is for other libraries. That is, if a library in
/usr/lib/foo has a $ORIGIN rpath, ld.so will also look into /usr/lib/foo
for whatever this library needs.

Now, you may think such a thing would be useless, except that if you already
get your /usr/lib/foo/libfoo.so from an rpath (i.e. a binary linked to
libfoo.so having /usr/lib/foo in its rpath), this rpath is not used for 
libfoo.so's dependencies.

Mike


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

Re: Bug#443769: rt2500-source: Missing dependency on bzip2

[Edward Allcutt]

On Wed, 2007-09-26 at 00:26 -0500, Manoj Srivastava wrote:
> On Tue, 25 Sep 2007 22:10:52 -0400, Edward Allcutt <[EMAIL PROTECTED]> said: 
> 
> > Perhaps because the specific compiler needed depends on what the
> > current kernel was compiled with? I thought that was the reason
> > linux-headers depended on a specific compiler version.
> 
> Has that ever been the case?  I've had modules compiled with
>  a different gcc that I had when I compiled the kernel, and never had an
>  issue so far.
I could well be wrong but I thought there may be some problem with
compiling modules with gcc-4.1 when the kernel was compiled with
gcc-3.3.
-- 
Edward Allcutt <[EMAIL PROTECTED]>


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

Re: Building packages with exact binary matches

[Martin Uecker]

On Wed, Sep 26, 2007 at 12:25:02AM -0500, Manoj Srivastava wrote:
> On Wed, 26 Sep 2007 02:45:09 +0200, Martin Uecker <[EMAIL PROTECTED]> said: 

[...]

> >> > No. I would trust the binaries if there are *no mails* from other
> >> 
> >> Ah, security through blissful ignorance :) You do not actually trust
> >> the archive, or the developers, you trust the silence.
> 
> > I trust special relativity, because nobody has disproven it yet.  Do
> > you think this is blissfull ignorance, too?
> 
> Actually, partly. I am a quantum mechanic by training (I just
>  went sideways into computer because there was so little money in devoce
>  modeling). I like the special relativity because the math is sound; it
>  has predicted things we were not aware of before; and all kinds of
>  experimental data matches the theory -- except when you get to very
>  very small dimensions, but people are still working on that.

I am a mathematical phycicist by training: There are no known problems
with the SRT at the small scale. But you are right with your other point:
The math of a scientific theory has to be sound. But it has to be related
to reality, too. It is the last part we are talking about. 
 
> Just because you have _heard_ anyone diss special relativity
>  being the sole reason to believe in it is in the same ball park as
>  blissful, you know, ignorance.

It is not about hearsay. It is about finding an error in a predictation.
And I do not care *who* finds the error. Of course the predications
have actually be checked. So you are right with your argument, if nobody
actually does this, it would be ignorant to believe in a scientifc theory
for the sole reason that nobody complains. Similar, if nobody recompiles
the packages and checks for mismatches, then silence would in fact not
imply that things are ok. But I question your premise: I have no doubt
that some people would actually recompile packages and compare the
hash. Even if it is not done normally, somebody would do this if doubts
come up for some reason (e.g. some debian hosts are compromised again.).
This alone would actually be worth a lot.

[...]
 
> >> So, one someone lets the cat out of the bag, and we are not so
> >> blissful ,how can we check?
> >> 
> >> Simple, you say, compile the source!!  But, dear folks, the person
> >> who can compromise the archive, fake out the buildd's, add the
> >> archive signature -- can also hack the source.
> 
> > Is actually quite likely that somebody would notice if Debian
> > distributes trojaned source packages.
> 
> Really?  What was the last time anyone looked through libsepol
>  library code, eh? Or libselinux code? You do know dpkg and coreutils
>  are linked to that?

I would assume that there are people hacking on this code or at least
somebody fixes a bug in it occasionally. I know I looked at the
source code of libselinux once (but not closely). If in fact some
code is never looked at, then it is propably a really bad idea to
include it in critical packages.

> > All security work in the free software community works like this:
> > Somebody finds a flaw, he reports it, it gets fixed.  So you say this
> > can be DOSed by reporting a lot of false bug reports with a botnet?
> 
> No, the bug reporter goes and presents _evidence_ that can be
>  checked, and a patch, or a source of the problem.  No one jumps up and
>  down and issue CVE's just become someone says things are not ok.  And
>  no one makes a security ssue go away if bunches of people rise up and
>  say the code is juuust fiiine.

I never claimed that I believe random people just saying things
are ok or not ok. A binary mismatch is *evidence*. So if some
random people come up with such evidence, then I can check it myself.
 
> The difference is evidence.  If there is some merit to the
>  notion that a buildd is compromised, the solution is not bunches of
>  people building from potentially tainted sources and comparing
>  checksums. 

If know that the source code wich has hash 4457575757575 compiled
in the build environment with hash 4837373737 gives a package with hash
366336363, then it is actually *evidence* that something is seriously
wrong if you end up with a package with a different hash. 
 
> > Ironically, I think the current scheme where the binaries are signed
> > by some public key provides a false illusion of security.  Have you
> > actually thought about the meaning of this signature?  It just means
> > that the signee (and I do not even know who this actually is) believes
> > that this binary was not tampered with. Nothing more. And nobody else
> > has the possibilty to verify this.
> 
> If you do not know who the signatories of the archive key are, I
>  suggest you leanr, and see how the web of trust thing works for you,
>  and whether or not you can trust the guy doing the builds.
>
> Nothing is bullet proof. And no one can make anyone trust
>  anyone, including themselves.  Like all security

Re: dpkg-shlibdeps and private libraries

[Pierre Habouzit]

On Wed, Sep 26, 2007 at 10:36:18AM +, Reinhard Tartler wrote:
> Raphael Hertzog <[EMAIL PROTECTED]> writes:
> 
> > libswui680lp.so has an RPATH set to $ORIGIN ... which is an environment
> > variable apparently defined by the openoffice startup script/program. 
> > This variable is not set a build time (and the code wasn't expecting
> > variables at that place anyway).
> 
> I don't think $ORIGIN is an environment variable. AFAIK, the sun linker
> is using that keyword to specify that you want to use an RPATH relative
> to the location of the binary, which is pretty handy for
> deploying/moving not packaged local software that is dynamically linked.
> 
> According to http://linuxreviews.org/man/ld.so/, the linux ld.so
> supports the same feature. However, I did not find this piece in the
> debian manpage, nor in the upstream documentation.

  Yeah, as discussed on IRC, it's not documented, but the glibc ld.so
supports $ORIGIN and $PLATFORM at least since glibc 2.1. It also
supports $LIB which use is somehow unclear to me.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpcyBXN29vD0.pgp
Description: PGP signature

Re: AM status for Krystian Wlosek?

[Patrick Schoenfeld]

Don Armstrong wrote:
> The reason why maintainers may be checked far more thoroughly is
> because the average employee of Google or Microsoft can't make changes
> to any piece of software company wide, nor do they vote on the
> direction of the entire company. [It's also far easier to fire someone
> than it is to remove a Developer.]

Nor can they write emails with the branding of Debian as a project (and
eventually throw a bad light on it), nor can they use (and possibly
abuse) the infrastructure a dozen volunteers provide.

> If you feel that the checks are unreasonable or to thorough, then feel
> free to make specific recommendations for places where they should be
> relaxed, ideally by helping with the NM process.

There has been the decision on Developers light. Wouldn't that be
something for contributors like him? How far has this gotten in
technical sense?

Regards,

Patrick


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

Re: dpkg-shlibdeps and private libraries

[Nikita V. Youshchenko]

> libswui680lp.so has an RPATH set to $ORIGIN ... which is an environment
> variable apparently defined by the openoffice startup script/program

No.
$ORIGIN is dynamic linker feature, it is expanded to the directory where
executable resides.


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

Re: AM status for Krystian Wlosek?

[Kevin Mark]

On Wed, Sep 26, 2007 at 02:57:52AM -0700, Don Armstrong wrote:
> On Tue, 25 Sep 2007, Piotr Roszatycki wrote:
> > I suppose that everyone are busy today, so do I. I'm a little tired
> > with sponsoring his packages and I know he could to upload his
> > packages by his own.
> > 
> > I really don't undestand why new developers are checked so precisely.
> > I think it is much harder to join Debian than i.e. Google or
> > Microsoft. It is ridiculous. I understand, the developers should have
> > a good knowledge of unix systems and our ogranization but... that's
> > going too far!
> 
> The reason why maintainers may be checked far more thoroughly is
> because the average employee of Google or Microsoft can't make changes
> to any piece of software company wide, nor do they vote on the
> direction of the entire company. [It's also far easier to fire someone
> than it is to remove a Developer.]
> 
> If you feel that the checks are unreasonable or to thorough, then feel
> free to make specific recommendations for places where they should be
> relaxed, ideally by helping with the NM process.
> 

There is also the DM (Debian maintainer) vote that indicates that DD
seem not to mind allowing certain folks to upload certain packages. But
this has not been implemented yet. If that were implemented, the OP
would have want he wanted, at least that is what I would expect.
=K
-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal |mysite.verizon.net/kevin.mark/|
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
|  my keyserver: subkeys.pgp.net | my NPO: cfsg.org |
|join the new debian-community.org to help Debian!  |
|___  Unless I ask to be CCd, assume I am subscribed ___|


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

/usr/share/man/man8/ld.so.8.gz does not document the $ORIGIN, $PLATFORM and $LIB feature

[Reinhard Tartler]

Package: libc6
Version: 2.6.1-1+b1
Severity: wishlist
Tags: patch
File: /usr/share/man/man8/ld.so.8.gz

Raphael Hertzog noticed in [1] that the openoffice.org package is using
the undocumented $ORIGIN feature of the linux ld.so. See [2] for a
documentation of that feature.

[1] http://thread.gmane.org/gmane.linux.debian.devel.general/119923 
[2] http://linuxreviews.org/man/ld.so/

See the following irc query in #debian-devel:

12:42:05 < MadCoder> according to http://linuxreviews.org/man/ld.so/ it does
12:42:20 < MadCoder> (understands $ORIGIN)
12:43:04 < MadCoder> siretart: linux seems to support it
12:43:12 < MadCoder> it's just not in the man page
12:43:21 < MadCoder> let me look at ld code
12:43:21 < siretart> MadCoder: oh. then we should have that documented :)
12:43:31 < buxy> siretart: anyway, thanks for the info!
12:43:53 < MadCoder> siretart: yeah, stupid glibc maintainers
12:44:27 < _rene_> siretart: their goal is to get rid of LD_LIBRARY_PATH (which 
they currently use, too because some internally shipped libs like libxml, 
python, .. (sic!) don't have the RPATH)
12:44:53 < _rene_> siretart: and they indeed used $ORIGIN since ever.
12:45:08 < MadCoder> siretart: the code shows that $ORIGIN and $PLATFORM are 
supported 
12:45:27 < MadCoder> and $LIB
12:45:31 < MadCoder> not sure what they do
12:45:40 < _rene_> MadCoder: ah, so it's an ld feature? good to know...
12:45:58 < MadCoder> yeah I'm looking at glibc-2.6/elf/dl-load.c right now :)
12:46:02  * _rene_ didn't really look that deep into what $ORIGIN is for at OOo
12:46:23 < MadCoder> and it seems that you can put $ORIGIN $PLATFORM and $LIB 
in your rpath
12:46:38 < MadCoder> $ORIGIN is the absolute path the binary in question live
12:46:44 < MadCoder> $PLATFORM is your elf platform
12:46:58 < siretart> MadCoder: cool!
12:47:10 < MadCoder> I'm not sure to understand what $LIB is yet
12:49:39 < MadCoder> siretart: and it seems linux supports it at least since 
glibc 2.1
12:49:43 < MadCoder> so it's hardly new
12:50:15 < _rene_> .oO ( that also explains why OOos configure script 
explicitely checks for glibc being >= 2.1 )
12:51:02 < MadCoder> probably
12:51:29 < MadCoder> $LIB is defined it seems to a "safe path where to find 
libraries" when building the glibc
12:51:32 < MadCoder> it's odd
12:52:16 < MadCoder> though $ORIGIN and $PLATFORM are definitely nice features
12:52:33 < MadCoder> buxy: so you shouldn't have such a hard time to deal with 
it
12:53:00 < MadCoder> for a library path/to/libfoo.so $ORIGIN has to be replaced 
with path/to
12:54:25 < buxy> MadCoder: yeah, that's easy, however I think I'll ignore 
$PLATFORM and $LIB for now
12:54:31  * siretart goes to file a bug about documenting the $ORIGIN feature
12:55:14 < MadCoder> $LIB is likely to be never used


--
System Information: Debian Release: lenny/sid APT prefers testing APT
policy: (500, 'testing'), (50, 'unstable') Architecture: i386 (x86_64)

Kernel: Linux 2.6.20.4-gernoth-64bit (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libc6 depends on:
ii  libgcc1   1:4.2.1-4  GCC support library

libc6 recommends no packages.

-- no debconf information


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

Re: AM status for Krystian Wlosek?

[Piotr Roszatycki]

2007/9/26, Patrick Schoenfeld <[EMAIL PROTECTED]>:
> Don Armstrong wrote:
> > The reason why maintainers may be checked far more thoroughly is
> > because the average employee of Google or Microsoft can't make changes
> > to any piece of software company wide, nor do they vote on the
> > direction of the entire company. [It's also far easier to fire someone
> > than it is to remove a Developer.]
>
> Nor can they write emails with the branding of Debian as a project (and
> eventually throw a bad light on it), nor can they use (and possibly
> abuse) the infrastructure a dozen volunteers provide.

Why just new maintainers are checked so precisely? The old Debian
developers also can make a threat for Debian Project. It's logical,
that everybody should be checked, especially the old developers which
didn't be check so paranoid in the past.

I hope you see the absurdity in this procedure...

-- 
 .''`.Piotr Roszatycki
: :' :mailto:[EMAIL PROTECTED]
`. `' mailto:[EMAIL PROTECTED]
  `-


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

Re: AM status for Krystian Wlosek?

[Patrick Schoenfeld]

Piotr Roszatycki wrote:
> Why just new maintainers are checked so precisely? The old Debian

Because the old Debian developers should have been checked already.

> developers also can make a threat for Debian Project. It's logical,

Yeah, off course *can* they do this. But it is impossible to check
everyone who ever passed  a NM-test on a regular basis. You see that it
is already a *big* job to check new applicants which shouldn't be more
then eventual 100 per month, how should that be if you wanted to check
1000 developers on a regular basis? So all you *can* do is check it when
they apply to become a developer.

> that everybody should be checked, especially the old developers which
> didn't be check so paranoid in the past.

I got the point, but you cannot argue against a good practice in the
current by mistakes made in the past. I agree that it might be good to
checkout who were checked more loosely and check if this maintainer is
still active, if his contributions are of a good quality, etc. But I
think that this will not make things better, so it is eventually
pointless, while you can avoid a lot by checking new applicants proper.

> I hope you see the absurdity in this procedure...

Nope. Not that clear.

Regards,

Patrick


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

Bug#444115: general: network interface (eth0) gets undetected after restrat checked using ifconfig -a

[Antano Solar]

On Wednesday 26 September 2007 13:33:09 Josselin Mouette wrote:
> Le mercredi 26 septembre 2007 à 12:49 +0530, Antano Solar a écrit :
> > When the cmos battery is removed and power unplugged and the system
> > booted . I press f2(load defaults) in the cmos screen and the syetm boots
> > very slowly and detects my lan card. i.e ifconfig -a lists eth0.
> > But after this if I shut down the computer and start again or even
> > restart it , the network card is not detected . when the network card
> > goes undetected even if I boot into windows it remains undetected in
> > windows also. To make the netowrk card appear again I need to rerun the
> > procedure of removing the batters and unplugging power cable.
>
> If the problem appears in other operating systems, it sounds like it is
> caused by the hardware or the firmware - either the BIOS or the network
> card's.

The problem occurs in windows only if I do a shutdown in linux.
When i boot in windows and restart again or shutdown and start it is fine.
But the card disappears only after I boot into linux and shutdown 

Re: volatile.debian.org: Does Debian still support it?

[Martin Zobel-Helas]

Hi, 

On Wed Sep 26, 2007 at 00:20:10 +0200, Piotr Roszatycki wrote:
> You made a subtle mistake. You checked the source package for tzdata
> and the changes are really small. Then you checked the differences for
> libdatetime-timezone-perl package, but this source package is already
> compiled. You should check the difference between binary packages for
> tzdata.
> 
> The real source data for DateTime::TimeZone is the same as for tzdata
> source package. Then, the data is precompiled into Perl source. It
> makes a Debian source package.

Accepted now.

For the future: i would have been much easier, if you would have said:
be warned, the patch is huge, but if you don't look at the compiled
version of it, it is these number of lines...

Both of us would have had much less trouble.

Greetings
Martin

PS: It might take me a day or so to prepare a VUA, unless someone drafts
one for me.

-- 
[EMAIL PROTECTED] /root]# man real-life
No manual entry for real-life


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

Re: AM status for Krystian Wlosek?

[Don Armstrong]

On Wed, 26 Sep 2007, Piotr Roszatycki wrote:
> Why just new maintainers are checked so precisely? The old Debian
> developers also can make a threat for Debian Project. It's logical,
> that everybody should be checked, especially the old developers
> which didn't be check so paranoid in the past.

Those Developers who haven't gone through the NM process for the most
part have been checked by a far more rigorous procedure: they've
actually contributed and done the work. [Indeed, all developers are
continually being "rechecked" by this metric.]


Don Armstrong

-- 
Every gun that is made, every warship launched, every rocket fired
signifies in the final sense, a theft from those who hunger and are
not fed, those who are cold and are not clothed. This world in arms is
not spending money alone. It is spending the sweat of its laborers,
the genius of its scientists, the hopes of its children. This is not a
way of life at all in any true sense. Under the clouds of war, it is
humanity hanging on a cross of iron.
 -- Dwight Eisenhower, April 16, 1953

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: volatile.debian.org: Does Debian still support it?

[Piotr Roszatycki]

2007/9/26, Martin Zobel-Helas <[EMAIL PROTECTED]>:
> Accepted now.

Thank you very much.

> For the future: i would have been much easier, if you would have said:
> be warned, the patch is huge, but if you don't look at the compiled
> version of it, it is these number of lines...
>
> Both of us would have had much less trouble.

I think we could communicate better if you read the patch, not just
statistics about it. By the way, the patch itself does not contain the
real source data - the Olson database. I understand that it might be
not clear for someone who didn't use this library and know nothing
about complexity of timezones support in computing systems. It is
really hard piece of technology.

Thanks a lot and greetings.

-- 
 .''`.Piotr Roszatycki
: :' :mailto:[EMAIL PROTECTED]
`. `' mailto:[EMAIL PROTECTED]
  `-


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

Re: AM status for Krystian Wlosek?

[Patrick Schoenfeld]

Don Armstrong wrote:
> Those Developers who haven't gone through the NM process for the most
> part have been checked by a far more rigorous procedure: they've
> actually contributed and done the work. [Indeed, all developers are
> continually being "rechecked" by this metric.]

Eh.. i agree with most of you in this thread. But this argumentation
meets for almost everybody that really intends to become a DD. That does
say nothing about quality of their work, *if* they *will* do there
duties and if they *will* do it in a regular manner. You cannot argue
with something that cannot be evaluated, whereas you ask for evaluation
of other peoples contribution to Debian.

Regards,

Patrick


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

Re: volatile.debian.org: Does Debian still support it?

[Luk Claes]

Piotr Roszatycki wrote:

2007/9/26, Martin Zobel-Helas <[EMAIL PROTECTED]>:

Accepted now.


Thank you very much.


For the future: i would have been much easier, if you would have said:
be warned, the patch is huge, but if you don't look at the compiled
version of it, it is these number of lines...

Both of us would have had much less trouble.


I think we could communicate better if you read the patch, not just
statistics about it. By the way, the patch itself does not contain the
real source data - the Olson database. I understand that it might be
not clear for someone who didn't use this library and know nothing
about complexity of timezones support in computing systems. It is
really hard piece of technology.


It's only logical to NOT start reading a patch of more than 38K lines, 
so it's far easier if one would explain beforehand why it's that huge...


Cheers

Luk


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

Re: AM status for Krystian Wlosek?

[Don Armstrong]

On Wed, 26 Sep 2007, Patrick Schoenfeld wrote:
> Don Armstrong wrote:
> > Those Developers who haven't gone through the NM process for the most
> > part have been checked by a far more rigorous procedure: they've
> > actually contributed and done the work. [Indeed, all developers are
> > continually being "rechecked" by this metric.]
> 
> Eh.. i agree with most of you in this thread. But this argumentation
> meets for almost everybody that really intends to become a DD. That
> does say nothing about quality of their work, *if* they *will* do
> there duties and if they *will* do it in a regular manner. You
> cannot argue with something that cannot be evaluated, whereas you
> ask for evaluation of other peoples contribution to Debian.

Unfortunatly, I'm not quite sure I understand what you're saying.

The point of NM is to evaluate whether people are capable of
positively contributing to Debian and are going to do so. How this is
done exactly depends on the AM, but that's what the NM procedure does.

If you're arguing that we can't evaluate it with 100% certainty, I
agree. My goal as an AM is to do the best job I can.

If you're saying that it can't be evaluated at all, I disagree.
People's technical skill and previous contributions to Debian all
point to the likelihood of their future contribution.


Don Armstrong

-- 
My spelling ability, or rather the lack thereof, is one of the wonders
of the modern world.

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: volatile.debian.org: Does Debian still support it?

[Martin Zobel-Helas]

Hi, 

On Wed Sep 26, 2007 at 14:46:16 +0200, Piotr Roszatycki wrote:
> 2007/9/26, Martin Zobel-Helas <[EMAIL PROTECTED]>:
> > Accepted now.
> 
> Thank you very much.
> 
> > For the future: i would have been much easier, if you would have said:
> > be warned, the patch is huge, but if you don't look at the compiled
> > version of it, it is these number of lines...
> >
> > Both of us would have had much less trouble.
> 
> I think we could communicate better if you read the patch, not just
> statistics about it. By the way, the patch itself does not contain the
> real source data - the Olson database. I understand that it might be

will that cause dfsg problems?

> not clear for someone who didn't use this library and know nothing
> about complexity of timezones support in computing systems. It is
> really hard piece of technology.


-- 
[EMAIL PROTECTED] /root]# man real-life
No manual entry for real-life


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

Re: modified email address in debian/copyright file

[Jon Dowland]

On Tue, Sep 25, 2007 at 03:20:09PM -0500, Steve Greenland
wrote:
> I'd bet at least a small sum of money that "not beyond
> human recognition" and "impede machine parsing" are, at
> this point, non-intersecting sets. It's not even like they
> have to get it right on the first try -- just generate a
> bunch of differnt "unmunges", and try them. Or, more
> accurately, sell them to losers.

I personally agree. I don't bother munging my email address
at all anymore, as I don't think it helps a great deal in
the mid to long term, and it certainly detracts from the
usefulness of an address. However if an upstream author of a
package wishes to conceal their address, I think we should
honour that.


-- 
Jon Dowland


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

Re: AM status for Krystian Wlosek?

[Patrick Schoenfeld]

Don Armstrong schrieb:
> If you're saying that it can't be evaluated at all, I disagree.

No. Don't get me wrong, because that is /absolutely/ not what I wanted
to say. But you said (as far as I have understood) that those Debian
Developers that have /not/ gone through the NM process has proven that
they are good enough to be a DD, by actually (and /just/)"contributing
and doing the work".
I just wanted to point out, that this argumentation is weak, because you
say: "Hey, we need to check if a /new/ prospective developer really has
the intension that conform with the project, is technically skilled, has
actually done something for the project, etc. Yeah, we *really* need to
check it, because he did eventually do some work, but we have not
checked it for quality, for the kind of it has to be for Debian etc."
But OTOH you say: Hey, those Debian Developers that have /not/ been
checked have proven their qualification on their own, without anyone
ever checking this like you do with a NM-application.

Again: I really really think that the NM-Process is a good thing and i
really think it has to be done well, but then you cannot argue /this/
way for people who didn't need to go through this procedure. Hopefully,
I now found a way to tell you, what I meant.

Greets
Patrick


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

Re: AM status for Krystian Wlosek?

[Neil Williams]

On Wed, 26 Sep 2007 16:17:52 +0200
Patrick Schoenfeld <[EMAIL PROTECTED]> wrote:

> But OTOH you say: Hey, those Debian Developers that have /not/ been
> checked have proven their qualification on their own, without anyone
> ever checking this like you do with a NM-application.

The work of those DD's is constantly reviewed and checked by other DD's
- during mass bug filing, NMU's, bug triage etc.etc.
 
> Again: I really really think that the NM-Process is a good thing and i
> really think it has to be done well, but then you cannot argue /this/
> way for people who didn't need to go through this procedure. Hopefully,
> I now found a way to tell you, what I meant.

The procedure is constantly evolving - it was different 5 years ago to
how it was 2 years ago and how it is today. The only way to proceed is
to ensure that DD's who were accepted long ago are as up to date as new
DD's via mailing lists, standards versions and policy etc. Ongoing work
within Debian is a continuing re-evaluation of each active DD by other
DD's (and users). The process of learning does not stop upon acceptance,
it is an ongoing process of keeping up to date with changes across
Debian.

>From what little I've seen on debian-private, it is this ongoing
workload of staying up to date that makes the difference when an
inactive DD is thinking about leaving the project due to a lack of
time. DD's who were accepted many years ago are just as conscientious
as new DD's. Staying up to date after acceptance is a trickle process -
it is completely impractical to try to require ongoing examination of
such a process.

Old or new, if a DD makes a wrong call on a mailing list or in a bug
report, there's usually someone who will point it out.
:-)

That's how peer review works - not by continual external examination
but by ongoing review by those who are in the same situation.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpFDGzPntHFM.pgp
Description: PGP signature

Re: How to detect if inside a buildd chroot

[A Mennucc]

hi

It is all explained in
/usr/share/doc/sysv-rc/README.policy-rc.d

It seems that all you need to do is to create inside your chroot a
simple shell script  /usr/sbin/policy-rc.d that just does an 'exit 101'

for example with these two simple commands

$ echo -e '#!/bin/sh\nexit 101' > /usr/sbin/policy-rc.d
$ chmod  +x /usr/sbin/policy-rc.d

then invoke-rc.d becomes a no-op, it will not start or stop anything.

Unfortunately  the docs are a bit incomprehensible to me .. it seems you
can do much complex stuff than that, but I cant help. You may want to
look into the package policyrcd-script-zg2 : they know their act.


a.

Sebastian Dröge ha scritto:
> Am Dienstag, den 25.09.2007, 11:49 +0200 schrieb Jonas Meurer:
>> On 25/09/2007 Sebastian Dröge wrote:
>>> does somebody know about a solution to check whether one runs in a
>>> buildd chroot or not? I need this to prevent hal from starting in buildd
>>> chroots (via invoke-rc.d from postinst) as it breaks there because of
>>> several reasons, including no /sys mounted.
>> I tought that this should be handled by invoke-rc.d itself. The manpage
>> states that:
>>
>>  invoke-rc.d introduces the concept of a policy layer which is
>>  used to verify if an init script should be run or not, or if
>>  something else should be done instead. This layer has various
>>  uses, the most immediate ones being avoiding that package
>>  upgrades start daemons out-of-runlevel, and that a package
>>  starts or stops daemons while inside a chroot jail.
>>
>>
>> So my assumption was that invoke-rc.d detects if it's invoked inside a
>> chroot, and doesn't start the service in that case.
> 
> AFAIK this only happens if specified in some config file that daemons
> shouldn't be started. Whatever, although hal is invoked by invoke-rc.d
> it is started in the buildd chroots. :/
> 
> 

Re: AM status for Krystian Wlosek?

[Patrick Schoenfeld]

Neil Williams wrote:
> The work of those DD's is constantly reviewed and checked by other DD's
> - during mass bug filing, NMU's, bug triage etc.etc.

And the work of non-DD contributors isn't?
Come on, you know that I don't speak against how it is currently, but
against the /argumentation/. It is as it is: We need to trust in that
the people, who ever got DD, are trust worth. If we do not, then a
community and the good work like it is can't be kept up.

> as new DD's. Staying up to date after acceptance is a trickle process -
> it is completely impractical to try to require ongoing examination of
> such a process.

Full ACK. And *this* is a true argument, IMHO. It is just not realizable
to ongoing examine if DD stayed actual with current policies or their
interest.

> Old or new, if a DD makes a wrong call on a mailing list or in a bug
> report, there's usually someone who will point it out.
> :-)

Right. :-))

-Patrick


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

New adzapper package with Konqueror AdBlocK support

[Ludovic Drolez]

Hi !

I've uploaded a new adzapper package (20070317-2), which generates a file
compatible with Konqueror's adblock feature. Just import the file
/var/lib/adzapper/konqueror.txt in the adblock panel.

Feel free to send me any suggestion.

Cheers,

-- 
Ludovic Drolez.

http://www.palmopensource.com   - The Palm Open Source Portal
http://www.drolez.com  - Personal site - Linux, Zaurus and PalmOS stuff


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

Re: New adzapper package with Konqueror AdBlocK support

[Peter Samuelson]

[Ludovic Drolez]
> Just import the file /var/lib/adzapper/konqueror.txt in the adblock
> panel.
> 
> Feel free to send me any suggestion.

Uh, wouldn't that belong in /usr/share?
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/

Bug#444189: ITP: libtap-parser-perl -- Perl module for parsing TAP output

[gregor herrmann]

Package: wnpp
Severity: wishlist
Owner: gregor herrmann <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: libtap-parser-perl
  Version : 0.54
  Upstream Author : Curtis "Ovid" Poe
* URL : http://search.cpan.org/dist/TAP-Parser/
* License : Perl (GPL/Artistic)
  Programming Lang: Perl
  Description : Perl module for parsing TAP output

 TAP::Parser is designed to produce a proper parse of TAP output.
 .
 TAP, the Test Anything Protocol, is Perl's simple text-based interface
 between testing modules such as Test::More and the test harness
 Test::Harness.

libtap-parser-perl is needed by the new release of libmail-box-perl
(cf. #442912).

- -- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'experimental'), (500, 'testing'), (500, 
'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.22.200709061812
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG+oyAOzKYnQDzz+QRAqHcAKCdi/rYOL7YROIRsbM+O2Ts+7LqnwCgv5ai
vsY5+VB7aN6t4P9+ijY6SNs=
=F+R4
-END PGP SIGNATURE-



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

Re: volatile.debian.org: Does Debian still support it?

[Piotr Roszatycki]

2007/9/26, Martin Zobel-Helas <[EMAIL PROTECTED]>:
> > I think we could communicate better if you read the patch, not just
> > statistics about it. By the way, the patch itself does not contain the
> > real source data - the Olson database. I understand that it might be
>
> will that cause dfsg problems?

Not at all. The packages was built with pbuilder. It still is not
fully understandable, so I'll try explain:

olson db = tzdata source package upstream

olson db + time zone compiler (zic) = tzdata binary package

olson db + parse_olsen translator = DateTime::TimeZone official CPAN
source package = Debian source package

Debian source package + pbuilder = Debian binary package

The Debian source package is based on official CPAN package and
contains already parsed database which is provided by original author.

I did the same work as upstream author, so I called parse_olsen
translator and I've got the path for new Debian source package.

Of course it builds our Debian binary package correctly.

-- 
 .''`.Piotr Roszatycki
: :' :mailto:[EMAIL PROTECTED]
`. `' mailto:[EMAIL PROTECTED]
  `-


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

Re: AM status for Krystian Wlosek?

[Don Armstrong]

On Wed, 26 Sep 2007, Patrick Schoenfeld wrote:
> Neil Williams wrote:
> > The work of those DD's is constantly reviewed and checked by other DD's
> > - during mass bug filing, NMU's, bug triage etc.etc.
> 
> And the work of non-DD contributors isn't?

Not in the same way, no. Most non-DD contributions that actually
affect the archive always go through a DD gatekeeper. At the end of
the day, that DD is the person who is actually responsible.

> We need to trust in that the people, who ever got DD, are trust
> worth. If we do not, then a community and the good work like it is
> can't be kept up.

That's actually backwards from what I've said. My argument is not that
DDs should be trusted, but that DDs are in a position where they can
abuse that trust. The longer they've been a DD (and the more work they
do) the less and less likely they are to do so (at least
intentionally).

> It is just not realizable to ongoing examine if DD stayed actual
> with current policies or their interest.

It's easier to tell[1] which developers are current with what is
happening in Debian (assuming they're active) than it is to tell
whether an NM applicant is.


Don Armstrong

1: by looking at the packages they upload, the bugs that they have
open, and the bugs which have been filed
-- 
Grimble left his mother in the food store and went to the launderette
and watched the clothes go round. It was a bit like colour television
only with less plot.
 -- Clement Freud _Grimble_

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: AM status for Krystian Wlosek?

[Patrick Schoenfeld]

Don Armstrong wrote:

That's actually backwards from what I've said. My argument is not that
DDs should be trusted, but that DDs are in a position where they can


Well, but actually it does not work without a level of trust. And as a 
community that tries to build up a good, reliable and universal 
operating system, there cannot be trust in anyone.



abuse that trust. The longer they've been a DD (and the more work they
do) the less and less likely they are to do so (at least
intentionally).


If you intended to say that by the first mail, then I agree and there is 
no need to argue anymore. :)



It's easier to tell[1] which developers are current with what is
happening in Debian (assuming they're active) than it is to tell
whether an NM applicant is.


Hm. Considered that all "tools" (including BTS, PTS and QA pages) track 
the work of non-DD contributors.. hmm.. probably, probably not.


Greets,
Patrick


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

Bug#444199: ITP: freecol -- freecol: an open version of Colonization

[Vincent Fourmond]

Package: wnpp
Severity: wishlist
Owner: Vincent Fourmond <[EMAIL PROTECTED]>

* Package name: freecol
  Version : 0.7.2
  Upstream Author : [EMAIL PROTECTED]
* URL : http://www.freecol.org/
* License : GPL
  Programming Lang: java
  Description : freecol: an open version of Colonization

freecol is a game in the spirit of Civilization but taking place in a
colonial background. Colonize a new world, build towns, trade or fight
with natives and other European civilizations, trade with your
homeland until you're ready to fight for your independance !

Java game, so probably will end up in contrib.

License is GPL, I'm not sure though whether all art work is free.

Great game (though buggy sometimes...) !

  Vincent Fourmond


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.22-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) (ignored: LC_ALL set to 
en_GB)
Shell: /bin/sh linked to /bin/dash



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

Re: How to detect if inside a buildd chroot

[Roger Leigh]

A Mennucc <[EMAIL PROTECTED]> writes:

> It is all explained in
> /usr/share/doc/sysv-rc/README.policy-rc.d
>
> It seems that all you need to do is to create inside your chroot a
> simple shell script  /usr/sbin/policy-rc.d that just does an 'exit 101'

I would very much prefer that all packages worked correctly inside a
chroot without any admin intervention.  If it's not appropriate to run
inside a chroot, then the init script should IMHO detect that and not
start/restart/stop the service.


Regards,
Roger

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


pgptLwotFfjzL.pgp
Description: PGP signature

Re: How to detect if inside a buildd chroot

[Mike Hommey]

On Wed, Sep 26, 2007 at 09:31:36PM +0100, Roger Leigh wrote:
> A Mennucc <[EMAIL PROTECTED]> writes:
> 
> > It is all explained in
> > /usr/share/doc/sysv-rc/README.policy-rc.d
> >
> > It seems that all you need to do is to create inside your chroot a
> > simple shell script  /usr/sbin/policy-rc.d that just does an 'exit 101'
> 
> I would very much prefer that all packages worked correctly inside a
> chroot without any admin intervention.  If it's not appropriate to run
> inside a chroot, then the init script should IMHO detect that and not
> start/restart/stop the service.

The fact is, not all chroot are buildd chroots, and many chroots
actually do run services...

Mike


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

Re: How to detect if inside a buildd chroot

[Tyler MacDonald]

Mike Hommey <[EMAIL PROTECTED]> wrote:
> > chroot without any admin intervention.  If it's not appropriate to run
> > inside a chroot, then the init script should IMHO detect that and not
> > start/restart/stop the service.
> 
> The fact is, not all chroot are buildd chroots, and many chroots
> actually do run services...

  Yep... but I still find it a bit annoying that I have to override binaries
like start-stop-daemon or invoke-rc.d when building a chroot. I wish there
was a way to just set a flag that means "dpkg, don't start/stop any
services!"... instead I end up doing stuff like:


invoke="/usr/sbin/invoke-rc.d"

cdebootstrap -f "standard" "$SUITE" "$TARGET" "$MIRROR"
mount -t proc proc "$TARGET/proc"
$chroot "$TARGET" $aptitude update || throw
$chroot "$TARGET" /usr/sbin/dpkg-divert \
  --add --rename --divert $invoke.orig $invoke || throw
ln -sf /bin/true "$TARGET/$invoke"

 [bootstrap code...]

/bin/rm -f "$TARGET/$invoke"
$chroot "$TARGET" /usr/sbin/dpkg-divert \
  --remove --rename --divert $invoke.orig $invoke || throw
umount "$TARGET/proc"


- Tyler


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

Re: How to detect if inside a buildd chroot

[Lars Wirzenius]

ke, 2007-09-26 kello 13:49 -0700, Tyler MacDonald kirjoitti:
>   Yep... but I still find it a bit annoying that I have to override
> binaries
> like start-stop-daemon or invoke-rc.d when building a chroot. I wish there
> was a way to just set a flag that means "dpkg, don't start/stop any
> services!"... instead I end up doing stuff like:

That shouldn't be necessary anymore. The policy-rc.d trick that has been
mentioned in this thread a couple of times should work fine. Here's the
code in piuparts which does it:

full_name = os.path.join(self.name, "usr/sbin/policy-rc.d")
create_file(full_name, "#!/bin/sh\nexit 101\n")
os.chmod(full_name, 0777)

-- 
Copyrights, patents, trademarks: not property, not rights, but
priviledges!


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

Bug#444221: ITP: python-pysizer -- memory profiiler for Python

[Thomas Viehmann]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org
Owner: Thomas Viehmann <[EMAIL PROTECTED]>

* Package name: python-pysizer
  Version : 0.1.1
  Upstream Authors: Nick Smallbone
* URL : http://pysizer.8325.org/
* License : BSD-like
  Programming Lang: Python, basically
  Description : memory profiler for Python
 PySizer lets you analyse the memory usage of your Python programs and
 makes data such as memory usage by objects of a certain type readily
 available.
 This package contains the parts of PySizer written in Python. There
 is an optional patch to python itself to collect more information, but
 that has not been compiled into the stock Debian python binaries.

As always, suggestions (better description, etc.) are very welcome.
There might be room for improvement.
python-pysizer will likely be comaintained by the python-modules team.

I'm not yet sure what to do about the patch to the python interpreter,
PySizer is very useful even without it, though.

PySizer has an advantage over Heapy (cp. ITP #409740) in that the pure
python parts are useful by themselves. (Heapy presently segfaults on
amd64 and I have not found a fix yet).

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/




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

ITH: libxmlrpc-c

[sean finney]

hey folks,

this package is getting waaay out of date.  as the current maintainer has 
stated in the BR (which has been open for over 2 years), he doesn't really 
have the time/interest in continuing to maintain it and has offerred to give 
it up to those in the BR, but nothing has happened.  

also, gutsy has moved on ahead and packaged the latest version.

personally, i have a small amount of interest in seeing this package updated, 
as i would like the xmlrpc support in rtorrent which is blocked by this.   
so, unless there are any serious objections i will just grab the version from 
gutsy if that seems to work, and follow their lead.

i don't believe that the updating will cause too much problems wrt 
transitions, since there's only one reverse depends (openser)  for the 
package currently in unstable afaict.

if there's anyone who's more interested in permanently maintaining this 
package feel free to step up.



sean


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

Re: New adzapper package with Konqueror AdBlocK support

[Michael Biebl]

Peter Samuelson schrieb:
> [Ludovic Drolez]
>> Just import the file /var/lib/adzapper/konqueror.txt in the adblock
>> panel.
>>
>> Feel free to send me any suggestion.
> 
> Uh, wouldn't that belong in /usr/share?

If it's downloaded from the internet or autogenerated in some way then
I'd say /var/lib/ is correct. For static data I agree, /usr/share/ would
be more appropriate (*)

Cheers,
Michael

(*) I think adzapper does the former (without checking the package more
deeply).
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: modified email address in debian/copyright file

[Ben Finney]

Jon Dowland <[EMAIL PROTECTED]> writes:

> However if an upstream author of a package wishes to conceal their
> address, I think we should honour that.

This is at odds with "always have correct contact information for the
copyright holder at the time of packaging", which I think Debian
should strive to achieve for the sake of its users.

The only way to honour "conceal their address" at the same time as the
above is to not distribute the package at all. I don't think that's a
good solution.

-- 
 \"Computers are useless. They can only give you answers."  -- |
  `\ Pablo Picasso |
_o__)  |
Ben Finney


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

Packaging a library that requires cross-compiled code

[David Anderson]

[I've only just subscribed, please forgive me if I got something horribly wrong]

Hello,

I was redirected here for advice from #debian-mentors, following a
packaging question I have. The short summary: I'd like to package a
library which requires a tiny blob of cross-compiled code to run, and
don't know how to achieve this in a debian-friendly way.

Context: the code I'd like to package is a Python package and
associated Python scripts, that enable low-level communication with a
Lego Mindstorms NXT brick over USB. This is the newer Lego Mindstorms
brick, which to the best of my knowledge currently has no supporting
libraries available in Debian (support is available for the older, but
completely different RCX model).

My module enables low-level communication at two levels: a wrapper
around python-pyusb to facilitate scanning for a brick and accessing
it, and an implementation of the simple command protocol used by the
onboard bootloader. This is a library aimed squarely at developers who
want to replace Lego's firmware with something else (in my case, an
open source high kernel I'm working on).

One of the tools provided is called `fwflash`, which takes a binary
firmware image and writes it to the brick's flash chip via the
bootloader. One of the steps in the flashing procedure is to upload a
tiny (136 bytes) driver for the flash controller into the brick's ram,
to oversee the actual flashing process. The brick cannot be flashed
without the help of this driver. (for those who care, the flash memory
is single-plane, which cannot be simultaneously read and written,
which requires the use of an in-ram driver for the few instructions
that actually perform the write. Attempting to drive the entire
process through the bootloader crashes the brick.) And, of course, as
the brick is based on an arm7 architecture, this flash driver needs to
be cross-compiled. From an architectural POV, the flash driver is an
internal implementation detail, the end user of the library doesn't
care about the technicalities that forced it into existence.

Problem: the flashing tool is unusable without this tiny piece of
firmware, but that code can only be compiled with a properly built
arm7tdmi cross-compiling gcc, which is not available in Debian. I
built my own from gnuarm.com.

Therefore, question: how should I get from this situation to having a
working .deb (including the cross-compiled driver), while at the same
time playing nicely with Debian packaging policies?

Possible solutions that we came up with on #debian-mentors:

1) Ship a built copy of the code in the package's .diff.gz, and DTRT
at package creation time to move the .bin from debian/ to the right
place in the staging tree. The source code for the .bin is in
.orig.tar.gz, under a free license. Anyone is free to modify or
rebuild the .bin, provided they obtain an arm7 cross-compiler by
non-debian means (instructions provided). People who just want to
rebuild the package can do so, without caring that there is
cross-compiled code involved.

Pro: dead simple, the packaging problem goes away. Con: means shipping
a binary blob in the source distribution, which appears to be frowned
upon, regardless of whether the source is also freely available in the
source distribution.

2) Package an arm7 cross-compiling gcc with just the right set of
options, integrate that with the packaging tools, and then package
with a Build-Depends on the cross-compiler.

Pro: feels like the Right Way, in a perfect world. Cons: opens the
floodgates of packaging cross-compilers, likely requires
additions/modifications to packaging tools, and takes way more time
than I'm personally ready to put into packaging my code.

3) Somehow make the packaging tools properly cross-compile the .bin
without having a cross-compiler package around. This was briefly
suggested on #debian-mentors, but I have no idea how this would be
implemented.

Pros: less time involved than 2), would make the package
self-contained. Cons: building a cross-compiler in the packaging
process just to build a 136 byte binary blob feels like killing a flea
with a bazooka, and makes building the package much, much longer than
it should be, given the amount of code and logic it actually carries.

4) Give up and stay away from the Debian main repositories, just put
the package up on a private package repository.

Pro: trivial solution. Cons: I'd like to do things right rather than
cobbling something together.

There you have it. Ideas, thoughts?

- Dave


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

Re: Packaging a library that requires cross-compiled code

[Paul Wise]

On 9/27/07, David Anderson <[EMAIL PROTECTED]> wrote:

> Possible solutions that we came up with on #debian-mentors:

The other possibility that was mentioned was to split the firmware out
into a separate source package that produces an Arch: all package and
then ensure that it is built on arm.

People in the channel had no idea if this would work though :)

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Packaging a library that requires cross-compiled code

[Bernd Zeimetz]

> 4) Give up and stay away from the Debian main repositories, just put
> the package up on a private package repository.

Please don't choose this way to solve the problem. Lego Mindstorms are
used a lot for education, including universities, as it is just very
easy to build objects with Lego bricks, so you have more time to think
about the code then about how to handle metal or other raw material.

Unfortunately I still have no clue about cross-compiling, but please let
me know if you need any help with the python parts. Feel free to join
#debian-python on OFTC, all questions regarding python apps/modules are
welcome there

Imho one very fast way to solve the problem would be to package all the
python tools, including fwflash - but without the actual firmware blob.
Instead you ask the people to download the file or let the tool handle
this automatically - at least this would make sure people are able to
use your tools with mindstorms while you have enough time to figure out
how to ship the precompiled firmware in a debian package. For example
you could build the firmware package on arm only and let your tools
download and extract the package.


Hope I could give you some useful hints,

Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: Packaging a library that requires cross-compiled code

[Steve Langasek]

On Thu, Sep 27, 2007 at 11:11:40AM +1000, Paul Wise wrote:
> On 9/27/07, David Anderson <[EMAIL PROTECTED]> wrote:

> > Possible solutions that we came up with on #debian-mentors:

> The other possibility that was mentioned was to split the firmware out
> into a separate source package that produces an Arch: all package and
> then ensure that it is built on arm.

> People in the channel had no idea if this would work though :)

The only (good) way to ensure the arch: all package is built on arm is to
always do the sourceful upload of the package from arm.

(Otherwise, you'd be building the arch: all package from the binary-arch
rule on arm only; this would work, but cause brain-twistiness wrt the
separation between arch: all and arch: any.)

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


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

Re: Packaging a library that requires cross-compiled code

[Roberto C . Sánchez]

On Wed, Sep 26, 2007 at 06:38:02PM -0700, Steve Langasek wrote:
> On Thu, Sep 27, 2007 at 11:11:40AM +1000, Paul Wise wrote:
> > On 9/27/07, David Anderson <[EMAIL PROTECTED]> wrote:
> 
> > > Possible solutions that we came up with on #debian-mentors:
> 
> > The other possibility that was mentioned was to split the firmware out
> > into a separate source package that produces an Arch: all package and
> > then ensure that it is built on arm.
> 
> > People in the channel had no idea if this would work though :)
> 
> The only (good) way to ensure the arch: all package is built on arm is to
> always do the sourceful upload of the package from arm.
> 
> (Otherwise, you'd be building the arch: all package from the binary-arch
> rule on arm only; this would work, but cause brain-twistiness wrt the
> separation between arch: all and arch: any.)
> 
I think that perhaps Paul meant to say an arch any package.  If the code
must always be compiled for a particular flavor of ARM processor,
regardless of the host architecture of the machine which will be
controlling the Lego, then it should be possible to build it is arch
any, which would not get autobuilt anyways.  Then, as long as the
uploader (maintainer or NMU) buils on ARM, everything should be OK.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: Packaging a library that requires cross-compiled code

[Roberto C . Sánchez]

On Wed, Sep 26, 2007 at 09:43:17PM -0400, Roberto C. Sánchez wrote:
> > 
> I think that perhaps Paul meant to say an arch any package.  If the code
> must always be compiled for a particular flavor of ARM processor,
> regardless of the host architecture of the machine which will be
> controlling the Lego, then it should be possible to build it is arch
> any, which would not get autobuilt anyways.  Then, as long as the
> uploader (maintainer or NMU) buils on ARM, everything should be OK.
> 
Please completely disregard what I said.  I have got it completely
confused.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: Packaging a library that requires cross-compiled code

[Paul Wise]

On 9/27/07, Steve Langasek <[EMAIL PROTECTED]> wrote:

> > The other possibility that was mentioned was to split the firmware out
> > into a separate source package that produces an Arch: all package and
> > then ensure that it is built on arm.
>
> > People in the channel had no idea if this would work though :)
>
> The only (good) way to ensure the arch: all package is built on arm is to
> always do the sourceful upload of the package from arm.

Right.

The issue would be whether or not the arm/armel gcc binaries support
the right target characteristics:

 the target system is an arm7, with no MMU, so no linux for starters
 I suspect that if debian supports an arm architecture,
it'd be arm9 or higher
 -mcpu=arm7?
 arm7tdmi
* danderson digs out the arm-elf-gcc configuration
 arm-elf, arm7 cpu, thumb interworking support, software
floating point emulation. That's the combination I need.

Any emdebian/other folks know if this is an option?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Changing name of source package

[Steve Langasek]

On Tue, Sep 25, 2007 at 05:04:47PM +0200, Uwe Steinmann wrote:

> I just want to double check that changing the name of a source package
> can be done as I anticipate it.
> I would like to change the name of the source package php4-ps into
> php-ps. php4-ps creates two binary packages php4-ps and php5-ps.
> The new source package php-ps will only create php5-ps because
> php4 will be dropped anyway in the near future.

> From what I have read so far, it should be sufficient to upload the
> new source package which takes over the binary package php5-ps.
> Is it required to wait for a new upstream version or can I simply
> push up the debian version from 1.3.5-1 to 1.3.5-2?

The only other thing you need to worry about is filing a bug report against
ftp.debian.org to get the old php4-ps source package removed, since this
won't happen automatically.

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


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

Re: Packaging a library that requires cross-compiled code

[Jon Leonard]

On Thu, Sep 27, 2007 at 02:59:16AM +0200, David Anderson wrote:
[how best to package a stub for which the cross-compiler isn't in Debian]

[possible solution 1]
> 1) Ship a built copy of the code in the package's .diff.gz, and DTRT
> at package creation time to move the .bin from debian/ to the right
> place in the staging tree. The source code for the .bin is in
> .orig.tar.gz, under a free license. Anyone is free to modify or
> rebuild the .bin, provided they obtain an arm7 cross-compiler by
> non-debian means (instructions provided). People who just want to
> rebuild the package can do so, without caring that there is
> cross-compiled code involved.
> 
> Pro: dead simple, the packaging problem goes away. Con: means shipping
> a binary blob in the source distribution, which appears to be frowned
> upon, regardless of whether the source is also freely available in the
> source distribution.

A slight variant on this would be to ship assembly source (the output of
gcc -S) instead of a binary blob, and cross-assemble that.  If the stub
is 136 bytes long, assembly isn't too bad, and it's a step away from a
binary blob.  This presumes that the cross-tools in Debian can correctly
assemble arm7, which I haven't verified.

But the binary-blob variant is probably simplest, and I'd recommend going
with that to get packaging done and the package in Debian.  Alternately,
check for the compiler, and use it if it's installed.  (And fall back to
the binary blob if it's not there.)

Jon Leonard


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

Teaching assembly (Re: Bug#443370: ITP: asmutils -- coreutils replacement written in i386 assembler)

[Oleg Verych]

23-09-2007, Bernd Zeimetz:
>

Some more context for compilers:


>> I can confirm that it is not faster since I tested it once, I think 'wc' it 
>> was. And it is definitely not portable to other platforms either :-) 
>> Nevertheless the package brings with it some spirit that is good to have: 
>> love to assembly as a language. Maybe there are applications of this package 
>> in the embedded world or for some "UNIX on a floppy disk"-kind of 
>> distributions. I do not care for the moment. The educational aspect of this 
>> package is what makes me want it for our distribution.
>
> For the educational aspect it would now nice to have this package at
> least in mips assembly, too, which is at least at my university used to
> teach assembly. It would also allow to compare the same implementation
> for different architectures.

What problems are with 

`gcc -S --verbose-asm`
`objdump -S`?

Even more interesting would be (i guess), to see actual output of various
optimizations stages in gcc. And this is more interesting work for
students. Analyzing, what is done -- is part of any scientific
publication and academic work. Education (for me) is developed skill of
analyzing with comprehensive knowledge of history of the subject.
That's how one can deal with data coming right now.

So, why waste time with obsolete plain asm programming??? The term "asm
programming" means "teaching asm in *vacuum*". And this is wrong.

Problem is (from what i've seen), that GCC developers don't like to waste
much time looking in asm. Asm is a text output of GCC for them[0]. Kernel
developers like only C, and not many of them like to spend time looking
in actual asm, because they think, that -O2 good, -Os is better for
Embedded hype[1][2].

[0] http://article.gmane.org/gmane.comp.gcc.devel/91370
[1] http://mid.gmane.org/[EMAIL PROTECTED]
[2] http://mid.gmane.org/[EMAIL PROTECTED]
(care to look a little more in threads)
_


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

Re: RFC: "autobuilder" pseudo-package

[Goswin von Brederlow]

Holger Levsen <[EMAIL PROTECTED]> writes:

> Hi,
>
> On Tuesday 25 September 2007 12:25, Simon Richter wrote:
>> inspired by the "how to detect if inside a buildd chroot" thread: would
>> it make sense to have an (empty) package "autobuilder" that all packages
>> that are not supposed to be installed on autobuilders (daemons, packages
>> requiring interactive configuration, ...) can conflict against?
>
> Interactive configuration must be done via debconf by now.
>
> And not wanting to start daemon can have other reasons than autobuilders, eg. 
> eg. chroots, fai's nfsroot, piuparts... so "autobuilder" is not a good name.
>
>
> regards,
>   Holger

I also would not make it empty but have it come with a policy-rc.d
script that returns 101. That way it nicely disables all daemons for
you. Also you could have some debconf configuration to set the
hostname and prompts to reflect it is a chroot.

MfG
Goswin


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

Re: modified email address in debian/copyright file

[Lars Wirzenius]

to, 2007-09-27 kello 10:21 +1000, Ben Finney kirjoitti:
> Jon Dowland <[EMAIL PROTECTED]> writes:
> 
> > However if an upstream author of a package wishes to conceal their
> > address, I think we should honour that.
> 
> This is at odds with "always have correct contact information for the
> copyright holder at the time of packaging", which I think Debian
> should strive to achieve for the sake of its users.

I'm afraid I have to disagree with that. Obfuscation which can easily be
reversed by a human, but not so easily by a computer, does not render
contact information incorrect. If I write my e-mail address as follows,
it's still correct: "My full name is Lars Ivar Wirzenius, and you can
send me e-mail by taking my initials and putting them in front of the at
sign and iki.fi after it."

Mind you, I don't like obfuscation, and I think it's a nuisance myself,
but we shouldn't violate people's wish to try to avoid spam by
publishing their addresses in un-obfuscated form. That only makes people
angry at us for little or no benefit, since there are no situations when
we want to automatically send e-mails to upstream developers anyway.

> The only way to honour "conceal their address" at the same time as the
> above is to not distribute the package at all. I don't think that's a
> good solution.

I don't think there is any requirement to have any upstream contact
information whatsoever in order to be able to distribute a package.

-- 
Close your mind to stress and pain, hack till you're no longer sane.


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

[VAC] a few days (I hope). Bretagne, France.

[Santiago José Ruano Rincón]

Hi,

Today, I'll travel to France to pursuit my Master studies in 
human-computer interaction at the ENST-Bretagne and Université de 
Bretagne Sud.


grep has a RC bug right now [1], any help to solve it will be appreciated. 
Just contact anibal.


[1] http://bugs.debian.org/181378

I hope I'll be able to continue my work on debian as soon as a I get some 
order and an INET connection there.


Best regards,

--
Santiago Ruano RincGrupo GNU/Linux Universidad del Cauca

"I know but one freedom, and that is the freedom of the mind."

--Antoine de Saint-Exupery

Re: modified email address in debian/copyright file

[Ben Finney]

Lars Wirzenius <[EMAIL PROTECTED]> writes:

> I don't think there is any requirement to have any upstream contact
> information whatsoever in order to be able to distribute a package.

This seems to be the point of disagreement. I think this should be
required, in order that Debian users can have more confidence [0] in
the copyright status of works in Debian.


[0] not absolute confidence, of course, which is impossible; but
greater confidence than would be the case in the absence of valid
copyright holder contact details.

-- 
 \"Program testing can be a very effective way to show the |
  `\presence of bugs, but is hopelessly inadequate for showing |
_o__)  their absence."  -- Edsger Dijkstra |
Ben Finney


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