Re: Adding an application to the menu

[Andrew Donnellan]

You might find more help on debian-mentors.

On 6/1/06, Indraveni <[EMAIL PROTECTED]> wrote:

Hi,

  I am creating a deb package which will install some type of converter into
the system and it is working fine. NOW..I want to add an entry into the
Applcaitions/Office menu of my debian system for that particular application
which is installed from my deb package. so that when I click on that menu
item it will start the converter.

 What do I need to do for this??

 HELP PLEASE

 Regards
 Indraveni


 
 Yahoo! India Answers: Share what you know. Learn something new Click here
 Send free SMS to your Friends on Mobile from your Yahoo! Messenger Download
now



--
Andrew Donnellan
http://andrewdonnellan.com
http://ajdlinux.blogspot.com
Jabber - [EMAIL PROTECTED]
GPG - hkp://subkeys.pgp.net 0x5D4C0C58
---
Member of Linux Australia - http://linux.org.au
Debian user - http://debian.org
Get free rewards - http://ezyrewards.com/?id=23484
OpenNIC user - http://www.opennic.unrated.net


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

Adding an application to the menu

[Indraveni]

Hi,   I am creating a deb package which will install some type of converter into the system and it is working fine. NOW..I want to add an entry into the Applcaitions/Office menu of my debian system for that particular application which is installed from my deb package. so that when I click on that menu item it will start the converter.  What do I need to do for this??  HELP PLEASE  Regards Indraveni 
	

	
		 
 Yahoo! India Answers: Share what you know. Learn something new Click here 
Send free SMS to your Friends on Mobile from your Yahoo! Messenger Download now

Re: Please revoke your signatures from Martin Kraff's keys

[Mike Hommey]

On Thu, Jun 01, 2006 at 12:41:52AM +0200, Javier Fernández-Sanguino Peña 
<[EMAIL PROTECTED]> wrote:
> On Mon, May 29, 2006 at 02:48:33PM +0200, Wouter Verhelst wrote:
> > Then there's the issue of tracing who did an actual upload into the real
> > world. A name on a GPG key is not, by any means, an effective way to do
> > that, since it does not contain enough information to get out the black
> > helicopters. Case in point:
> (...)
> 
> Useless case, you seem to believe that police officers can only trace and
> obtain information from people through Google !
> 
> I do not know how many cases related to "digital crimes" have you been
> involved with or know of, so please allow me to enlighten you how it could
> possiby work:
> 
> - somebody named X gets a trojan in the Debian archive through a GPG key
> - SPI (not Debian as it does not have a legal entity in itself) brings the
>   case to a law agency claiming that X has committed a crime
> - the Police traces X to A, B and C (same names != same people)

You'd have to skip this point if name(X) != name(A).

> - the Police gathers evidence that A and B *might* be in possession of the
>   GPG key and might have done the attack (this includes things like
>   information from ISPs linking a telecommunications contract to a name, data
>   from their communication either publicly available or requested to ISPs or
>   servers)

They'll have some trouble getting information from ISPs hosting a proxy
of whatever outside the US.

Mike


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

Re: adding ddccontrol to debian

[Roberto C. Sanchez]

Hendrik Sattler wrote:
> Am Mittwoch, 31. Mai 2006 04:20 schrieb Luc Verhaegen:
> 
>>Imho there should be an X implementation of this:
>>* driver side should be possible entirely from within the ddc module:
>>the ddc module could probe and initialise the ddci slave address for the
>>driver when handed the I2C bus for ddc and could handle everything else
>>from there.
> 
> 
> Actually, this should be a kernel thing as a user might also control this 
> stuff for a VT.
> There is a framework for LCD backlight in kernel (2.6.16 at least), maybe 
> this 
> could be utilized or extended for such stuff?
> 
> HS

That is an interesting idea.  Have you considered proposing it to the
upstream devs?

-Roberto

-- 
Roberto C. Sanchez
http://familiasanchez.net/~roberto


signature.asc
Description: OpenPGP digital signature

about mdadm 2.5-1/experimental

[martin f krafft]

Good evening^Wmorning,

I have uploaded mdadm 2.4.1-2 to unstable (should be ready for
(non-production) use, no *big* changes), and 2.5-1 to experimental
(*big* changes, works in my case, YMMV).

If you want to give 2.5-1 a whirl, I would appreciate it. Until the
initramfs-tools maintainers have had a chance to catch up (no
pressure...), please consider:

THIS IS AN EXPERIMENTAL RELEASE. DO NOT EVEN THINK ABOUT RUNNING IT
ON PRODUCTION SERVERS. or at least don't blame me for it afterwards.

None of the following needs to concern you if you are using
monolithic kernels (no modules), yaird, or initrd-tools/mkinitrd.

This release depends heavily on the initramfs-tools dudes fixing
#367567 with their next (>> 0.60) release. In the mean time, you
*can* try mdadm 2.5 by taking a screwdriver and loosening those
screws that make the conflict on initramfs-tools (<= 0.60)
necessary:

  apt-get install -d -t experimental mdadm
  sed -i -e s,md,mdadm, /usr/share/initramfs-tools/scripts/local-top/lvm
  rm /usr/share/initramfs-tools/{scripts/local-top,hooks}/md
  dpkg -i --force-conflicts /var/cache/apt/archive/mdadm_2.5-1_*.deb

If you installed the package before the `sed` and `rm` calls,
please run `update-initramfs -u` afterwards.

Good luck, and thanks.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
you can't assign IP address 127.0.0.1 to the loopback adapter,
because it is a reserved address for loopback devices.
  -- micro$oft windoze xp professional


signature.asc
Description: Digital signature (GPG/PGP)

Re: adding ddccontrol to debian

[Hendrik Sattler]

Am Mittwoch, 31. Mai 2006 04:20 schrieb Luc Verhaegen:
> Imho there should be an X implementation of this:
> * driver side should be possible entirely from within the ddc module:
> the ddc module could probe and initialise the ddci slave address for the
> driver when handed the I2C bus for ddc and could handle everything else
> from there.

Actually, this should be a kernel thing as a user might also control this 
stuff for a VT.
There is a framework for LCD backlight in kernel (2.6.16 at least), maybe this 
could be utilized or extended for such stuff?

HS


pgpq3BejpDwMb.pgp
Description: PGP signature

Re: Please revoke your signatures from Martin Kraff's keys

[Javier Fernández-Sanguino Peña]

On Mon, May 29, 2006 at 02:48:33PM +0200, Wouter Verhelst wrote:
> Then there's the issue of tracing who did an actual upload into the real
> world. A name on a GPG key is not, by any means, an effective way to do
> that, since it does not contain enough information to get out the black
> helicopters. Case in point:
(...)

Useless case, you seem to believe that police officers can only trace and
obtain information from people through Google !

I do not know how many cases related to "digital crimes" have you been
involved with or know of, so please allow me to enlighten you how it could
possiby work:

- somebody named X gets a trojan in the Debian archive through a GPG key
- SPI (not Debian as it does not have a legal entity in itself) brings the
  case to a law agency claiming that X has committed a crime
- the Police traces X to A, B and C (same names != same people)
- the Police gathers evidence that A and B *might* be in possession of the
  GPG key and might have done the attack (this includes things like
  information from ISPs linking a telecommunications contract to a name, data
  from their communication either publicly available or requested to ISPs or
  servers)
- the Police asks for a search warrant, gets into A and B's house and seizes
  their computers
- the Police finds the private key associated with the GPG key in A's
  computer (maybe even evidences of the trojan itself)

Guess who is going to get prosecuted regardless of whether they have the same
name?

If you think that's science fiction, maybe a tv series plot, or think that
law agencies (or judges) are stupid and cannot gather evidence for a case in
the digital age then think again [1]

Law agencies (in many countries) have enough budget and laws backing them to
do that (and more). Given enough damage done by X (=A) through the trojan
introduced in the archive or enough money layed down by SPI you bet there
would be a thorough investigation of the case.

Regards

Javier


[1] Virus and worm writers have been busted with even less information (when
the investigation started) than the information I leak while writting this
e-mail.


signature.asc
Description: Digital signature

Re: [Debconf-discuss] list of valid documents for KSPs

[Manoj Srivastava]

On 30 May 2006, Theodore Tso stated:

> On Tue, May 30, 2006 at 07:49:34AM -0500, Manoj Srivastava wrote:
>>> What Martin Krafft showed you was,
>>
>> How do I know that person actually was  Martin Krafft?
>
> So if you have no idea whether or not someone was Martin Krafft, how
> can you ask everyone to revoke all signatures for Martin Krafft as
> you did earlier.  That is really unreasonable.

The person who I thought was Marting has apparently revealed
 that the identity documents that were preseted to the key signing
 party participants were ones that did not come out of a trusted
 process.  Typically, the identity papers are produced by official
 bodies, like governments, that have international treaties in place
 to assure a minimal conformance of identity checks.

Given that, it is entirely reasonable to ask for signatures to
 be revoked,  since this was not the first time such an "experiment"
 has apparently been conducted.

> Does that mean that if someone shows up at an future keysigning
> party at OLS, for example, with an Transational Republic ID which
> has the name "Manoj Srivastava", that everyone would be therefore be
> entitled to demand on debian-devel that all signatures for "Manoj
> Srivastava" should now be revoked?

I would think that if an imposter was running around, and if
 people were no longer sure that such an imposter twas the one whose
 ID they had based their signatures on, HELL YES!!!

> After all, we have no idea if anyone who might or might not have
> been "Manoj Srivastava" might or might not have produced an
> identification documents that may or may not have been false.  We
> don't know!

Then please do revoke your signature on a key that purports to
 be mine.


> Do you see how rediculous this is?  How irrational you are being?

I think you are the one being irrational talking about a "web
 of trust" and blithely signing keys for people who conduct "tests" to
 see how weak processes of "trust" are.

If I, or someone posing as me, has ever done anything to
 damage trust in my identity, REVOKE YOUR SIGNATURES FROM MY KEY.


Is that plain enough for you? 
> Had Martin never mentioned this, it would have been a non-issue.
> There is no real damage. While signatures may have been based on a
> non-offical ID, Martin did indeed own the key in question, so the
> end harm is zero. But Martin decided to publish this experiment

Err, while you so assert, and perhaps you have inside
 information that enables you to make that statement, I have no such
 recourse.  How do I know someone called Martin does own that key,
 except by hearsay?

> So, if KSPs are not changed, then the Web of trust becomes
> effectively worthless.  Manoj should be far more concerned about
> that, then about Martin's demonstration of this.

Well, KSP's in Debian are essentially dead, as far as I am
 concerned, since the community has not come to an agreement that
 bringing Bubba's passports is an unacceptable action.  Everyone is
 actring the ostrich, claiming that the burden lies on the
 verification process of the signer, despite the fact that it is
 essentially impossible to detect the forgery without specialized
 equipment and  access to government data files.

Since we have rejected a social workaround of deprecating
 Bubba's passports (like, you know, in other unpublished "tests"), I
 fail to see how one can actually sign a key in the community.  I
 can't tell Bubba's ID's from the official ones.

On 30 May 2006, Joe Smith told this:

> Let me try to spell it out another way.  Either the entity at the
> the KSP who was allegedly Martin Krafft was indeed Martin Krafft, or
> he was not.  It must be one or the other; you seem to be arguing
> things both ways, and you don't get to do that.

Sigh.  Your logic is flawed.  I met someone who claimed to be
 Martin. I find that there is now doubt about the papers presented by
 such an individual. A person who owns that key claims to have
 presented papers of uncertain provenance. If you think this has
 nothing to do with the validity of the process of signing that key,
 especially  since my memory of the actual checking process is
 unclear, and that many people bought into that identity papers, I
 certainly am ginna lower the trust I place in your ability to
 determine how the web of trust is extended.

On 30 May 2006, Henning Makholm stated:

> Scripsit Manoj Srivastava <[EMAIL PROTECTED]>
>
>> Nothing that a general software developer can do to check an ID is
>> proof against a determined individual, we all assume that there is
>> a gentleman's agreement in place that such an attack is not
>> mounted.
>
> If you _really_ believed that you could depend on people keeping any
> gentleman's agreement, the whole charade of holding a KSP would be
> completely pointless.

If you think that you can check an ID if there are no
 expectations of good faith, then you are stickin

Re: Renaming a package

[Otavio Salvador]

Steve Langasek <[EMAIL PROTECTED]> writes:

> On Wed, May 31, 2006 at 02:05:13PM +0200, Daniel Kobras wrote:
>> On Tue, May 30, 2006 at 04:12:31PM -0700, Steve Langasek wrote:
>> > On Tue, May 30, 2006 at 11:22:51AM +0200, Simon Richter wrote:
>> > > Steve Langasek schrieb:
>> > > >>Package: oldpkg
>> > > >>Depends: newpkg
>> > > >>Description: transitional dummy package
>
>> > > >>Package: newpkg
>> > > >>Replaces: oldpkg
>> > > >>Conflicts: oldpkg
>> > > >>Description: ...
>
>> > > >*NO* *NO* *NO* *NO* *NO*.  Look closely at the package relationships 
>> > > >you've
>> > > >specified.  Why would you upload a package to the archive that *can 
>> > > >never 
>> > > >be installed*?
>
>> > > Hm, that used to be a "magic" combination that would let dpkg do the 
>> > > right thing.
>
>> > I've heard this stated before, but if it was ever true, it's definitely not
>> > the case with apt (or with britney), and it's not mentioned in policy.
>
>> It may well cause problems to britney, but policy section 7.5.2
>> ('Replacing whole packages, forcing their removal') definitely mentions
>> the behaviour of Replaces+Conflicts.
>
> It explains Replaces+Conflicts.  It does *not* say "create a dummy package
> that can't be installed because it depends on the thing that conflicts it".

Might be good to include a Provides too or packages depending in the
oldpkg will break.

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


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

Re: screenshot with package description

[Gonéri Le Bouder]

Since monday, I have a server. I'm working on creating a basic process to 
import files via ftp upload.

I created the Alioth group apt-pixmap and imported already created scripts on 
its CVS.


Regards,

Gonéri

Re: Renaming a package

[Steve Langasek]

On Wed, May 31, 2006 at 02:05:13PM +0200, Daniel Kobras wrote:
> On Tue, May 30, 2006 at 04:12:31PM -0700, Steve Langasek wrote:
> > On Tue, May 30, 2006 at 11:22:51AM +0200, Simon Richter wrote:
> > > Steve Langasek schrieb:
> > > >>Package: oldpkg
> > > >>Depends: newpkg
> > > >>Description: transitional dummy package

> > > >>Package: newpkg
> > > >>Replaces: oldpkg
> > > >>Conflicts: oldpkg
> > > >>Description: ...

> > > >*NO* *NO* *NO* *NO* *NO*.  Look closely at the package relationships 
> > > >you've
> > > >specified.  Why would you upload a package to the archive that *can 
> > > >never 
> > > >be installed*?

> > > Hm, that used to be a "magic" combination that would let dpkg do the 
> > > right thing.

> > I've heard this stated before, but if it was ever true, it's definitely not
> > the case with apt (or with britney), and it's not mentioned in policy.

> It may well cause problems to britney, but policy section 7.5.2
> ('Replacing whole packages, forcing their removal') definitely mentions
> the behaviour of Replaces+Conflicts.

It explains Replaces+Conflicts.  It does *not* say "create a dummy package
that can't be installed because it depends on the thing that conflicts it".

-- 
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: bits from the release team: release goals, python, X.org, amd64, timeline

[Michael Schmitz]

> Since m68k pretty much depends on the gcc-4.1 transition to make it in
> again, I would suggest that we (as in, the m68k port) make the switch to
> GCC4.1 as the default already. This will allow us to verify that stuff
> actually builds and works, and to catch up with building those that fail
> with ICE in gcc-4.0 before that time. Since m68k is not a release
> architecture right now, this should not cause any problems for any other
> port if the GCC 4.1 transition does not happen, but it will help if it
> does.
>
> Thoughts, objections?

I fully concur.

Michael


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

Re: bits from the release team: release goals, python, X.org, amd64, timeline

[Michael Schmitz]

> On Tue, May 30, 2006 at 02:01:19PM -0700, Steve Langasek wrote:
> > BTW, can you tell me anything about the dip in
> > http://buildd.debian.org/stats/graph2-quarter-big.png for m68k?  Seems to be
> > heading in the wrong direction again for being a release candidate.  I see
> > 12 buildds actively uploading packages for m68k, is this too few or is there
> > some other problem?
>
> Personally, I'm not sure what the problem is, actually. Anyone else?

For my part, it's due to the third version of glibc being built in as many
days (one on crest, two on hobbes) each blocking a fast host for 48+
hours, IIRC. Unless there's other biggies lurking in the queue, we should
catch up once the hopfully final glibc build is through.

N.B.: the flurry of glibc uploads speaks loud and clear as to people
getting their packages into shape for release.

Michael


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

Re: debdelta

[martin f krafft]

also sprach A Mennucc <[EMAIL PROTECTED]> [2006.05.31.1706 +0200]:
> I have completed a reasonably working version of 'debdelta', a package
> suite to compute differences between Debian packages.

Nice. I assume you saw
http://lists.debian.org/debian-devel/2006/05/msg02676.html ?

> Unfortunately my repository of .debdelta is currently stored in a
> slow-bandwidth server; I would need some space (~800Mb) in some Debian
> server to host it (in a server where there is a copy of the archive). Any
> suggestions? The best would be if ftp-masters may help me set it up
> in ftp.debian.org .

In the mean time, I could give you an account on one of my machines,
which are on a 4Gbps link.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"die philosophie ist eine art rache an der wirklichkeit."
 - friedrich nietzsche


signature.asc
Description: Digital signature (GPG/PGP)

Re: Red team attacks vs. cracking

[Gunnar Wolf]

Henning Makholm dijo [Wed, May 31, 2006 at 04:10:51AM +0200]:
> Scripsit Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]>
> 
> > I do agree with Manoj that this was *not* a legitimate experiment (i.e.
> > not a "red team" test) and that Martin *did* abuse our [0] trust [1]
> 
> A KSP that depends on there being any pre-existing trust to abuse is
> *completely worthless* as a KSP whether or not that trust is abused
> or not.

Ummm... There is a certain metric of pre-existing trust that _does_
exist here. Lets go back to Martin's specific case, to exemplify.

Many people have known Martin in person for several years. The people
that do know him already will be very surprised and react right away
if he wants to impersonate someone else (as an example, Alexander
Schmehl, who was at Debconf and was part of the prepared sheets, but
didn't take part in the end at the KSP). 

Of course, Martin could keep track of who knows him personally, and
maybe even extrapolate on who is right away familiar with Alexander,
and cleverly switch the fake and real IDs, not to raise
suspiciousness. 

If he is standing in spot 104 (which in our list means "between Jeroen
and Adeodato - who didn't participate, so Nicolas stands next to
him"), however, he won't be allowed to present an ID with Alexander's
name, as Alexander should have been standing in spot 38 (between me
and Rodrigo Gallardo).

Ok, so Martin, who is a bad person and a very good and clever actor,
will play as he were taking part in the KSP, standing between Rodrigo
and me. If somebody comes that probably knows Alexander or him
personally, he will pretend he is just hanging around, chatting with
people, and not signing keys.

But here comes the bit of pre-existing trust we _do_ have: I know
personally Alexander, have worked with him and can recognize him
easily. And although I haven't talked as much with Martin, I can also
easily recognize his face. If he is standing next to me the whole
time, even if he is a great actor and doesn't allow me to doubt he is
presenting a fake ID, it will be obvious for me he is impersonating
somebody else. So, I denounce he is a fake, and nobody signs the fake
Alexander's key.

Yes, I'm picking the names of two well-known people in the project. It
could be easier to impersonate, say, Raúl Odria or Mario Oyorzabal
(both of which didn't attend), so this pre-existing trust is
limited. But it clearly exists and counts for something, specially in
well-connected groups such as ours. And this is an important factor to
request people who are well known in the project not to skip the KSP
if it happens as it happened this time (and as in the other proposals
I've seen).

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

Re: Request for key signing in Shanghai

[Anthony Fok]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bonjour Thomas!

Thomas Goirand wrote:
> Stephen Gran wrote:
> >> This one time, at band camp, Thomas Goirand said:
> >>> Hello!
> >>>
> >>> Is there somebody in Shanghai from Debian able to check my ID
> >>> and sign my key? If there is none, is there somebody in
> >>> Singapore, where I might be able to go? I wouldn't be able to
> >>> go in Hongkong (because of visa problems) where I could see there
> >>> was somebody available.
Most Debian developers from Hong Kong are in Mainland China nowadays.  :-)

I'll be in Shanghai briefly this coming Sunday at the airport.  If you
don't mind going to the Pudong airport, or if you don't mind taking a
bus or a train to come to Kunshan, I'd be happy to check your ID and
sign your key.  :-)

Cheers,

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

iD8DBQFEfbOLLa8qZm1n95ARAm3zAJ9yLOiMDoIN9PPxZPmg/DBUfUbbwgCcCv67
SrsnGDyrMwN1DzefQ1xukQc=
=q7q5
-END PGP SIGNATURE-


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

debdelta

[A Mennucc]

Dear Debian people,

I have completed a reasonably working version of 'debdelta', a package
suite to compute differences between Debian packages.

For sake of clarity, let's call '.debdelta' a file that encodes
the differences between Debian packages, and '.deb' a Debian package.

The command 'debdelta' creates a .debdelta ; the command 'debpatch'
applies it to the old .deb to recreate the new .deb ; or,
it can use the *installed* files of the old .deb.

The command 'debdelta-upgrade' is meant to be run between 'apt-get
 update' and 'apt-get upgrade'; it downloads .debdelta files and
 recreate the new .deb files from them; always using the *installed* old
 version of the .deb, and not the old .deb file itself.

Downloading .debdeltas instead of .deb packages can be a huge
benefit for people with slow Internet access, and/or to keep traffic
on servers low (as when the X security upgrade did saturate the server
security.debian.org , see http://www.debian.org/News/2005/20050920 )

More info and details are in 
  http://tonelli.sns.it/pub/mennucc1/debdelta/README

The 'debdelta' package is in
 http://tonelli.sns.it/pub/mennucc1/debdelta/etch
or
 http://tonelli.sns.it/pub/mennucc1/debdelta/sarge

Unfortunately my repository of .debdelta is currently stored in a
slow-bandwidth server; I would need some space (~800Mb) in some Debian
server to host it (in a server where there is a copy of the archive). Any
suggestions? The best would be if ftp-masters may help me set it up
in ftp.debian.org .

a.

-- 
Andrea Mennucc



signature.asc
Description: Digital signature

Re: bits from the release team: release goals, python, X.org, amd64, timeline

[Christian T. Steigies]

On Wed, May 31, 2006 at 02:35:47PM +0200, Wouter Verhelst wrote:
> [You had removed m68k-build from the Cc list. Was that on purpose?]
> 
> On Tue, May 30, 2006 at 02:01:19PM -0700, Steve Langasek wrote:
> > BTW, can you tell me anything about the dip in
> > http://buildd.debian.org/stats/graph2-quarter-big.png for m68k?  Seems to be
> > heading in the wrong direction again for being a release candidate.  I see
> > 12 buildds actively uploading packages for m68k, is this too few or is there
> > some other problem?
> 
> Personally, I'm not sure what the problem is, actually. Anyone else?

http://unstable.buildd.net/buildd/m68k_stats

a4000t, crest, kullervo, and vivaldi are sitting on 15+ packages, but those
might be unreported failures. Most of our buildds are up, I even switched on
my mac again, so I don't think the number of buildds is the problem.

Christian


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

Re: adding ddccontrol to debian

[Otavio Salvador]

"Roberto C. Sanchez" <[EMAIL PROTECTED]> writes:

> I have a package ready at the moment.  However, it only cleanly builds
> with the version of gcc in Sarge.  I have been assured by upstream that
> a new release is forthcoming which fixes the build issues with gcc 4.x.
>  Once it is out, the package will be updated and uploaded.

I saw that 0.4.1 works with Fedora Core 4 and AFAIK it has new GCC so
it should be enough. Am I wrong?

Also, you might try to use CVS snapshots to get it in for testing too,
if the released version isn't enough for us.

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


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

Re: Package Selection for Debian Live

[Daniel Baumann]

Pedro Macanas wrote:
> There is no  XFCE version (see  http://live.debian.net/wiki/Download ).
> Previously there was a XFCE version.

There will be one as soon as Xfce is installable in sid again.

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


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

Re: Contacting the buildd admin of the current build chroot

[Ingo Juergensmann]

On Wed, May 31, 2006 at 04:16:47PM +0200, Thomas Weber wrote:

> is it possible for a 'building' package to send a mail to the buildd
> admin of the current buildd machine (i.e. something like
> [EMAIL PROTECTED])?

Usually (at least for most m68k buildds) the buildd runs under *surprise*
the use "buildd". Mail to that user is forwarded by buildd-mail to the
buildd admin. 

> Sending this problem to the [EMAIL PROTECTED] list
> didn't fix it for all machines, as can be seen at
> http://buildd.debian.org/fetch.php?pkg=octaviz%26ver=0.4.0-26%
> 26arch=ia64%26stamp=1149076049%26file=log
> (search for '2005').
> Now, I would like to add something to debian/rules that checks for the
> state (auto/manual) of this symlink and sends a mail to the buildd admin
> if the state is 'manual'. Thus, only involved admins would be bothered.
> Alternatively, I could add 
>   update-alternatives --auto octave-config 
> to debian/rules; but I don't know if this is acceptable.
> Suggestions?

Hmmm, on http://www.buildd.net/ there are contact addresses listed beside
almost every buildd, if you want to contact certain buildd admins directly.

-- 
Ciao...//Fon: 0381-2744150 
  Ingo   \X/ SIP: [EMAIL PROTECTED]

gpg pubkey: http://www.juergensmann.de/ij/public_key.asc


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

Contacting the buildd admin of the current build chroot

[Thomas Weber]

Hi, 

is it possible for a 'building' package to send a mail to the buildd
admin of the current buildd machine (i.e. something like
[EMAIL PROTECTED])?

Reason: somewhere around Sep-Nov 2005, an alternative symlink was left
by the octave2.1 package in state 'manual'. This means that packages
build-depending on octave2.1 fail to build (if they are built on a
buildd which built octave2.1 in this period). A more explicit
explanation can be found at
http://lists.debian.org/debian-devel/2006/01/msg01566.html.

Sending this problem to the [EMAIL PROTECTED] list
didn't fix it for all machines, as can be seen at
http://buildd.debian.org/fetch.php?pkg=octaviz%26ver=0.4.0-26%
26arch=ia64%26stamp=1149076049%26file=log
(search for '2005').

Now, I would like to add something to debian/rules that checks for the
state (auto/manual) of this symlink and sends a mail to the buildd admin
if the state is 'manual'. Thus, only involved admins would be bothered.

Alternatively, I could add 
  update-alternatives --auto octave-config 
to debian/rules; but I don't know if this is acceptable.

Suggestions?

Thanks
Thomas


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

Re: Renaming a package

[Frank Küster]

Daniel Kobras <[EMAIL PROTECTED]> wrote:

> On Tue, May 30, 2006 at 04:12:31PM -0700, Steve Langasek wrote:
>> On Tue, May 30, 2006 at 11:22:51AM +0200, Simon Richter wrote:
>> > Steve Langasek schrieb:
>> > >>Package: oldpkg
>> > >>Depends: newpkg
>> > >>Description: transitional dummy package
>> 
>> > >>Package: newpkg
>> > >>Replaces: oldpkg
>> > >>Conflicts: oldpkg
>> > >>Description: ...
>> 
>> > >*NO* *NO* *NO* *NO* *NO*.  Look closely at the package relationships 
>> > >you've
>> > >specified.  Why would you upload a package to the archive that *can never 
>> > >be installed*?
>> 
>> > Hm, that used to be a "magic" combination that would let dpkg do the 
>> > right thing.
>> 
>> I've heard this stated before, but if it was ever true, it's definitely not
>> the case with apt (or with britney), and it's not mentioned in policy.
>
> It may well cause problems to britney, but policy section 7.5.2
> ('Replacing whole packages, forcing their removal') definitely mentions
> the behaviour of Replaces+Conflicts.

I think the wording is a bit unclear.  Of course it works as described
if there are two or more alternative packages, possibly all providing a
particular virtual package, and you have one installed and say "apt-get
install one_other".  What happens upon upgrade is not specified in that
section, but it is clear from other information:

Before upgrade: oldpkg is installed

apt-get upgrade:

- wants to upgrade oldpkg

- checks for new dependencies: oldpkg now Depends: newpkg

- wants to install newpkg: Since newpkg Conflicts: oldpkg, it cannot be
  installed, neither before nor after upgrading oldpkg.

  Possible solutions:

  a) remove oldpkg, install newpkg

  b) keep oldpkg at old version

Of course you want it to choose a), but that is not going to happen.
apt-get doesn't now that oldpkg is a dummy package, and you never
requested newpkg to be installed.  Therefore it will choose solution b. 

In short:  The mechanism of Replaces as described in 7.5.2 only works if
the package that declares both the Conflicts and Replaces is explicitly
selected for installation, and helps to decide which of two (or more?)
conflicting packages should be removed.  It does not help in apt*
invocations where no package names are given.

Regards, Frank


-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: adding ddccontrol to debian

[Holger Levsen]

Hi,

On Wednesday 31 May 2006 01:08, Roberto C. Sanchez wrote:
> The current ITP is not frozen :-)
>
> I have a package ready at the moment.  However, it only cleanly builds
> with the version of gcc in Sarge.  I have been assured by upstream that
> a new release is forthcoming which fixes the build issues with gcc 4.x.
>  Once it is out, the package will be updated and uploaded.
>
> -Roberto

bcc:ed to the #322774 as that info was not there yet.


regards,
Holger


pgp1J2ZweKVoq.pgp
Description: PGP signature

Re: bits from the release team: release goals, python, X.org, amd64, timeline

[Wouter Verhelst]

[You had removed m68k-build from the Cc list. Was that on purpose?]

On Tue, May 30, 2006 at 02:01:19PM -0700, Steve Langasek wrote:
> BTW, can you tell me anything about the dip in
> http://buildd.debian.org/stats/graph2-quarter-big.png for m68k?  Seems to be
> heading in the wrong direction again for being a release candidate.  I see
> 12 buildds actively uploading packages for m68k, is this too few or is there
> some other problem?

Personally, I'm not sure what the problem is, actually. Anyone else?

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: bits from the release team: release goals, python, X.org, amd64, timeline

[Ingo Juergensmann]

On Tue, May 30, 2006 at 02:01:19PM -0700, Steve Langasek wrote:

> BTW, can you tell me anything about the dip in
> http://buildd.debian.org/stats/graph2-quarter-big.png for m68k?  Seems to be
> heading in the wrong direction again for being a release candidate.  I see
> 12 buildds actively uploading packages for m68k, is this too few or is there
> some other problem?

Hmmm, when I compare your graph with my graph on
http://unstable.buildd.net/buildd/m68k_stats.png it seem that the drop is
caused by a bunch of packages in Needs-Build queue. 
The total number of installed packages (>5900) is ok for me. 

There are >120 packages in Building which might be caused by a bad
coincidence of one buildd admin going on vacation and network problems of
two of his buildds, so that buildd logs couldn't be handled. 

And you may have noticed that one or the other buildd was shutdown lately,
because there was too less work for them. Tanda for example is usually
powered off, but gets reactivated when there is a peak in the needs-build
queue. Sadly one buildd (akire) is idle because its new ssh pubkey wasn't
added after a disk crash. 

After all, nothing serious to worry about, IMHO.

-- 
Ciao...//Fon: 0381-2744150 
  Ingo   \X/ SIP: [EMAIL PROTECTED]

gpg pubkey: http://www.juergensmann.de/ij/public_key.asc


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

Re: Renaming a package

[Daniel Kobras]

On Tue, May 30, 2006 at 04:12:31PM -0700, Steve Langasek wrote:
> On Tue, May 30, 2006 at 11:22:51AM +0200, Simon Richter wrote:
> > Steve Langasek schrieb:
> > >>Package: oldpkg
> > >>Depends: newpkg
> > >>Description: transitional dummy package
> 
> > >>Package: newpkg
> > >>Replaces: oldpkg
> > >>Conflicts: oldpkg
> > >>Description: ...
> 
> > >*NO* *NO* *NO* *NO* *NO*.  Look closely at the package relationships you've
> > >specified.  Why would you upload a package to the archive that *can never 
> > >be installed*?
> 
> > Hm, that used to be a "magic" combination that would let dpkg do the 
> > right thing.
> 
> I've heard this stated before, but if it was ever true, it's definitely not
> the case with apt (or with britney), and it's not mentioned in policy.

It may well cause problems to britney, but policy section 7.5.2
('Replacing whole packages, forcing their removal') definitely mentions
the behaviour of Replaces+Conflicts.

Regards,

Daniel.


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

Re: id gives conflicting results

[Juha Jäykkä]

> Doubtful.  Several things might cause this behavior (slow slapd timing
> out, nscd caching bad information, group queries set up wrong), but it's

Nscd's off since it *WILL* cache up the wrong info every now and then
without a clear indication of why. This I thought might be ldap timeout
issue, but instead of trying to figure it out, I removed nscd.

As to slapd timing out, I doubt it since this also happens on the slapd
servers themselves (which should *not* be too slow with the modest db we
have). The connect timeout is 5 seconds, search timeout 30 - they are
intentionally low so that it would swiftly fall back to next LDAP replica
in case the primary one dies. Perhaps the resolver does not implement
this fall-back cleanly?

Group queries may indeed be set up wrong - but I have dug thourgh all the
docs I can and cannot figure out what would be wrong there. Remember:
this affects just three user accounts (perhaps more - I haven't done
extensive testing) and all out accounts are analogous to each other: only
the attributes uid, uidNumber, gidNumber, mail and krb5PrincipalName
differ (yes, userPasswords are identical: {KERBEROS} hard to say.  The fact that it's so random leads me to believe it's
> something like a slapd timeout.

I just tried to increase the timeouts to 30 and 120 seconds, but the
effect remains.

Still as baffled as ever,
Juha

-- 
 ---
| Juha Jäykkä, [EMAIL PROTECTED]|
| Laboratory of Theoretical Physics |
| Department of Physics, University of Turku|
| home: http://www.utu.fi/~juolja/  |
 ---


signature.asc
Description: PGP signature

Bug#361814: marked as done (ICE: tree check: expected ssa_name, have symbol_memory_tag in is_old_name, at tree-into-ssa.c:466)

[Debian Bug Tracking System]

Your message dated Tue, 30 May 2006 16:47:41 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Accepted gcc-snapshot 20060530-1 (source i386 amd64 powerpc)
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: gcc-snapshot
Version: 20060325-1


> Automatic build of gnutls11_1.0.16-14 on em64t by sbuild/amd64 1.112
...
>  cc -DHAVE_CONFIG_H -I. -I. -I.. -I../libextra -Iminitasn1/ -I../includes 
> -I/usr/include -I/usr/include -g -Wall -O2 -D_REENTRANT -D_THREAD_SAFE -g -O2 
> -finline-functions -pipe -c auth_cert.c -o auth_cert.o >/dev/null 2>&1
> make[4]: *** [auth_cert.lo] Error 1

(sid)2618:[EMAIL PROTECTED]: ~/src/gnutls11-1.0.16/lib] 
/usr/lib/gcc-snapshot/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../libextra 
-Iminitasn1/ -I../includes -I/usr/include -I/usr/include -g -Wall -O2 
-D_REENTRANT -D_THREAD_SAFE -g -O2 -finline-functions -pipe -c auth_cert.c -o 
auth_cert.o
auth_cert.c: In function '_gnutls_gen_x509_crt':
auth_cert.c:652: internal compiler error: tree check: expected ssa_name, have 
symbol_memory_tag in is_old_name, at tree-into-ssa.c:466
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

-- 
Martin Michlmayr
http://www.cyrius.com/

--- End Message ---
--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 30 May 2006 15:54:59 +0200
Source: gcc-snapshot
Binary: gcc-snapshot
Architecture: amd64 i386 powerpc source 
Version: 20060530-1
Distribution: unstable
Urgency: low
Maintainer: Debian GCC Maintainers 
Changed-By: Martin Michlmayr <[EMAIL PROTECTED]>
Description: 
 gcc-snapshot - A SNAPSHOT of the GNU Compiler Collection
Closes: 361441 361591 361602 361814 364394 364591 364602 364622 366626 366939
Changes: 
 gcc-snapshot (20060530-1) unstable; urgency=low
 .
* SVN 20060530, taken from the trunk, revision 114238.
  - PR tree-optimization/27085: ICE in add_virtual_operand, at
tree-ssa-operands.c (closes: #361441).
  - PR tree-optimization/27093: ICE in verify_ssa failed:
definition does not dominate use (closes: #361591).
  - PR middle-end/25776: ICE: verify_cgraph_node failed (closes:
#361602).
  - PR tree-optimization/26490: ICE: tree check: expected ssa_name,
have symbol_memory_tag in is_old_name (closes: #361814).
  - PR c/27273: ICE: tree check: expected class 'constant', have
'binary' (bit_and_expr) in convert_and_check, at c-common.c
(closes: #364591).
  - PR tree-optimization/27548: ICE: SSA corruption: Conflict across
an abnormal edge (closes: #364602).
  - PR c++/27210: ICE: tree check: did not expect class 'type', have
'type' (template_type_parm) in contains_placeholder_p, at tree.c
(closes: #364622).
  - PR c++/27471: ICE in build_c_cast, at cp/typeck.c:5443 (closes:
#366626).
  - PR target/27158 (powerpc): ICE: error in extract_insn, at
recog.c:2084 (see #362307, also present in gcc-4.1).
  - PR target/27571 (alpha): ICE in get_attr_usegp, at
config/alpha/alpha.md:171 (closes: #366939).
* Update ppc64 patch so it builds again.  Thanks, Andreas Jochens
  (closes: #364394).
* Add myself as an uploader.
Files: 
 5c13ef903bbe62b16c730efd04efedc6 37995290 devel standard 
gcc-snapshot_20060530-1.tar.gz
 b1c67a1adfd42b761ffbc7b925e2c4a8 2421 devel standard 
gcc-snapshot_20060530-1.dsc
 75b25dbb6d9b5705ad244f9475f0385e 56658110 devel extra 
gcc-snapshot_20060530-1_i386.deb
 987f439cfac1980f86209830852df975 61639740 devel extra 
gcc-snapshot_20060530-1_amd64.deb
 a25cbb180f357e3c9bb79ad4ab2708e2 62751796 devel extra 
gcc-snapshot_20060530-1_powerpc.deb

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

iD8DBQFEfMeGKb5dImj9VJ8RAtqfAJ0WibiV+Rd80Vh0p/YEUif0nUyoWwCfT6V7
n/fcC5h9QuhinHbZMw6vCD0=
=OjlY
-END PGP SIGNATURE-


Accepted:
gcc-snapshot_20060530-1.dsc
  to pool/main/g/gcc-snapshot/gcc-snapshot_20060530-1.dsc
gcc-snapshot_20060530-1.tar.gz
  to pool/main/g/gcc-snapshot/gcc-snapshot_20060530-1.tar.gz
gcc-snapshot_20060530-1_amd64.deb
  to pool/main/g/gcc-snapshot/gcc-snapshot_20060530-1_amd64.deb
gcc-snapshot_20060530-1_i386.deb
  to pool/main/g/gcc-snapshot/gcc-snapshot_20060530-1_i386.deb
gcc-snapshot_20060530-1_powerpc.deb
  to pool/main/g/gcc-snapshot/gcc-snapshot_20060530-1_powerpc.deb


-- 
To UNSUBSCRIBE, email to [EMAIL PRO

Bug#366939: marked as done ([alpha] ICE: in get_attr_usegp, at config/alpha/alpha.md:171)

[Debian Bug Tracking System]

Your message dated Tue, 30 May 2006 16:47:41 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Accepted gcc-snapshot 20060530-1 (source i386 amd64 powerpc)
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: gcc-snapshot
Version: 20060508-1

I've filed PR27571 about this.

> Automatic build of eglade_0.3.7-2 on juist by sbuild/alpha 0.44
...
> gcc -pipe -O2 -c -x c base1.c
> base1.c: In function 'r7to_double':
> base1.c:3823: error: unrecognizable insn:
> (jump_insn 36 35 37 (addr_diff_vec:SI (label_ref:DI 35)
>  [
> (label_ref:DI 43)
> (label_ref:DI 98)
> (label_ref:DI 115)
> (label_ref:DI 151)
> (label_ref:DI 181)
> (label_ref:DI 213)
> (label_ref:DI 244)
> (label_ref:DI 255)
> ]
> (const_int 0 [0x0])
> (const_int 0 [0x0])) -1 (nil)
> (nil))
> base1.c:3823: internal compiler error: in get_attr_usegp, at 
> config/alpha/alpha.md:171
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.

-- 
Martin Michlmayr
http://www.cyrius.com/

--- End Message ---
--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 30 May 2006 15:54:59 +0200
Source: gcc-snapshot
Binary: gcc-snapshot
Architecture: amd64 i386 powerpc source 
Version: 20060530-1
Distribution: unstable
Urgency: low
Maintainer: Debian GCC Maintainers 
Changed-By: Martin Michlmayr <[EMAIL PROTECTED]>
Description: 
 gcc-snapshot - A SNAPSHOT of the GNU Compiler Collection
Closes: 361441 361591 361602 361814 364394 364591 364602 364622 366626 366939
Changes: 
 gcc-snapshot (20060530-1) unstable; urgency=low
 .
* SVN 20060530, taken from the trunk, revision 114238.
  - PR tree-optimization/27085: ICE in add_virtual_operand, at
tree-ssa-operands.c (closes: #361441).
  - PR tree-optimization/27093: ICE in verify_ssa failed:
definition does not dominate use (closes: #361591).
  - PR middle-end/25776: ICE: verify_cgraph_node failed (closes:
#361602).
  - PR tree-optimization/26490: ICE: tree check: expected ssa_name,
have symbol_memory_tag in is_old_name (closes: #361814).
  - PR c/27273: ICE: tree check: expected class 'constant', have
'binary' (bit_and_expr) in convert_and_check, at c-common.c
(closes: #364591).
  - PR tree-optimization/27548: ICE: SSA corruption: Conflict across
an abnormal edge (closes: #364602).
  - PR c++/27210: ICE: tree check: did not expect class 'type', have
'type' (template_type_parm) in contains_placeholder_p, at tree.c
(closes: #364622).
  - PR c++/27471: ICE in build_c_cast, at cp/typeck.c:5443 (closes:
#366626).
  - PR target/27158 (powerpc): ICE: error in extract_insn, at
recog.c:2084 (see #362307, also present in gcc-4.1).
  - PR target/27571 (alpha): ICE in get_attr_usegp, at
config/alpha/alpha.md:171 (closes: #366939).
* Update ppc64 patch so it builds again.  Thanks, Andreas Jochens
  (closes: #364394).
* Add myself as an uploader.
Files: 
 5c13ef903bbe62b16c730efd04efedc6 37995290 devel standard 
gcc-snapshot_20060530-1.tar.gz
 b1c67a1adfd42b761ffbc7b925e2c4a8 2421 devel standard 
gcc-snapshot_20060530-1.dsc
 75b25dbb6d9b5705ad244f9475f0385e 56658110 devel extra 
gcc-snapshot_20060530-1_i386.deb
 987f439cfac1980f86209830852df975 61639740 devel extra 
gcc-snapshot_20060530-1_amd64.deb
 a25cbb180f357e3c9bb79ad4ab2708e2 62751796 devel extra 
gcc-snapshot_20060530-1_powerpc.deb

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

iD8DBQFEfMeGKb5dImj9VJ8RAtqfAJ0WibiV+Rd80Vh0p/YEUif0nUyoWwCfT6V7
n/fcC5h9QuhinHbZMw6vCD0=
=OjlY
-END PGP SIGNATURE-


Accepted:
gcc-snapshot_20060530-1.dsc
  to pool/main/g/gcc-snapshot/gcc-snapshot_20060530-1.dsc
gcc-snapshot_20060530-1.tar.gz
  to pool/main/g/gcc-snapshot/gcc-snapshot_20060530-1.tar.gz
gcc-snapshot_20060530-1_amd64.deb
  to pool/main/g/gcc-snapshot/gcc-snapshot_20060530-1_amd64.deb
gcc-snapshot_20060530-1_i386.deb
  to pool/main/g/gcc-snapshot/gcc-snapshot_20060530-1_i386.deb
gcc-snapshot_20060530-1_powerpc.deb
  to pool/main/g/gcc-snapshot/gcc-snapshot_20060530-1_powerpc.deb


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

Bug#364394: marked as done (gcc-snapshot: FTBFS (ppc64): /usr/bin/ld: cannot find -lc)

[Debian Bug Tracking System]

Your message dated Tue, 30 May 2006 16:47:41 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Accepted gcc-snapshot 20060530-1 (source i386 amd64 powerpc)
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: gcc-snapshot
Version: 20060419-1
Severity: wishlist
Tags: patch

When building 'gcc-snapshot' on ppc64/unstable,
I get the following error:

/usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.so when searching for 
-lc
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.a when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
make[6]: *** [32/libgcc_s.so] Error 1

With the attached patch 'gcc-snapshot' can be compiled on ppc64.

The patch changes 'debian/ppc64-biarch.dpatch' so that the patch
applies to the new snapshot version.

It also changes debian/rules.patch to apply the ppc64-biarch.dpatch
and the ppc64-ada.dpatch patches even if 'biarch32' is disabled.
The build fails if those patches are not applied.

Regards
Andreas Jochens

diff -urN ../tmp-orig/gcc-snapshot-20060419/debian/patches/ppc64-biarch.dpatch 
./debian/patches/ppc64-biarch.dpatch
--- ../tmp-orig/gcc-snapshot-20060419/debian/patches/ppc64-biarch.dpatch
2006-04-19 20:38:10.0 +
+++ ./debian/patches/ppc64-biarch.dpatch2006-04-21 12:36:01.0 
+
@@ -44,20 +44,6 @@
  
  # We want fine grained libraries, so use the new code to build the
  # floating point emulation libraries.
-@@ -37,8 +34,11 @@
- mklibgcc: bispecs
- 
- bispecs: specs
--  if [ x`$(GCC_FOR_TARGET) -print-multi-os-directory` = x../lib ]; then \
-+  touch f-test.c; \
-+  $(GCC_FOR_TARGET) -c f-test.c -o f-test.o; \
-+  if [ "x`file f-test.o | grep 64-bit`" = "x" ]; then \
- sed -e '/cc1_options/{ n; s/$$/ %{m64:-mlong-double-128}/; }' < specs 
> $@; \
-   else \
- sed -e '/cc1_options/{ n; s/$$/ %{!m32:-mlong-double-128}/; }' < 
specs > $@; \
--  fi
-+  fi; \
-+  rm f-test.c f-test.o;
 diff -urN tmp/libjava/configure.host src/libjava/configure.host
 --- tmp/libjava/configure.host 25 Nov 2004 03:46:56 -
 +++ src/libjava/configure.host 15 Dec 2004 15:45:22 -
diff -urN ../tmp-orig/gcc-snapshot-20060419/debian/rules.patch 
./debian/rules.patch
--- ../tmp-orig/gcc-snapshot-20060419/debian/rules.patch2006-04-19 
20:51:37.0 +
+++ ./debian/rules.patch2006-04-22 06:40:38.0 +
@@ -136,15 +136,14 @@
 debian_patches += amd64-biarch
 debian_patches += libjava-ia32fix
   endif
-  ifeq ($(DEB_TARGET_ARCH),ppc64)
-# FIXME: needed for 4.1?
-debian_patches += ppc64-biarch ppc64-ada
-  endif
   ifneq ($(with_32bit_check),yes)
 debian_patches += disable-configure-run-check
   endif
 endif
 
+ifeq ($(DEB_TARGET_ARCH),ppc64)
+  debian_patches += ppc64-biarch ppc64-ada
+endif
 
 patch: $(patch_stamp)
 $(patch_stamp): $(unpack_stamp) pre-patch \

--- End Message ---
--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 30 May 2006 15:54:59 +0200
Source: gcc-snapshot
Binary: gcc-snapshot
Architecture: amd64 i386 powerpc source 
Version: 20060530-1
Distribution: unstable
Urgency: low
Maintainer: Debian GCC Maintainers 
Changed-By: Martin Michlmayr <[EMAIL PROTECTED]>
Description: 
 gcc-snapshot - A SNAPSHOT of the GNU Compiler Collection
Closes: 361441 361591 361602 361814 364394 364591 364602 364622 366626 366939
Changes: 
 gcc-snapshot (20060530-1) unstable; urgency=low
 .
* SVN 20060530, taken from the trunk, revision 114238.
  - PR tree-optimization/27085: ICE in add_virtual_operand, at
tree-ssa-operands.c (closes: #361441).
  - PR tree-optimization/27093: ICE in verify_ssa failed:
definition does not dominate use (closes: #361591).
  - PR middle-end/25776: ICE: verify_cgraph_node failed (closes:
#361602).
  - PR tree-optimization/26490: ICE: tree check: expected ssa_name,
have symbol_memory_tag in is_old_name (closes: #361814).
  - PR c/27273: ICE: tree check: expected class 'constant', have
'binary' (bit_and_expr) in convert_and_check, at c-common.c
(closes: #364591).
  - PR tree-optimization/27548: ICE: SSA corruption: Conflict across
an abnormal edge (closes: #364602).
  - PR c++/27210: ICE

Bug#364602: marked as done (ICE: SSA corruption: Conflict across an abnormal edge)

[Debian Bug Tracking System]

Your message dated Tue, 30 May 2006 16:47:41 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Accepted gcc-snapshot 20060530-1 (source i386 amd64 powerpc)
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: gcc-snapshot
Version: 20060419-1

> Automatic build of gambit_0.2006.01.20-1.1 on test.track.rz.uni-augsburg.de 
> by sbuild/powerpc 0.44
...
> if powerpc-linux-gnu-g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" 
> -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" 
> -DPACKAGE=\"gambit\" -DVERSION=\"0.2006.01.20\" -DSTDC_HEADERS=1 
> -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
> -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 
> -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_BCMP=1 -DHAVE_SRAND48=1 
> -DHAVE_DRAND48=1  -I. -I.  -I../../../sources   -g -O2 -MT odometer.o -MD -MP 
> -MF ".deps/odometer.Tpo" -c -o odometer.o odometer.cc; \
>   then mv -f ".deps/odometer.Tpo" ".deps/odometer.Po"; else rm -f 
> ".deps/odometer.Tpo"; exit 1; fi
> 
>  Conflict NewMaxs$maxdex_1667(ab) and NewMaxs$maxdex_1642(ab) across an 
> abnormal edge from BB67->BB123
> odometer.cc: In member function 'gIndexOdometer 
> gIndexOdometer::AfterExcisionOf(int&) const':
> odometer.cc:171: internal compiler error: SSA corruption
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> make[4]: *** [odometer.o] Error 1
> make[4]: Leaving directory 
> `/build/tbm/gambit-0.2006.01.20/sources/tools/enumpoly'

-- 
Martin Michlmayr
http://www.cyrius.com/

--- End Message ---
--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 30 May 2006 15:54:59 +0200
Source: gcc-snapshot
Binary: gcc-snapshot
Architecture: amd64 i386 powerpc source 
Version: 20060530-1
Distribution: unstable
Urgency: low
Maintainer: Debian GCC Maintainers 
Changed-By: Martin Michlmayr <[EMAIL PROTECTED]>
Description: 
 gcc-snapshot - A SNAPSHOT of the GNU Compiler Collection
Closes: 361441 361591 361602 361814 364394 364591 364602 364622 366626 366939
Changes: 
 gcc-snapshot (20060530-1) unstable; urgency=low
 .
* SVN 20060530, taken from the trunk, revision 114238.
  - PR tree-optimization/27085: ICE in add_virtual_operand, at
tree-ssa-operands.c (closes: #361441).
  - PR tree-optimization/27093: ICE in verify_ssa failed:
definition does not dominate use (closes: #361591).
  - PR middle-end/25776: ICE: verify_cgraph_node failed (closes:
#361602).
  - PR tree-optimization/26490: ICE: tree check: expected ssa_name,
have symbol_memory_tag in is_old_name (closes: #361814).
  - PR c/27273: ICE: tree check: expected class 'constant', have
'binary' (bit_and_expr) in convert_and_check, at c-common.c
(closes: #364591).
  - PR tree-optimization/27548: ICE: SSA corruption: Conflict across
an abnormal edge (closes: #364602).
  - PR c++/27210: ICE: tree check: did not expect class 'type', have
'type' (template_type_parm) in contains_placeholder_p, at tree.c
(closes: #364622).
  - PR c++/27471: ICE in build_c_cast, at cp/typeck.c:5443 (closes:
#366626).
  - PR target/27158 (powerpc): ICE: error in extract_insn, at
recog.c:2084 (see #362307, also present in gcc-4.1).
  - PR target/27571 (alpha): ICE in get_attr_usegp, at
config/alpha/alpha.md:171 (closes: #366939).
* Update ppc64 patch so it builds again.  Thanks, Andreas Jochens
  (closes: #364394).
* Add myself as an uploader.
Files: 
 5c13ef903bbe62b16c730efd04efedc6 37995290 devel standard 
gcc-snapshot_20060530-1.tar.gz
 b1c67a1adfd42b761ffbc7b925e2c4a8 2421 devel standard 
gcc-snapshot_20060530-1.dsc
 75b25dbb6d9b5705ad244f9475f0385e 56658110 devel extra 
gcc-snapshot_20060530-1_i386.deb
 987f439cfac1980f86209830852df975 61639740 devel extra 
gcc-snapshot_20060530-1_amd64.deb
 a25cbb180f357e3c9bb79ad4ab2708e2 62751796 devel extra 
gcc-snapshot_20060530-1_powerpc.deb

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

iD8DBQFEfMeGKb5dImj9VJ8RAtqfAJ0WibiV+Rd80Vh0p/YEUif0nUyoWwCfT6V7
n/fcC5h9QuhinHbZMw6vCD0=
=OjlY
-END PGP SIGNATURE-


Accepted:
gcc-snapshot_20060530-1.dsc
  to pool/main/g/gcc-snapshot/gcc-snapshot_20060530-1.dsc
gcc-snapshot_20060530-1.tar.gz
  to pool/main/g/gcc-snapsho

Bug#361602: marked as done (internal compiler error: verify_cgraph_node failed)

[Debian Bug Tracking System]

Your message dated Tue, 30 May 2006 16:47:41 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Accepted gcc-snapshot 20060530-1 (source i386 amd64 powerpc)
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: gcc-snapshot
Version: 20060325-1

Okay, fair enough, the headers are not in the package, but GCC
shouldn't ICE...

| dll_main.cpp:190: internal compiler error: verify_cgraph_node failed


> Automatic build of stlport4.6_4.6.2-3 on em64t by sbuild/amd64 1.112
...
> c++ -pthread -fexceptions -I../stlport -Wall -W -Wno-sign-compare -Wno-unused 
> -Wno-uninitialized -ftemplate-depth-32 -frtti -O2 -fPIC dll_main.cpp -c -o 
> ../lib/obj/GCC/ReleaseD/dll_main.o
> In file included from stlport_prefix.h:28,
>  from dll_main.cpp:29:
> ../stlport/ctime:25:44: error: /usr/include/c++/4.2/ctime: No such file or 
> directory
> In file included from ../stlport/stl/debug/_debug.c:160,
>  from ../stlport/stl/debug/_debug.h:418,
>  from ../stlport/utility:40,
>  from dll_main.cpp:35:
> ../stlport/cstdlib:25:46: error: /usr/include/c++/4.2/cstdlib: No such file 
> or directory
> In file included from ../stlport/stl/debug/_debug.c:237,
>  from ../stlport/stl/debug/_debug.h:418,
>  from ../stlport/utility:40,
>  from dll_main.cpp:35:
> ../stlport/cstdarg:25:46: error: /usr/include/c++/4.2/cstdarg: No such file 
> or directory
> In file included from ../stlport/stl/debug/_debug.c:238,
>  from ../stlport/stl/debug/_debug.h:418,
>  from ../stlport/utility:40,
>  from dll_main.cpp:35:
> ../stlport/cstdio:31:45: error: /usr/include/c++/4.2/cstdio: No such file or 
> directory
> In file included from ../stlport/stl/_alloc.h:31,
>  from ../stlport/memory:32,
>  from dll_main.cpp:38:
> ../stlport/cstddef:35:46: error: /usr/include/c++/4.2/cstddef: No such file 
> or directory
> In file included from ../stlport/stl/_alloc.h:42,
>  from ../stlport/memory:32,
>  from dll_main.cpp:38:
> ../stlport/cstring:25:46: error: /usr/include/c++/4.2/cstring: No such file 
> or directory
> In file included from ../stlport/stl/_new.h:50,
>  from ../stlport/stl/_alloc.h:60,
>  from ../stlport/memory:32,
>  from dll_main.cpp:38:
> ../stlport/new:36:49: error: /usr/include/c++/4.2/new: No such file or 
> directory
> In file included from ../stlport/stl/_tempbuf.h:34,
>  from ../stlport/memory:36,
>  from dll_main.cpp:38:
> ../stlport/climits:27:46: error: /usr/include/c++/4.2/climits: No such file 
> or directory
> In file included from ../stlport/stl/_limits.h:32,
>  from ../stlport/limits:32,
>  from dll_main.cpp:44:
> ../stlport/cfloat:27:45: error: /usr/include/c++/4.2/cfloat: No such file or 
> directory
> In file included from ../stlport/stl/_cwchar.h:21,
>  from ../stlport/stl/_limits.h:36,
>  from ../stlport/limits:32,
>  from dll_main.cpp:44:
> ../stlport/cwchar:36:45: error: /usr/include/c++/4.2/cwchar: No such file or 
> directory
> In file included from ../stlport/stl/_string.h:27,
>  from ../stlport/string:45,
>  from dll_main.cpp:45:
> ../stlport/cctype:26:45: error: /usr/include/c++/4.2/cctype: No such file or 
> directory
> In file included from ../stlport/stdexcept:37,
>  from dll_main.cpp:46:
> ../stlport/exception:60:55: error: /usr/include/c++/4.2/exception: No such 
> file or directory
> In file included from ../stlport/stl/_pthread_alloc.c:37,
>  from ../stlport/stl/_pthread_alloc.h:482,
>  from dll_main.cpp:57:
> ../stlport/cerrno:25:45: error: /usr/include/c++/4.2/cerrno: No such file or 
> directory
> ../stlport/ctime:32: error: '__std_alias::size_t' has not been declared
> ../stlport/ctime:33: error: '__std_alias::clock_t' has not been declared
[lots of errors]
> ../stlport/stl/_algobase.c:156: error: no match for 'operator-' in '__last - 
> __first'
> ../stlport/stl/_algobase.c: In function '_RandomAccessIter 
> _STL::__find_if(_RandomAccessIter, _RandomAccessIter, _Predicate, const 
> _STL::random_access_iterator_tag&) [with _RandomAccessIter = 
> _STL::reverse_iterator, _Predicate = 
> _STL::_Neq_char_bound<_STL::char_traits >]':
> ../stlport/stl/_algobase.c:196:   instantiated 

Bug#366626: marked as done (ICE in build_c_cast, at cp/typeck.c:5443)

[Debian Bug Tracking System]

Your message dated Tue, 30 May 2006 16:47:41 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Accepted gcc-snapshot 20060530-1 (source i386 amd64 powerpc)
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: gcc-snapshot
Version: 20060508-1

The following bug is known already (PR27471) but I'm filing it in the
BTS since it actually shows up when compiling a package in Debian.


> Automatic build of partimage_0.6.4-14 on test.track.rz.uni-augsburg.de by 
> sbuild/powerpc 0.44
...
> g++ -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\" -D_REENTRANT 
> -D_FILE_OFFSET_BITS=64 -I. -I. -I../../.. -I../../.. -I../../../src/client 
> -I../../../src/shared -I/usr/include/slang  -Wno-deprecated 
> -I/usr/include/openssl -Wall  -g -Wall -O2 -c -o fs_jfs.o fs_jfs.cpp
> fs_jfs.cpp: In member function 'int CJfsPart::browseBitmap(QWORD*, xtpage_t*, 
> DWORD, QWORD)':
> fs_jfs.cpp:330: warning: deprecated conversion from string constant to 
> 'char*''
> fs_jfs.cpp: In member function 'virtual void CJfsPart::readSuperBlock()':
> fs_jfs.cpp:487: warning: deprecated conversion from string constant to 
> 'char*''
> fs_jfs.cpp: In function 'void showInodeInfos(CJfsDiskInode)':
> fs_jfs.cpp:527: internal compiler error: in build_c_cast, at cp/typeck.c:5443
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> make[5]: *** [fs_jfs.o] Error 1
> make[5]: Leaving directory `/build/tbm/partimage-0.6.4/src/client/fs'

-- 
Martin Michlmayr
http://www.cyrius.com/

--- End Message ---
--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 30 May 2006 15:54:59 +0200
Source: gcc-snapshot
Binary: gcc-snapshot
Architecture: amd64 i386 powerpc source 
Version: 20060530-1
Distribution: unstable
Urgency: low
Maintainer: Debian GCC Maintainers 
Changed-By: Martin Michlmayr <[EMAIL PROTECTED]>
Description: 
 gcc-snapshot - A SNAPSHOT of the GNU Compiler Collection
Closes: 361441 361591 361602 361814 364394 364591 364602 364622 366626 366939
Changes: 
 gcc-snapshot (20060530-1) unstable; urgency=low
 .
* SVN 20060530, taken from the trunk, revision 114238.
  - PR tree-optimization/27085: ICE in add_virtual_operand, at
tree-ssa-operands.c (closes: #361441).
  - PR tree-optimization/27093: ICE in verify_ssa failed:
definition does not dominate use (closes: #361591).
  - PR middle-end/25776: ICE: verify_cgraph_node failed (closes:
#361602).
  - PR tree-optimization/26490: ICE: tree check: expected ssa_name,
have symbol_memory_tag in is_old_name (closes: #361814).
  - PR c/27273: ICE: tree check: expected class 'constant', have
'binary' (bit_and_expr) in convert_and_check, at c-common.c
(closes: #364591).
  - PR tree-optimization/27548: ICE: SSA corruption: Conflict across
an abnormal edge (closes: #364602).
  - PR c++/27210: ICE: tree check: did not expect class 'type', have
'type' (template_type_parm) in contains_placeholder_p, at tree.c
(closes: #364622).
  - PR c++/27471: ICE in build_c_cast, at cp/typeck.c:5443 (closes:
#366626).
  - PR target/27158 (powerpc): ICE: error in extract_insn, at
recog.c:2084 (see #362307, also present in gcc-4.1).
  - PR target/27571 (alpha): ICE in get_attr_usegp, at
config/alpha/alpha.md:171 (closes: #366939).
* Update ppc64 patch so it builds again.  Thanks, Andreas Jochens
  (closes: #364394).
* Add myself as an uploader.
Files: 
 5c13ef903bbe62b16c730efd04efedc6 37995290 devel standard 
gcc-snapshot_20060530-1.tar.gz
 b1c67a1adfd42b761ffbc7b925e2c4a8 2421 devel standard 
gcc-snapshot_20060530-1.dsc
 75b25dbb6d9b5705ad244f9475f0385e 56658110 devel extra 
gcc-snapshot_20060530-1_i386.deb
 987f439cfac1980f86209830852df975 61639740 devel extra 
gcc-snapshot_20060530-1_amd64.deb
 a25cbb180f357e3c9bb79ad4ab2708e2 62751796 devel extra 
gcc-snapshot_20060530-1_powerpc.deb

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

iD8DBQFEfMeGKb5dImj9VJ8RAtqfAJ0WibiV+Rd80Vh0p/YEUif0nUyoWwCfT6V7
n/fcC5h9QuhinHbZMw6vCD0=
=OjlY
-END PGP SIGNATURE-


Accepted:
gcc-snapshot_20060530-1.dsc
  to pool/main/g/gcc-snapshot/gcc-snapshot_20060530-1.dsc
gcc-snapshot_20060530-1.tar.gz
  to pool/main/g/gcc-snapshot/gcc-snapshot_20060530-1.tar.gz
gcc-snapshot_20060530-1_amd64.deb
  

Bug#364591: marked as done (ICE: tree check: expected class 'constant', have 'binary' (bit_and_expr) in convert_and_check, at c-common.c:1083)

[Debian Bug Tracking System]

Your message dated Tue, 30 May 2006 16:47:41 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Accepted gcc-snapshot 20060530-1 (source i386 amd64 powerpc)
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: gcc-snapshot
Binary: gcc-snapshot
Version: 20060419-1

ICE: tree check: expected class 'constant', have 'binary' (bit_and_expr) in 
convert_and_check, at c-common.c:1083
on powerpc


> Automatic build of lanmap_0.1+svn20060227-3 on test.track.rz.uni-augsburg.de 
> by sbuild/powerpc 0.44
...
> cc -W -Wall -Wno-unused -DLINUX -DLANMAP_DATADIR=/usr/share/lanmap/   -c -o 
> protocols.o protocols.c
> protocols.c: In function 'parse_stp':
> protocols.c:1682: internal compiler error: tree check: expected class 
> 'constant', have 'binary' (bit_and_expr) in convert_and_check, at 
> c-common.c:1083
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> make[2]: *** [protocols.o] Error 1

> Automatic build of gnushogi_1.3-6 on test.track.rz.uni-augsburg.de by 
> sbuild/powerpc 0.44
...
> gcc -Wall -g -O2 -fsigned-char -funroll-loops 
> -DHASHFILE=\"/usr/lib/games/gnushogi.hsh\" -Wall -Wno-implicit-int -I.. -c 
> search.c
> search.c: In function 'search':
> search.c:887: internal compiler error: tree check: expected class 'constant', 
> have 'binary' (bit_and_expr) in convert_and_check, at c-common.c:1083
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> make[2]: *** [search.o] Error 1
> make[2]: Leaving directory `/build/tbm/gnushogi-1.3/gnushogi'
> make[1]: [gnushogi_compile] Error 2 (ignored)

> Automatic build of postgresql-8.1_8.1.3-4 on test.track.rz.uni-augsburg.de by 
> sbuild/powerpc 0.44
...
> cc -g -Wall -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline 
> -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -fpic 
> -I. -I../../src/include -D_GNU_SOURCE  -I/usr/include/tcl8.4  -c -o 
> _int_gist.o _int_gist.c
> _int_gist.c: In function 'g_int_consistent':
> _int_gist.c:40: internal compiler error: tree check: expected class 
> 'constant', have 'binary' (bit_and_expr) in convert_and_check, at 
> c-common.c:1083
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> make[3]: *** [_int_gist.o] Error 1
> make[3]: Leaving directory 
> `/build/tbm/postgresql-8.1-8.1.3/build-tree/postgresql-8.1.3/contrib/intarray'

> Automatic build of xscorch_0.2.0-4 on test.track.rz.uni-augsburg.de by 
> sbuild/powerpc 0.44
...
> gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../sutil -I../libj-g -O2 -c 
> strack.c
> strack.c: In function '_sc_weapon_track':
> strack.c:184: internal compiler error: tree check: expected class 'constant', 
> have 'binary' (bit_and_expr) in convert_and_check, at c-common.c:1083
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> make[3]: *** [strack.o] Error 1
> make[3]: Leaving directory `/build/tbm/xscorch-0.2.0/sgame'


> Automatic build of hercules_3.03.1-1 on test.track.rz.uni-augsburg.de by 
> sbuild/powerpc 0.44
...
>  gcc -DHAVE_CONFIG_H -I. -I. -I. -I. -W -Wall -O2 -MT channel.lo -MD -MP -MF 
> .deps/channel.Tpo -c channel.c  -fPIC -DPIC -o .libs/channel.o
> channel.c: In function 'clear_subchan':
> channel.c:811: internal compiler error: tree check: expected class 
> 'constant', have 'binary' (bit_and_expr) in convert_and_check, at 
> c-common.c:1083
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> make[3]: *** [channel.lo] Error 1


> Automatic build of mednafen_0.5.2-1 on test.track.rz.uni-augsburg.de by 
> sbuild/powerpc 0.44
...
>   powerpc-linux-gnu-g++ -DLOCALEDIR=\"/usr/share/locale\" -DHAVE_CONFIG_H 
> -ffast-math -I../.. -I../../include -I../../intl -I../fidlib   -pthread 
> -DFIDLIB_LINUX -Wall -Winline -fomit-frame-pointer -finline-limit=6000 
> --param large-function-growth=800 --param inline-unit-growth=175 -Wall -O2 
> -Wl,-z,defs -I/usr/include/SDL -D_REENTRANT  -maltivec  -maltivec  -Wall -O2 
> -Wl,-z,defs -c -o cart.o `test -f 'cart.cpp' || echo './'`cart.cpp
> cart.cpp: In function 'void setchr8r(int, unsigned int)':
> cart.cpp:294: internal compiler error: tree check: expected class 'constant', 
> have 'binary' (bit_and_expr) in convert_and_check, at c-

Bug#361441: marked as done (internal compiler error: in add_virtual_operand, at tree-ssa-operands.c)

[Debian Bug Tracking System]

Your message dated Tue, 30 May 2006 16:47:41 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Accepted gcc-snapshot 20060530-1 (source i386 amd64 powerpc)
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: gcc-snapshot
Version: 20060325-1

This is a regression from 4.1:

> Automatic build of vnc4_4.1.1+X4.3.0-4 on em64t by sbuild/amd64 1.112
...
> gcc -O2 -fno-strength-reduce -ansi -pedantic -Wall -Wpointer-arith -Wundef
> -fno-merge-constants -I../../../../../../extras/Mesa/src
> -I../../../../../../extras/Mesa/src/array_cache 
> -I../../../../../../extras/Mesa/src/math
> -I../../../../../../extras/Mesa/src/tnl 
> -I../../../../../../extras/Mesa/include 
> -I../../../../../../programs/Xserver/include 
> -I../../../../../../exports/include/X11 
> -I../../../../../../programs/Xserver/GL/include 
> -I../../../../../../programs/Xserver/GL/glx 
> -I../../../../../../lib/GL/include 
> -I../../../../../../programs/Xserver/hw/xfree86 
> -I../../../../../../exports/include  -I../../../../../.. 
> -I../../../../../../exports/include -I/usr/X11R6/include  -Dlinux 
> -D__x86_64__ -D_POSIX_C_SOURCE=199309L   
> -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE 
> -D_SVID_SOURCE -D_GNU_SOURCE  
>  -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP   -DXCSECURITY -DTOGCUP   
> -DXF86BIGFONT -DDPMSExtension -DPANORAMIX-DRENDER -DRANDR 
> -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH 
> -DXFreeXDGA -DXvExtension   
> -DXFree86LOADER  -DXFree86Server-DXF86VIDMODE 
>   -DXvMCExtension 
> -DSMART_SCHEDULE
> -DBUILDDEBUG -DXResExtension
> -DX_BYTE_ORDER=X_LITTLE_ENDIAN -D_XSERVER64 -DNDEBUG  -DFUNCPROTO=15 
> -DNARROWPROTO  -DIN_MODULE -DXFree86Module -DGLXEXT  -DGLX_USE_MESA 
> -D__GLX_ALIGN64   -c t_array_import.c
> t_array_import.c: In function '_tnl_import_color':
> t_array_import.c:98: internal compiler error: in add_virtual_operand, at 
> tree-ssa-operands.c:1354
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> make[9]: *** [t_array_import.o] Error 1
> rm -f t_context.o

-- 
Martin Michlmayr
http://www.cyrius.com/

--- End Message ---
--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.7
Date: Tue, 30 May 2006 15:54:59 +0200
Source: gcc-snapshot
Binary: gcc-snapshot
Architecture: amd64 i386 powerpc source 
Version: 20060530-1
Distribution: unstable
Urgency: low
Maintainer: Debian GCC Maintainers 
Changed-By: Martin Michlmayr <[EMAIL PROTECTED]>
Description: 
 gcc-snapshot - A SNAPSHOT of the GNU Compiler Collection
Closes: 361441 361591 361602 361814 364394 364591 364602 364622 366626 366939
Changes: 
 gcc-snapshot (20060530-1) unstable; urgency=low
 .
* SVN 20060530, taken from the trunk, revision 114238.
  - PR tree-optimization/27085: ICE in add_virtual_operand, at
tree-ssa-operands.c (closes: #361441).
  - PR tree-optimization/27093: ICE in verify_ssa failed:
definition does not dominate use (closes: #361591).
  - PR middle-end/25776: ICE: verify_cgraph_node failed (closes:
#361602).
  - PR tree-optimization/26490: ICE: tree check: expected ssa_name,
have symbol_memory_tag in is_old_name (closes: #361814).
  - PR c/27273: ICE: tree check: expected class 'constant', have
'binary' (bit_and_expr) in convert_and_check, at c-common.c
(closes: #364591).
  - PR tree-optimization/27548: ICE: SSA corruption: Conflict across
an abnormal edge (closes: #364602).
  - PR c++/27210: ICE: tree check: did not expect class 'type', have
'type' (template_type_parm) in contains_placeholder_p, at tree.c
(closes: #364622).
  - PR c++/27471: ICE in build_c_cast, at cp/typeck.c:5443 (closes:
#366626).
  - PR target/27158 (powerpc): ICE: error in extract_insn, at
recog.c:2084 (see #362307, also present in gcc-4.1).
  - PR target/27571 (alpha): ICE in get

Bug#361591: marked as done (internal compiler error: verify_ssa failed)

[Debian Bug Tracking System]

Your message dated Tue, 30 May 2006 16:47:41 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Accepted gcc-snapshot 20060530-1 (source i386 amd64 powerpc)
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: gcc-snapshot
Version: 20060325-1

internal compiler error: verify_ssa failed:

> Automatic build of mail-notification_2.0.dfsg.1-2 on em64t by sbuild/amd64 
> 1.112
...
> cc -DHAVE_CONFIG_H -I. -I. -I..   -pthread -DORBIT2=1 -DXTHREADS 
> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gconf/2 
> -I/usr/include/orbit-2.0 -I/usr/include/libgnomeui-2.0 
> -I/usr/include/libgnome-2.0 -I/usr/include/libgnomecanvas-2.0 
> -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 
> -I/usr/include/libbonoboui-2.0 -I/usr/include/gnome-vfs-2.0 
> -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gnome-keyring-1 
> -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 
> -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include 
> -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/X11R6/include 
> -I/usr/include/libxml2 -I/usr/include/libglade-2.0 -I/usr/include/eel-2 
> -I/usr/include/gail-1.0   -I/usr/include/gmime-2.0 -I/usr/include/glib-2.0 
> -I/usr/lib/glib-2.0/include -I.. -DPREFIX="\"/usr\"" 
> -DSYSCONFDIR="\"/etc\"" -DDATADIR="\"/usr/share\"" -DLIBDIR="\"/usr/lib\"" 
> -DGNOMELOCALEDIR="\"/usr/share/locale\"" 
> -DGNOMEPIXMAPSDIR="\"/usr/share/pixmaps\"" 
> -DUIDIR="\"/usr/share/mail-notification/ui\"" 
> -DG_LOG_DOMAIN="\"mail-notification\""   -g -Wall -O2 -c -o 
> mail_notification-mn-imap-mailbox-properties.o `test -f 
> 'mn-imap-mailbox-properties.c' || echo './'`mn-imap-mailbox-properties.c
> cc -DHAVE_CONFIG_H -I. -I. -I..   -pthread -DORBIT2=1 -DXTHREADS 
> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gconf/2 
> -I/usr/include/orbit-2.0 -I/usr/include/libgnomeui-2.0 
> -I/usr/include/libgnome-2.0 -I/usr/include/libgnomecanvas-2.0 
> -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 
> -I/usr/include/libbonoboui-2.0 -I/usr/include/gnome-vfs-2.0 
> -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gnome-keyring-1 
> -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 
> -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include 
> -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/X11R6/include 
> -I/usr/include/libxml2 -I/usr/include/libglade-2.0 -I/usr/include/eel-2 
> -I/usr/include/gail-1.0   -I/usr/include/gmime-2.0 -I/usr/include/glib-2.0 
> -I/usr/lib/glib-2.0/include -I.. -DPREFIX="\"/usr\"" 
> -DSYSCONFDIR="\"/etc\"" -DDATADIR="\"/usr/share\"" -DLIBDIR="\"/usr/lib\"" 
> -DGNOMELOCALEDIR="\"/usr/share/locale\"" 
> -DGNOMEPIXMAPSDIR="\"/usr/share/pixmaps\"" 
> -DUIDIR="\"/usr/share/mail-notification/ui\"" 
> -DG_LOG_DOMAIN="\"mail-notification\""   -g -Wall -O2 -c -o 
> mail_notification-mn-imap-mailbox.o `test -f 'mn-imap-mailbox.c' || echo 
> './'`mn-imap-mailbox.c
> cc -DHAVE_CONFIG_H -I. -I. -I..   -pthread -DORBIT2=1 -DXTHREADS 
> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gconf/2 
> -I/usr/include/orbit-2.0 -I/usr/include/libgnomeui-2.0 
> -I/usr/include/libgnome-2.0 -I/usr/include/libgnomecanvas-2.0 
> -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 
> -I/usr/include/libbonoboui-2.0 -I/usr/include/gnome-vfs-2.0 
> -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gnome-keyring-1 
> -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 
> -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include 
> -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/X11R6/include 
> -I/usr/include/libxml2 -I/usr/include/libglade-2.0 -I/usr/include/eel-2 
> -I/usr/include/gail-1.0   -I/usr/include/gmime-2.0 -I/usr/include/glib-2.0 
> -I/usr/lib/glib-2.0/include -I.. -DPREFIX="\"/usr\"" 
> -DSYSCONFDIR="\"/etc\"" -DDATADIR="\"/usr/share\"" -DLIBDIR="\"/usr/lib\"" 
> -DGNOMELOCALEDIR="\"/usr/share/locale\"" 
> -DGNOMEPIXMAPSDIR="\"/usr/share/pixmaps\"" 
> -DUIDIR="\"/usr/share/mail-notification/ui\"" 
> -DG_LOG_DOMAIN="\"mail-notification\""   -g -Wall -O2 -c -o 
> mail_notification-mn-authenticated-mailbox-properties.o `test -f 
> 'mn-authenticated-mailbox-properties.c' || echo 
> './'`mn-authenticated-mailbox-properties.c
> cc -DHAVE_CONFIG_H -I. -I. -I..   -pthread -DORBIT2=1 -DXTHREADS 
> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gconf/2 
> -I/usr/include/orbit-2.0 -I/usr/include/libgnomeui-2.0 
> -I/usr/include/libgnome-2.0 -I/usr/in

Bug#364622: marked as done (ICE: tree check: did not expect class 'type', have 'type' (template_type_parm) in contains_placeholder_p, at tree.c:2139)

[Debian Bug Tracking System]

Your message dated Tue, 30 May 2006 16:47:41 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Accepted gcc-snapshot 20060530-1 (source i386 amd64 powerpc)
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: gcc-snapshot
Version: 20060419-1

> Automatic build of xmahjongg_3.7-1.1 on test.track.rz.uni-augsburg.de by 
> sbuild/powerpc 0.44
...
> if g++ -Wall -DHAVE_CONFIG_H -I. -I. -I..  -I../include-g -O2 -MT 
> straccum.o -MD -MP -MF ".deps/straccum.Tpo" -c -o straccum.o straccum.cc; \
>   then mv -f ".deps/straccum.Tpo" ".deps/straccum.Po"; else rm -f 
> ".deps/straccum.Tpo"; exit 1; fi
> ../include/lcdf/vector.cc: In member function 'bool Vector::reserve(int)':
> ../include/lcdf/vector.cc:89: internal compiler error: tree check: did not 
> expect class 'type', have 'type' (template_type_parm) in 
> contains_placeholder_p, at tree.c:2139
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> make[3]: *** [straccum.o] Error 1


> Automatic build of ragel_5.3-1 on test.track.rz.uni-augsburg.de by 
> sbuild/powerpc 0.44
...
> g++ -c -g -Wall -O2  -I../common -I../aapl -o parsedata.o parsedata.cpp
> ../aapl/mergesort.h: In member function 'void MergeSort::sort(T*, 
> long int)':
> ../aapl/mergesort.h:131: internal compiler error: tree check: did not expect 
> class 'type', have 'type' (template_type_parm) in contains_placeholder_p, at 
> tree.c:2139
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> make[2]: *** [parsedata.o] Error 1

> Automatic build of lcdf-typetools_2.36-1 on test.track.rz.uni-augsburg.de by 
> sbuild/powerpc 0.44
...
> Fetching source files...
> Reading package lists...
> Building dependency tree...
> Need to get 506kB of source archives.
> Get:1 http://ftp.de.debian.org sid/main lcdf-typetools 2.36-1 (dsc) [624B]
> Get:2 http://ftp.de.debian.org sid/main lcdf-typetools 2.36-1 (tar) [476kB]
> Get:3 http://ftp.de.debian.org sid/main lcdf-typetools 2.36-1 (diff) [28.9kB]
> Fetched 506kB in 1s (472kB/s)
> Download complete and in download only mode
> ** Using build dependencies supplied by package:
> Build-Depends: debhelper (>> 4.0.0), libkpathsea-dev (>= 2.0.2-4), dpatch
> Checking for already installed source dependencies...
> debhelper: missing
> libkpathsea-dev: missing
> dpatch: missing
> Checking for source dependency conflicts...
> Reading package lists...
> Building dependency tree...
> The following extra packages will be installed:
>   gettext html2text intltool-debian libkpathsea4 po-debconf
> Suggested packages:
>   dh-make curl cvs gettext-doc
> Recommended packages:
>   patchutils libmail-sendmail-perl libcompress-zlib-perl
> The following NEW packages will be installed:
>   debhelper dpatch gettext html2text intltool-debian libkpathsea-dev
>   libkpathsea4 po-debconf
> 0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
> Need to get 80.1kB/2805kB of archives.
> After unpacking 8561kB of additional disk space will be used.
> WARNING: The following packages cannot be authenticated!
>   html2text gettext intltool-debian po-debconf debhelper dpatch libkpathsea4
>   libkpathsea-dev
> Authentication warning overridden.
> Get:1 http://ftp.de.debian.org sid/main libkpathsea-dev 3.0-16 [80.1kB]
> Fetched 80.1kB in 0s (130kB/s)
> Selecting previously deselected package html2text.
> (Reading database ... 14693 files and directories currently installed.)
> Unpacking html2text (from .../html2text_1.3.2a-3_powerpc.deb) ...
> Selecting previously deselected package gettext.
> Unpacking gettext (from .../gettext_0.14.5-2_powerpc.deb) ...
> Selecting previously deselected package intltool-debian.
> Unpacking intltool-debian (from .../intltool-debian_0.34.2+20060415_all.deb) 
> ...
> Selecting previously deselected package po-debconf.
> Unpacking po-debconf (from .../po-debconf_1.0_all.deb) ...
> Selecting previously deselected package debhelper.
> Unpacking debhelper (from .../debhelper_5.0.32_all.deb) ...
> Selecting previously deselected package dpatch.
> Unpacking dpatch (from .../archives/dpatch_2.0.19_all.deb) ...
> Selecting previously deselected package libkpathsea4.
> Unpacking libkpathsea4 (from .../libkpathsea4_3.0-16_powerpc.deb) ...
> Selecting previously deselected package libkpathsea-dev.
> Unpacking libkpathsea-dev (from .../libkpathsea-dev_3.0-16_powerpc.deb) ...
> Setting up html2text (1.3.2a-3) ...
> 
> Sett

Re: id gives conflicting results

[Stephen Gran]

This one time, at band camp, Juha Jäykkä said:
> > The issue is with pam_group and /etc/security/group.conf.
> How can I debug this further? I don't know how the kernel checks the
> permissions, since apparently the output of "id" and what groups the
> kernel thinks the user belongs to, differ. Perhaps tweaking
> nsswitch.conf might help?

Doubtful.  Several things might cause this behavior (slow slapd timing
out, nscd caching bad information, group queries set up wrong), but it's
hard to say.  The fact that it's so random leads me to believe it's
something like a slapd timeout.

Good luck,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: glibc built with gcc-4.1 (update)

[Roger Leigh]

Ingo Juergensmann <[EMAIL PROTECTED]> writes:

> On Tue, May 30, 2006 at 05:52:43PM +0200, Ingo Juergensmann wrote:
>> akire:/build/glibc/glibc-2.3.6# dpkg-buildpackage -rfakeroot | tee
>> ../glibc-build-2006-05-30.log
>> dpkg-source: building glibc in glibc_2.3.6-7+gcc41.diff.gz
>> ...
>> So, it's on its way... ;)
>
> It failed (again):
> gcc-4.1 ../sysdeps/m68k/fpu/s_isinf.c -c -std=gnu99 -O2 -Wall -Winline
> -Wstrict-prototypes -Wwrite-strings -fstrict-aliasin
> g -g -pipe -Wno-uninitialized -D__NO_MATH_INLINES
> -D__LIBC_INTERNAL_MATH_INLINES -I../include -I. -I/build/glibc/glibc-
> 2.3.6/build-tree/m68k-libc/math -I.. -I../libio
> -I/build/glibc/glibc-2.3.6/build-tree/m68k-libc -I../sysdeps/m68k/elf -I..
> /libidn/sysdeps/unix -I../linuxthreads/sysdeps/unix/sysv/linux/m68k
> -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthr
> eads/sysdeps/pthread -I../sysdeps/pthread
> -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix
> -I../linuxthre
> ads/sysdeps/m68k -I../sysdeps/unix/sysv/linux/m68k
> -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -
> I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv
> -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/m68k/
> m68020 -I../sysdeps/m68k/fpu -I../sysdeps/m68k -I../sysdeps/wordsize-32
> -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/d
> bl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754
> -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem /us
> r/lib/gcc/m68k-linux-gnu/4.1.0/include -isystem
> /build/glibc/glibc-2.3.6/debian/include -D_LIBC_REENTRANT -include ../inclu
> de/libc-symbols.h   -o
> /build/glibc/glibc-2.3.6/build-tree/m68k-libc/math/s_isinf.o -MD -MP -MF
> /build/glibc/glibc-2.3.
> 6/build-tree/m68k-libc/math/s_isinf.o.dt -MT
> /build/glibc/glibc-2.3.6/build-tree/m68k-libc/math/s_isinf.o
> In file included from ../math/math.h:382,
>  from ../include/math.h:3,
>  from ../sysdeps/m68k/fpu/s_isinf.c:19:
> ../sysdeps/m68k/fpu/bits/mathinline.h:128: error: expected ',' or ';' before
> '{' token
> [ lots of those lines deleted ]
> ../sysdeps/m68k/fpu/bits/mathinline.h:249: error: expected ',' or ';' before
> '{' token
> ../sysdeps/m68k/fpu/bits/mathinline.h:249: error: expected ',' or ';' before
> '{' token
> ../sysdeps/m68k/fpu/bits/mathinline.h:249: error: expected ',' or ';' before
> '{' token
> ../sysdeps/m68k/fpu/bits/mathinline.h:250: error: expected ',' or ';' before
> '{' token

You've probably hit #340871: [m68k] packages ftbfs due to mathinline.h
in libc6-dev.  I posted a patch there, but it needs someone with both
m68k glibc knowledge to complete the work.


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.


pgpkS7km0trhV.pgp
Description: PGP signature

Re: id gives conflicting results

[Juha Jäykkä]

> The issue is with pam_group and /etc/security/group.conf.

I doubt that: /etc/security/group.conf is empty (apart from comments).

I have been tinkering with this every now and then and the problem won't
go away. It even seems to manifest itself at random!

For example, I created a user "testuser" for this purpose. It has no
local accounts anywhere (not even a matching uid), so it's a completely
LDAP-based user. On one machine (call it A) the user can
read /var/log/syslog, on another it cannot (call it B). On A, if the
user logs into a VT, it can read /var/log/sysl with and without an OpenAFS
PAG; when logged into X (always with a PAG), he can read it, too. But
when using ssh to log into A from the VT, suddlenly the user cannot read
the log any longer! However, logging in with ssh from B, the user CAN
read the log. Also, with the two users I observed this earlier, there
does not seem to be any logic what so ever, which user can read which
files and when.

How can I debug this further? I don't know how the kernel checks the
permissions, since apparently the output of "id" and what groups the
kernel thinks the user belongs to, differ. Perhaps tweaking nsswitch.conf
might help? Currently, the relevant part is

passwd: ldap [SUCCESS=return] compat
group:  ldap [SUCCESS=return] compat

(I also tested with SUCCESS=continue on both lines.)

-Juha

-- 
 ---
| Juha Jäykkä, [EMAIL PROTECTED]|
| Laboratory of Theoretical Physics |
| Department of Physics, University of Turku|
| home: http://www.utu.fi/~juolja/  |
 ---


signature.asc
Description: PGP signature

Processed: Re: Bug#322762: marked as done (/usr/doc still exists (transition tracking bug))

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reopen 322762
Bug#322762: /usr/doc still exists (transition tracking bug)
'reopen' is deprecated when a bug has been closed with a version;
use 'found' or 'submitter' as appropriate instead.
Bug reopened, originator not changed.

> thanks [EMAIL PROTECTED] BCC'd
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: apt-update-stat.pl analyse changes in Debian software repository

[Liu Yubao]

You can run this script, it won't mess up your dpkg/apt state.
run "perl apt-update-stat.pl" for help.

Because indirect circular dependence is not handled properly, libc gets a
rdepends_score -1000, I don't know why there is circular dependence
and how to deal with it. Can anybody give an explanation?

And notice I don't consider source packages, the default score setting
in calculate_score() subroutine is probably not proper.

Here is part of output from "apt-update-stat.pl stat" for Ubuntu dapper:
libxrender122  10358   77736015
libfreetype6   22   1142   54685778
libxfixes3 22  14735   34401220
libxcursor122  35495   31797406
libfontenc121   5519   28837607
xcursorgen 21  57419   28809897
xfonts-utils   21   7846   28805163
makedepend 21520   28804515
sessreg21520   28804494
imake  21   1061   28804494
xutils 21  66930   28804473
libglib2.0-0   22520   26218863
libexpat1  22520   14510631
ttf-bitstream-vera 21   8609   14402688
wget   80   4985   14402265
ttf-freefont   21   8609   14400823
ttf-dejavu 21   8609   14399230
gsfonts-x1121  75580   14397858
cabextract 20520   14397738
msttcorefonts  20  84551   14397718
fontconfig 20 117502   14397698
libfontconfig1 22 120370   14083273
libxml222   11426403433
libcairo2  22 1440805268249
libdbus-1-2205205136055
libidl022   16025059538
liborbit2  22   32714993344
python2.4-minimal 100   11423786344
libxft222 1429163085262
libxinerama1   22  344113018898
libxrandr2 22  447913002039
libpango1.0-0  22 9915942631011
gconf2-common  22   32812595071
libatk1.0-022   10622592025
libbz2-1.0 625202540732
readline-common65  02350099
libreadline5   62   12102349237
python2.4  60   99102038896
libhal122   10602002538
libgconf2-422   94441826844
libavahi-common-data   22  01772631
libavahi-common3   225421772549

2006/5/31, Matt Taggart <[EMAIL PROTECTED]>:


"Liu Yubao" writes...

> The little Perl script can calculate how heavy a package depends on other
> packages and is depended by other packages, they are depicted by
> depends_score and rdepends_score.

With the help of Brendan O'Dea I wrote something similar a while back as a way
of determining the most depended upon packages as part of an exercise to
determine the most important things for the Linux Standard Base to standardize.
The script and result are at,

 http://freestandards.org/futures/identification/depends/

In particular the annotated output is sorta interesting (but out of date now,
I should re-run it at some point).

Have you published output from your tool anywhere?

--
Matt Taggart
[EMAIL PROTECTED]






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

Re: glibc built with gcc-4.1 (update)

[Ingo Juergensmann]

On Tue, May 30, 2006 at 05:52:43PM +0200, Ingo Juergensmann wrote:
> 
> > >I tried it on akire, but was interrupted by real world issues. 
> > >When you could give a more detailed HowTo (sbuild, dpkg-buildpackage,
> > >whatever) I would retry... 
> > Very easy:
> > dget http://people.debian.org/~aurel32/glibc/glibc_2.3.6-7+gcc41.dsc
> > dpkg-source -x glibc_2.3.6-7+gcc41.dsc
> > cd glibc-2.3.6
> > debuild or dpkg-buildpackage -rfakeroot
> > and wait a long time...
> 
> akire:/build/glibc/glibc-2.3.6# dpkg-buildpackage -rfakeroot | tee
> ../glibc-build-2006-05-30.log
> dpkg-source: building glibc in glibc_2.3.6-7+gcc41.diff.gz
> ...
> So, it's on its way... ;)

It failed (again):
gcc-4.1 ../sysdeps/m68k/fpu/s_isinf.c -c -std=gnu99 -O2 -Wall -Winline
-Wstrict-prototypes -Wwrite-strings -fstrict-aliasin
g -g -pipe -Wno-uninitialized -D__NO_MATH_INLINES
-D__LIBC_INTERNAL_MATH_INLINES -I../include -I. -I/build/glibc/glibc-
2.3.6/build-tree/m68k-libc/math -I.. -I../libio
-I/build/glibc/glibc-2.3.6/build-tree/m68k-libc -I../sysdeps/m68k/elf -I..
/libidn/sysdeps/unix -I../linuxthreads/sysdeps/unix/sysv/linux/m68k
-I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthr
eads/sysdeps/pthread -I../sysdeps/pthread
-I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix
-I../linuxthre
ads/sysdeps/m68k -I../sysdeps/unix/sysv/linux/m68k
-I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -
I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv
-I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/m68k/
m68020 -I../sysdeps/m68k/fpu -I../sysdeps/m68k -I../sysdeps/wordsize-32
-I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/d
bl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754
-I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem /us
r/lib/gcc/m68k-linux-gnu/4.1.0/include -isystem
/build/glibc/glibc-2.3.6/debian/include -D_LIBC_REENTRANT -include ../inclu
de/libc-symbols.h   -o
/build/glibc/glibc-2.3.6/build-tree/m68k-libc/math/s_isinf.o -MD -MP -MF
/build/glibc/glibc-2.3.
6/build-tree/m68k-libc/math/s_isinf.o.dt -MT
/build/glibc/glibc-2.3.6/build-tree/m68k-libc/math/s_isinf.o
In file included from ../math/math.h:382,
 from ../include/math.h:3,
 from ../sysdeps/m68k/fpu/s_isinf.c:19:
../sysdeps/m68k/fpu/bits/mathinline.h:128: error: expected ',' or ';' before
'{' token
[ lots of those lines deleted ]
../sysdeps/m68k/fpu/bits/mathinline.h:249: error: expected ',' or ';' before
'{' token
../sysdeps/m68k/fpu/bits/mathinline.h:249: error: expected ',' or ';' before
'{' token
../sysdeps/m68k/fpu/bits/mathinline.h:249: error: expected ',' or ';' before
'{' token
../sysdeps/m68k/fpu/bits/mathinline.h:250: error: expected ',' or ';' before
'{' token
make[3]: *** [/build/glibc/glibc-2.3.6/build-tree/m68k-libc/math/s_isinf.o]
Error 1
make[3]: Leaving directory
/build/glibc/glibc-2.3.6/build-tree/glibc-2.3.6/math'
make[2]: *** [math/subdir_lib] Error 2
make[2]: Leaving directory /build/glibc/glibc-2.3.6/build-tree/glibc-2.3.6'
make[1]: *** [all] Error 2
make[1]: Leaving directory /build/glibc/glibc-2.3.6/build-tree/m68k-libc'

Full logs are available at:
http://www.buildd.net/files/glibc-build-2006-05-30.log
http://www.buildd.net/files/glibc-build-2006-05-30_2.log

-- 
Ciao...//Fon: 0381-2744150 
  Ingo   \X/ SIP: [EMAIL PROTECTED]

gpg pubkey: http://www.juergensmann.de/ij/public_key.asc


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

Re: apt-update-stat.pl analyse changes in Debian software repository

[Matt Taggart]

"Liu Yubao" writes...

> The little Perl script can calculate how heavy a package depends on other
> packages and is depended by other packages, they are depicted by
> depends_score and rdepends_score.

With the help of Brendan O'Dea I wrote something similar a while back as a way 
of determining the most depended upon packages as part of an exercise to 
determine the most important things for the Linux Standard Base to standardize.
The script and result are at,

  http://freestandards.org/futures/identification/depends/

In particular the annotated output is sorta interesting (but out of date now, 
I should re-run it at some point).

Have you published output from your tool anywhere?

-- 
Matt Taggart
[EMAIL PROTECTED]



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