Re: mplayer in debian ( versus new-maintainer )
On Tue, Oct 29, 2002 at 08:52:46PM +0100, Dariush Pietrzak wrote: > Until now I've been preparing pure-gpl version of mplayer as advised by > debian-legal, and that version have been sent to Andrea. Now that divx4 > problem have been resolved, I can drop that tree and send the real thing;) Careful, this is the fourth time now that they've claimed that problem has been "resolved". Once they were lying, and twice they were wrong. Ignore anything that the mplayer authors produced; you need to find a copy of *that code* from the copyright holder that has a GPL license attached. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -><- | London, UK -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
s390 build
The buildd logs for my package, aplus-fsf, show a failure to build on the s390 due to a compile error. I logged on to trex and attempted to build it in the unstable chroot. It built without error. Then I noticed that the error in the buildd log referred to a file /usr/include/c++/3.2/backward/new.h. The "3.2" made me think that the 3.2 compiler was being used instead of the 2.95.4, but I found that the installed version of c++ is in fact 2.95.4 (c++ --version). What is the build-essential compiler on s390? If it is 3.2, should I expect it to be installed in the unstable chroot? -- Neil L. Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
how becoming maintainer
Hello! I'm a young french developer and user of debian (linux is my great passion) I'd like to work (and so learn it)on the maintaining of packages.So, i think it's a good way to go into the project and learn. Tell me if it is possible and what i have to do! and how! thank you very much sincerely sam -- Samuel Desseaux 01j, square des ormes 59510 Hem France tél:03.20.80.12.62 mobile:06.80.96.67.27 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how becoming maintainer
samuel desseaux <[EMAIL PROTECTED]> writes: > Hello! > > I'm a young french developer and user of debian (linux is my great passion) > > I'd like to work (and so learn it)on the maintaining of packages.So, i think > it's a good way to go into the project and learn. > Tell me if it is possible and what i have to do! and how! You first have to read the doc, and to learn how to read doc. See http://www.debian.org/devel/ -- Rémi Vanicat [EMAIL PROTECTED] http://dept-info.labri.u-bordeaux.fr/~vanicat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Advice needed for new Debian packages (SNA for Linux)
Dear Mentors, currently I'm preparing "Linux-SNA", found at www.linux-sna.org to fit into some Debian packages. Eduard Bloch ([EMAIL PROTECTED], CC:) and I, too, things this could be matter of public interest. So my question is: whats needed to get the packages verified and uploaded? Should I become maintainer of the packages if Debian agrees to upload them? Best regards Erik. -- Erik Weber phone: +49 160 55 11 893 Beratender Ingenieur PSF 10 33 49, 68 033 Mannheim pgp key ID: CA709381 EMail: [EMAIL PROTECTED] pgp key fingerprint: ABD7 4B13 02C8 21A2 6938 61BD FC20 9960 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian development
You may be interested in taking over the fcron package when you become a developer. Having the upstream and the Debian maintainer in the same country wouldn't do any harm, I don't plan on maintaining fcron long-term and I'm not sure whether Henrique wants it back when I'm finished with it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mplayer in debian ( versus new-maintainer )
Hi Dariush On Tue, Oct 29, 2002 at 08:52:46PM +0100, Dariush Pietrzak wrote: > Hello, > I am supposed to upload mplayer to debian, however there is quite a lagg > between me and my sponsor (Andrea Mennucc), and some problems with yes, it seems that sometimes the e-mail you send me or e-mail I send you get lost; indeed I haven't heard from you for quite a long time. > transferring larger files to him ( i.e. media packages that will follow > mplayer package - mplayer-fonts and mplayer-skins, are quite large and > it sometimes takes some time until we synchronize our versions ). I just found out, a few days ago, that the new mail server in this institution will silently drop e-mails that exceed a built-in limit; if you have sent me big files in the last 4 months and I never got back, it means we have to find another way. Example solutions: 1) split the big files using the 'split' command and send me the pieces. Example for sending aa.tar.gz : $ split -b 200k aa.tar.gz aa.tar.gz.pieces. $ for i in aa.tar.gz.pieces.* ; do echo $i | mutt [EMAIL PROTECTED] -a $i ; done $ rm aa.tar.gz.pieces.* If you don't have mutt you can use $ for i in aa.tar.gz.pieces.* ; do uuencode $i $i | mail [EMAIL PROTECTED] ; done 2) You should upload your public gpg key to a gpg server, and send me a copy; then I will send you crypted info on how you can send me very large files (basically, I will create you an account you can rsync to). Actually, you should send me a public gpg key nonetheless, and sign any package that you wish that I send into Debian > Until now I've been preparing pure-gpl version of mplayer as advised by > debian-legal, and that version have been sent to Andrea. Now that divx4 > problem have been resolved, I can drop that tree and send the real > thing;) I would love to try it; the version you sent to me in april crashed on some divx files > So I figured that I'd speed up my entrance into Debian,... you should absolutely try to get into Debian anyway; this will give you direct control on the forthcoming mplayer packages. see you soon a. -- Andrea Mennucc "E' un mondo difficile. Che vita intensa!" (Tonino Carotone) msg07684/pgp0.pgp Description: PGP signature
Re: Debian development
On Wed, 30 Oct 2002, Russell Coker wrote: > You may be interested in taking over the fcron package when you become a > developer. > > Having the upstream and the Debian maintainer in the same country wouldn't do > any harm, I don't plan on maintaining fcron long-term and I'm not sure > whether Henrique wants it back when I'm finished with it. I like fcron a lot, but I really lack the time to properly take care of it. So, I would not be opposed of someone else taking fcron over, as long as whomever does it meets my minimum requirements, which are: 1. you do test stuff before you upload. 2. you do test stuff before you upload. 3. you do test stuff before you upload. 4. you don't trust stuff from upstream before you look it over (fcron upstream is rather good, so this is not usually a problem... still, it pays to be doubly paranoid over something such as a crontab dispatcher). 5. you do test stuff before you upload. ...and... 6. you don't stick rm -rf $something-not-quote-safe in maintainer scripts. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
build failures & compiler versions
Hello all,
I am maintaining a package that fails to build on alpha, hppa, and s390.
It appears that the problem is that those architectures use gcc/g++-3.0,
rather than 2.95, as the default compiler. The source would need to be
modified (not hugely, perhaps) to compile with gcc/g++-3.0.
This package also uses the KDE2/Qt2 environment, which I know is due to
be replaced in unstable. Upstream has written a version that is ported
over to KDE3/Qt3, and I believe, gcc/g++-3.0.
I understand that KDE3 is being held up from moving into sid because of
hold-ups with changing to gcc-3.x. Am I correct in this?
So now I have, I guess, two questions. Does anyone know how long it is
expected to be before the new default compiler and KDE3 move into sid?
If it is expected to be relatively shortly, I will concentrate my
efforts on the new version.
The other question is, is this acceptable - that is, can I allow a build
failure on three architectures for a few {weeks,days}, or is that just
deemed too lazy? My personal feeling is that if the new compiler and
KDE3 aren't due in sid within about two weeks, I should go ahead and try
to deal with the source changes. This involves a fair amount of
research for me, so I wanted to ask other's opinions before I started
mucking about with it.
TIA,
Steve
--
What's another word for "thesaurus"?
-- Steven Wright
msg07686/pgp0.pgp
Description: PGP signature
Re: build failures & compiler versions
On Wed, Oct 30, 2002 at 12:08:53PM -0500, Stephen Gran wrote:
> I am maintaining a package that fails to build on alpha, hppa, and s390.
> It appears that the problem is that those architectures use gcc/g++-3.0,
> rather than 2.95, as the default compiler. The source would need to be
> modified (not hugely, perhaps) to compile with gcc/g++-3.0.
The default compiler on alpha is still gcc 2.95, to the best of my
knowledge. If the autobuilders are using 3.x, this is not reflected in
the default package layout for the architecture.
There is another issue, which is that g++ 2.95 is fairly *broken* on
alphas, and you need to disable optimization by compiling with -O0 to get
most complex C++ code to compile on that arch. For further information
on enabling compile options on an arch-dependent basis, see the rules
file for unixodbc, for example.
> This package also uses the KDE2/Qt2 environment, which I know is due to
> be replaced in unstable. Upstream has written a version that is ported
> over to KDE3/Qt3, and I believe, gcc/g++-3.0.
> I understand that KDE3 is being held up from moving into sid because of
> hold-ups with changing to gcc-3.x. Am I correct in this?
I believe the g++ migration is now the only thing we're waiting on for
KDE3.
> So now I have, I guess, two questions. Does anyone know how long it is
> expected to be before the new default compiler and KDE3 move into sid?
> If it is expected to be relatively shortly, I will concentrate my
> efforts on the new version.
> The other question is, is this acceptable - that is, can I allow a build
> failure on three architectures for a few {weeks,days}, or is that just
> deemed too lazy? My personal feeling is that if the new compiler and
> KDE3 aren't due in sid within about two weeks, I should go ahead and try
> to deal with the source changes. This involves a fair amount of
> research for me, so I wanted to ask other's opinions before I started
> mucking about with it.
Various people have stated an intention to make gcc 3.x (for x >= 2) the
default compiler for sarge. If upstream already has a new version of the
package that works with g++ 3.x and KDE3, I wouldn't recommend that you
spend a lot of time trying to get your current version of the package to
work with gcc 3.x -- especially since, on alpha at least, you *can't*
compile Qt-based packages using g++ 3.x.
If you have some time and energy to devote to the matter, I would suggest
talking with the toolchain maintainers about whether there's anything you
could do to help get the gcc 3.x transition moving forward.
Steve Langasek
postmodern programmer
msg07687/pgp0.pgp
Description: PGP signature
Re: build failures & compiler versions
Stephen Gran <[EMAIL PROTECTED]> writes:
> Hello all,
>
> I am maintaining a package that fails to build on alpha, hppa, and s390.
> It appears that the problem is that those architectures use gcc/g++-3.0,
> rather than 2.95, as the default compiler. The source would need to be
> modified (not hugely, perhaps) to compile with gcc/g++-3.0.
>
> This package also uses the KDE2/Qt2 environment, which I know is due to
> be replaced in unstable. Upstream has written a version that is ported
> over to KDE3/Qt3, and I believe, gcc/g++-3.0.
>
> I understand that KDE3 is being held up from moving into sid because of
> hold-ups with changing to gcc-3.x. Am I correct in this?
Yep.
> So now I have, I guess, two questions. Does anyone know how long it is
> expected to be before the new default compiler and KDE3 move into sid?
> If it is expected to be relatively shortly, I will concentrate my
> efforts on the new version.
The Qt3 maintainer told me yesterday that he plans to upload Qt3.1
compiled with g++-3.2 within a week. I assume KDE 3 would follow
shortly.
> The other question is, is this acceptable - that is, can I allow a build
> failure on three architectures for a few {weeks,days}, or is that just
> deemed too lazy? My personal feeling is that if the new compiler and
> KDE3 aren't due in sid within about two weeks, I should go ahead and try
> to deal with the source changes. This involves a fair amount of
> research for me, so I wanted to ask other's opinions before I started
> mucking about with it.
You could just change the Architecture: field in the control file to not
attempt to build on the broken arches, for now.
--
People said I was dumb, but I proved them!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: build failures & compiler versions
This one time, at band camp, Steve Langasek said: > On Wed, Oct 30, 2002 at 12:08:53PM -0500, Stephen Gran wrote: > > I am maintaining a package that fails to build on alpha, hppa, and > > s390. It appears that the problem is that those architectures use > > gcc/g++-3.0, rather than 2.95, as the default compiler. The source > > would need to be modified (not hugely, perhaps) to compile with > > gcc/g++-3.0. > > The default compiler on alpha is still gcc 2.95, to the best of my > knowledge. If the autobuilders are using 3.x, this is not reflected > in the default package layout for the architecture. This was, admittedly, a guess, as I have no access to the machines. The log files all show the same errors, and as I know hppa uses gcc-3.0, I assumed the others did as well. > There is another issue, which is that g++ 2.95 is fairly *broken* on > alphas, and you need to disable optimization by compiling with -O0 to > get most complex C++ code to compile on that arch. For further > information on enabling compile options on an arch-dependent basis, > see the rules file for unixodbc, for example. I didn't know you could do this, but that's very helpful. I will look into this, if the migration is expected to take some time. > I believe the g++ migration is now the only thing we're waiting on for > KDE3. That was my understanding as well. Do you know the timeframe that this is expected to take? > Various people have stated an intention to make gcc 3.x (for x >= 2) > the default compiler for sarge. If upstream already has a new version > of the package that works with g++ 3.x and KDE3, I wouldn't recommend > that you spend a lot of time trying to get your current version of the > package to work with gcc 3.x -- especially since, on alpha at least, > you *can't* compile Qt-based packages using g++ 3.x. Hmmm . . . that's problematic. Do you know if Qt3 and gcc-3.0 will play nicely on alpha? I have no experience with architectures other than i386. Google, here I come (^8. > Steve Langasek > postmodern programmer Thanks, Steve -- A list is only as strong as its weakest link. -- Don Knuth msg07689/pgp0.pgp Description: PGP signature
Re: build failures & compiler versions
On Wed, Oct 30, 2002 at 10:25:09AM -0800, Brian Nelson wrote: > You could just change the Architecture: field in the control file to not > attempt to build on the broken arches, for now. Don't discriminate against architectures because of a temporary build failure. Steve Langasek postmodern programmer msg07690/pgp0.pgp Description: PGP signature
Re: build failures & compiler versions
On Wed, Oct 30, 2002 at 01:25:08PM -0500, Stephen Gran wrote: > > I believe the g++ migration is now the only thing we're waiting on for > > KDE3. > That was my understanding as well. Do you know the timeframe that this > is expected to take? Nope, I'm pretty well removed from the C++ stuff. > > Various people have stated an intention to make gcc 3.x (for x >= 2) > > the default compiler for sarge. If upstream already has a new version > > of the package that works with g++ 3.x and KDE3, I wouldn't recommend > > that you spend a lot of time trying to get your current version of the > > package to work with gcc 3.x -- especially since, on alpha at least, > > you *can't* compile Qt-based packages using g++ 3.x. > Hmmm . . . that's problematic. Do you know if Qt3 and gcc-3.0 will play > nicely on alpha? Since the problem is a bug in gcc 2.95, there shouldn't be any alpha-specific problems with Qt compiled with gcc-3.x. Steve Langasek postmodern programmer msg07691/pgp0.pgp Description: PGP signature
Re: build failures & compiler versions
This one time, at band camp, Steve Langasek said:
> On Wed, Oct 30, 2002 at 12:08:53PM -0500, Stephen Gran wrote:
> > The other question is, is this acceptable - that is, can I allow a build
> > failure on three architectures for a few {weeks,days}, or is that just
> > deemed too lazy? My personal feeling is that if the new compiler and
> > KDE3 aren't due in sid within about two weeks, I should go ahead and try
> > to deal with the source changes. This involves a fair amount of
> > research for me, so I wanted to ask other's opinions before I started
> > mucking about with it.
>
> Various people have stated an intention to make gcc 3.x (for x >= 2) the
> default compiler for sarge. If upstream already has a new version of the
> package that works with g++ 3.x and KDE3, I wouldn't recommend that you
> spend a lot of time trying to get your current version of the package to
> work with gcc 3.x -- especially since, on alpha at least, you *can't*
> compile Qt-based packages using g++ 3.x.
OK, last question, I swear 8^). The current version is kcdlabel_2.7-3.
Upstream has named their port to KDE3 kcdlabel-2.7-KDE3, so how do I go
about this? kcdlabel_2.7-KDE3-1? -4? Or something else like
kcdlabel-KDE3_2.7-1 (although this would make it a new package name, and
I would have to use replaces/provides fields, I suppose)? I prefer
something like the first one, but it would have been simpler if upstream
just went to 2.8 - it's a fairly large code change, although no feature
change. I suppose as a last resort I could use
kcdlabel_2.8-really2.7-KDE3-1, but I dislike that in principal.
Thanks in advance,
Steve
> Steve Langasek
> postmodern programmer
--
How many surrealists does it take to screw in a lightbulb?
One to hold the giraffe and one to fill the bathtub with brightly colored
power tools.
msg07692/pgp0.pgp
Description: PGP signature
Re: build failures & compiler versions
On Wed, Oct 30, 2002 at 02:37:38PM -0500, Stephen Gran wrote: > OK, last question, I swear 8^). The current version is kcdlabel_2.7-3. > Upstream has named their port to KDE3 kcdlabel-2.7-KDE3, so how do I go > about this? kcdlabel_2.7-KDE3-1? -4? Or something else like > kcdlabel-KDE3_2.7-1 (although this would make it a new package name, and > I would have to use replaces/provides fields, I suppose)? I prefer > something like the first one, but it would have been simpler if upstream > just went to 2.8 - it's a fairly large code change, although no feature > change. I suppose as a last resort I could use > kcdlabel_2.8-really2.7-KDE3-1, but I dislike that in principal. $ dpkg --compare-versions 2.7-3 lt 2.7-KDE3; echo $? 0 $ So using an upstream version of 2.7-KDE3 would be fine. If you think the new version is different enough (i.e., incompatible), you could change the package name. If you keep the same package name and bump the upstream version, you would reset the Debian version to 1, giving you kdclabel_2.7-KDE3-1. Steve Langasek postmodern programmer msg07693/pgp0.pgp Description: PGP signature
Re: Debian development
Le Mercredi 30 Octobre 2002 16:07, Russell Coker a écrit : Hello! Thank you for the answer. Yes, i would accept and do that with pleasure. Moreover, as my job let me free time , there 's another packet, which i could take over:ivtools. I've contacted the former maintainer : ivtools.He seems to be agree. So, i am agree for fcron. What i have to do? thank you very much! sam > You may be interested in taking over the fcron package when you become a > developer. > > Having the upstream and the Debian maintainer in the same country wouldn't > do any harm, I don't plan on maintaining fcron long-term and I'm not sure > whether Henrique wants it back when I'm finished with it. -- Samuel Desseaux 01j, square des ormes 59510 Hem tél:03.20.80.12.62 mobile:06.80.96.67.27 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: build failures & compiler versions
On Oct 30, Steve Langasek ([EMAIL PROTECTED]) wrote: > The default compiler on alpha is still gcc 2.95, to the best of my > knowledge. If the autobuilders are using 3.x, this is not reflected in > the default package layout for the architecture. Where does one find the "default package layout for the architecture"? I am trying to figure out why the build daemon on s390 tried (and failed) to build my package with 3.2, yet the unstable chroot on trex has 2.95.4 (with which it builds fine). -- Neil L. Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: build failures & compiler versions
On Wed, Oct 30, 2002 at 10:22:33PM -0500, Neil L. Roeth wrote: > On Oct 30, Steve Langasek ([EMAIL PROTECTED]) wrote: > > The default compiler on alpha is still gcc 2.95, to the best of my > > knowledge. If the autobuilders are using 3.x, this is not reflected in > > the default package layout for the architecture. > Where does one find the "default package layout for the architecture"? I am > trying to figure out why the build daemon on s390 tried (and failed) to build > my package with 3.2, yet the unstable chroot on trex has 2.95.4 (with which it > builds fine). If you're a DD, madison on auric will give you the full listing of what's considered current[1]: $ madison gcc|grep unstable gcc | 2:2.95.4-17 | unstable | alpha, arm, i386, m68k, mips, mipsel, powerpc, s390, sparc gcc | 2:2.96-19 | unstable | ia64 gcc | 2:3.0.4-8 | unstable | hppa gcc |2:3.1-1 | unstable | hurd-i386 $ So, gcc 2.95 is still supposed to be what s390 uses. Sounds like someone has "tweaked" the s390 buildd. Steve Langasek postmodern programmer [1] If not, probably by checking package versions on your local Debian mirror. msg07696/pgp0.pgp Description: PGP signature
advocate location
Hello, Is there some way I can find out how many/which Debian Developers reside in a particular area, in the interests of finding an advocate? Thanks, Levi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: advocate location
On Wed, 30 Oct 2002, Levi Bard wrote: > Is there some way I can find out how many/which Debian Developers > reside in a particular area, in the interests of finding an > advocate? Uhm, you don't need to have physical contact with your advocate. All you need to have physical contact for is your keysigning. This page may help: http://www.debian.org/devel/join/nm-step2#key_signature -- Matthew Palmer, Debian Developer [EMAIL PROTECTED] http://www.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: advocate location
On Wed, Oct 30, 2002 at 10:24:03PM -0500, Levi Bard wrote: > Hello, > Is there some way I can find out how many/which Debian Developers reside in a >particular area, in the interests of finding an advocate? ldapsearch -P2 -x -h db.debian.org -b ou=Users,dc=debian,dc=org l= From the ldap-utils package. Steve Langasek postmodern programmer msg07699/pgp0.pgp Description: PGP signature
Re: build failures & compiler versions
Steve Langasek <[EMAIL PROTECTED]> writes: > $ madison gcc|grep unstable madison -s unstable gcc -- James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Packaging Trainee Engineer
Dear Sir,
I am currently a student at ESIEC, the only post Graduate School of Packaging
Engineering in EUROPE (Reims University France). I would like to know if
there is any opportunity for a 5-month trainee ship (internship or co-op) in
your company (from July to November 2003).
This is the second and final internship required by the school as part of our
curriculum.
I think my previous studies and current studies at ESIEC allow me to be
involved in development or improvement of new packaging, including testing,
legislation review, data banks, and cost reduction studies.
I have also a 3-month international packaging work experience. I worked for
Fisher & Paykel appliances, NEW ZEALAND appliances manufacturer including
design and production. During this trainee ship, I developped a new pack for
the Freestanding Range Product with the aim to reduce the current transit
damages. I worked on all elements of engineering design from project definition
to a tested detailed design. I was also trained for one week and used for
three months, PRO ENGINEER, a parametric 3D solid modeling software.
The flight costs will be paid by the scool. As for financial input, I only need
to have enough money for my living expenses (food and accommodations).
To know more about myself and for further information, please visit :
http://thomas.poizat.free.fr
Should you need more information, I would be pleased to provide it.
I look forward to hearing from you.
Sincerely Yours.
Thomas POIZAT (2nd year) ESIEC
Esplanade Roland Garros
B.P 1029 51686 Reims Cedex 2 FRANCE
Tel : (33) 03-26-91-33-99 Fax : (33) 03-26-91-38-03
E-mail : [EMAIL PROTECTED]
Encl : C.V.
{\rtf1\ansi\ansicpg1252\uc1 \deff0\deflang1036\deflangfe1036{\fonttbl{\f0\froman\fcharset0\fprq2{\*\panose 02020603050405020304}Times New Roman;}{\f1\fswiss\fcharset0\fprq2{\*\panose 020b0604020202020204}Arial;} {\f3\froman\fcharset2\fprq2{\*\panose 05050102010706020507}Symbol;}{\f28\froman\fcharset2\fprq2{\*\panose 05020102010507070707}Wingdings 2;}{\f33\froman\fcharset238\fprq2 Times New Roman CE;}{\f34\froman\fcharset204\fprq2 Times New Roman Cyr;} {\f36\froman\fcharset161\fprq2 Times New Roman Greek;}{\f37\froman\fcharset162\fprq2 Times New Roman Tur;}{\f38\froman\fcharset177\fprq2 Times New Roman (Hebrew);}{\f39\froman\fcharset178\fprq2 Times New Roman (Arabic);} {\f40\froman\fcharset186\fprq2 Times New Roman Baltic;}{\f41\fswiss\fcharset238\fprq2 Arial CE;}{\f42\fswiss\fcharset204\fprq2 Arial Cyr;}{\f44\fswiss\fcharset161\fprq2 Arial Greek;}{\f45\fswiss\fcharset162\fprq2 Arial Tur;} {\f46\fswiss\fcharset177\fprq2 Arial (Hebrew);}{\f47\fswiss\fcharset178\fprq2 Arial (Arabic);}{\f48\fswiss\fcharset186\fprq2 Arial Baltic;}}{\colortbl;\red0\green0\blue0;\red0\green0\blue255;\red0\green255\blue255;\red0\green255\blue0; \red255\green0\blue255;\red255\green0\blue0;\red255\green255\blue0;\red255\green255\blue255;\red0\green0\blue128;\red0\green128\blue128;\red0\green128\blue0;\red128\green0\blue128;\red128\green0\blue0;\red128\green128\blue0;\red128\green128\blue128; \red192\green192\blue192;\red255\green255\blue255;}{\stylesheet{\ql \li0\ri0\widctlpar\aspalpha\aspnum\faauto\adjustright\rin0\lin0\itap0 \fs20\lang1036\langfe1036\cgrid\langnp1036\langfenp1036 \snext0 Normal;}{ \s1\ql \li0\ri0\keepn\widctlpar\aspalpha\aspnum\faauto\adjustright\rin0\lin0\itap0 \fs24\lang1036\langfe1036\cgrid\langnp1036\langfenp1036 \sbasedon0 \snext0 heading 1;}{ \s2\ql \li0\ri0\sb240\sa60\keepn\widctlpar\aspalpha\aspnum\faauto\adjustright\rin0\lin0\itap0 \b\i\f1\fs24\lang1036\langfe1036\cgrid\langnp1036\langfenp1036 \sbasedon0 \snext0 heading 2;}{\s3\qj \li0\ri0\sb120\sa120\widctlpar\brdrb \brdrs\brdrw10\brsp20\brdrcf2 \aspalpha\aspnum\faauto\adjustright\rin0\lin0\itap0 \b\fs28\lang1036\langfe1036\cgrid\langnp1036\langfenp1036 \sbasedon0 \snext0 heading 3;}{\s8\qc \li0\ri0\sb120\sa120\keepn\widctlpar\brdrt \brdrsh\brdrs\brdrw10\brsp60\brdrcf6 \brdrl\brdrsh\brdrs\brdrw10\brsp80\brdrcf6 \brdrb\brdrsh\brdrs\brdrw10\brsp60\brdrcf6 \brdrr\brdrsh\brdrs\brdrw10\brsp80\brdrcf6 \aspalpha\aspnum\faauto\adjustright\rin0\lin0\itap0 \b\fs32\lang1036\langfe1036\cgrid\langnp1036\langfenp1036 \sbasedon0 \snext0 heading 8;}{\*\cs10 \additive Default Paragraph Font;}{\s15\ql \li0\ri0\widctlpar\aspalpha\aspnum\faauto\adjustright\rin0\lin0\itap0 \fs24\lang2057\langfe1036\cgrid\langnp2057\langfenp1036 \sbasedon0 \snext15 classique;}{\s16\ql \li0\ri0\sa120\widctlpar\aspalpha\aspnum\faauto\adjustright\rin0\lin0\itap0 \b\fs24\lang1036\langfe1036\cgrid\langnp1036\langfenp1036 \sbasedon0 \snext16 petit titre;}{\s17\ql \li0\ri0\widctlpar\aspalpha\aspnum\faauto\adjustright\rin0\lin0\itap0 \fs20\lang1036\langfe1036\cgrid\langnp1036\langfenp1036 \sbasedon0 \snext0 Date;}{\s18\ql \li0\ri0\widctlpar\aspalpha\aspnum\faauto\adjustright\rin0\lin0\itap0 \f1\fs20\lang2057\langfe1036\cgrid\langnp2057\langfenp1036 \sbasedon15 \snext18 texte;}{\s19\ql \li0\ri0\widctlpar\aspalpha\aspn
Re: mplayer in debian ( versus new-maintainer )
On Tue, Oct 29, 2002 at 08:52:46PM +0100, Dariush Pietrzak wrote: > Until now I've been preparing pure-gpl version of mplayer as advised by > debian-legal, and that version have been sent to Andrea. Now that divx4 > problem have been resolved, I can drop that tree and send the real thing;) Careful, this is the fourth time now that they've claimed that problem has been "resolved". Once they were lying, and twice they were wrong. Ignore anything that the mplayer authors produced; you need to find a copy of *that code* from the copyright holder that has a GPL license attached. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -><- | London, UK
s390 build
The buildd logs for my package, aplus-fsf, show a failure to build on the s390 due to a compile error. I logged on to trex and attempted to build it in the unstable chroot. It built without error. Then I noticed that the error in the buildd log referred to a file /usr/include/c++/3.2/backward/new.h. The "3.2" made me think that the 3.2 compiler was being used instead of the 2.95.4, but I found that the installed version of c++ is in fact 2.95.4 (c++ --version). What is the build-essential compiler on s390? If it is 3.2, should I expect it to be installed in the unstable chroot? -- Neil L. Roeth
how becoming maintainer
Hello! I'm a young french developer and user of debian (linux is my great passion) I'd like to work (and so learn it)on the maintaining of packages.So, i think it's a good way to go into the project and learn. Tell me if it is possible and what i have to do! and how! thank you very much sincerely sam -- Samuel Desseaux 01j, square des ormes 59510 Hem France tél:03.20.80.12.62 mobile:06.80.96.67.27
Re: how becoming maintainer
samuel desseaux <[EMAIL PROTECTED]> writes: > Hello! > > I'm a young french developer and user of debian (linux is my great passion) > > I'd like to work (and so learn it)on the maintaining of packages.So, i think > it's a good way to go into the project and learn. > Tell me if it is possible and what i have to do! and how! You first have to read the doc, and to learn how to read doc. See http://www.debian.org/devel/ -- Rémi Vanicat [EMAIL PROTECTED] http://dept-info.labri.u-bordeaux.fr/~vanicat
Advice needed for new Debian packages (SNA for Linux)
Dear Mentors, currently I'm preparing "Linux-SNA", found at www.linux-sna.org to fit into some Debian packages. Eduard Bloch ([EMAIL PROTECTED], CC:) and I, too, things this could be matter of public interest. So my question is: whats needed to get the packages verified and uploaded? Should I become maintainer of the packages if Debian agrees to upload them? Best regards Erik. -- Erik Weber phone: +49 160 55 11 893 Beratender Ingenieur PSF 10 33 49, 68 033 Mannheim pgp key ID: CA709381 EMail: [EMAIL PROTECTED] pgp key fingerprint: ABD7 4B13 02C8 21A2 6938 61BD FC20 9960
Debian development
You may be interested in taking over the fcron package when you become a developer. Having the upstream and the Debian maintainer in the same country wouldn't do any harm, I don't plan on maintaining fcron long-term and I'm not sure whether Henrique wants it back when I'm finished with it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: mplayer in debian ( versus new-maintainer )
Hi Dariush On Tue, Oct 29, 2002 at 08:52:46PM +0100, Dariush Pietrzak wrote: > Hello, > I am supposed to upload mplayer to debian, however there is quite a lagg > between me and my sponsor (Andrea Mennucc), and some problems with yes, it seems that sometimes the e-mail you send me or e-mail I send you get lost; indeed I haven't heard from you for quite a long time. > transferring larger files to him ( i.e. media packages that will follow > mplayer package - mplayer-fonts and mplayer-skins, are quite large and > it sometimes takes some time until we synchronize our versions ). I just found out, a few days ago, that the new mail server in this institution will silently drop e-mails that exceed a built-in limit; if you have sent me big files in the last 4 months and I never got back, it means we have to find another way. Example solutions: 1) split the big files using the 'split' command and send me the pieces. Example for sending aa.tar.gz : $ split -b 200k aa.tar.gz aa.tar.gz.pieces. $ for i in aa.tar.gz.pieces.* ; do echo $i | mutt [EMAIL PROTECTED] -a $i ; done $ rm aa.tar.gz.pieces.* If you don't have mutt you can use $ for i in aa.tar.gz.pieces.* ; do uuencode $i $i | mail [EMAIL PROTECTED] ; done 2) You should upload your public gpg key to a gpg server, and send me a copy; then I will send you crypted info on how you can send me very large files (basically, I will create you an account you can rsync to). Actually, you should send me a public gpg key nonetheless, and sign any package that you wish that I send into Debian > Until now I've been preparing pure-gpl version of mplayer as advised by > debian-legal, and that version have been sent to Andrea. Now that divx4 > problem have been resolved, I can drop that tree and send the real > thing;) I would love to try it; the version you sent to me in april crashed on some divx files > So I figured that I'd speed up my entrance into Debian,... you should absolutely try to get into Debian anyway; this will give you direct control on the forthcoming mplayer packages. see you soon a. -- Andrea Mennucc "E' un mondo difficile. Che vita intensa!" (Tonino Carotone) pgptdWGV5d8TN.pgp Description: PGP signature
Re: Debian development
On Wed, 30 Oct 2002, Russell Coker wrote: > You may be interested in taking over the fcron package when you become a > developer. > > Having the upstream and the Debian maintainer in the same country wouldn't do > any harm, I don't plan on maintaining fcron long-term and I'm not sure > whether Henrique wants it back when I'm finished with it. I like fcron a lot, but I really lack the time to properly take care of it. So, I would not be opposed of someone else taking fcron over, as long as whomever does it meets my minimum requirements, which are: 1. you do test stuff before you upload. 2. you do test stuff before you upload. 3. you do test stuff before you upload. 4. you don't trust stuff from upstream before you look it over (fcron upstream is rather good, so this is not usually a problem... still, it pays to be doubly paranoid over something such as a crontab dispatcher). 5. you do test stuff before you upload. ...and... 6. you don't stick rm -rf $something-not-quote-safe in maintainer scripts. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
build failures & compiler versions
Hello all,
I am maintaining a package that fails to build on alpha, hppa, and s390.
It appears that the problem is that those architectures use gcc/g++-3.0,
rather than 2.95, as the default compiler. The source would need to be
modified (not hugely, perhaps) to compile with gcc/g++-3.0.
This package also uses the KDE2/Qt2 environment, which I know is due to
be replaced in unstable. Upstream has written a version that is ported
over to KDE3/Qt3, and I believe, gcc/g++-3.0.
I understand that KDE3 is being held up from moving into sid because of
hold-ups with changing to gcc-3.x. Am I correct in this?
So now I have, I guess, two questions. Does anyone know how long it is
expected to be before the new default compiler and KDE3 move into sid?
If it is expected to be relatively shortly, I will concentrate my
efforts on the new version.
The other question is, is this acceptable - that is, can I allow a build
failure on three architectures for a few {weeks,days}, or is that just
deemed too lazy? My personal feeling is that if the new compiler and
KDE3 aren't due in sid within about two weeks, I should go ahead and try
to deal with the source changes. This involves a fair amount of
research for me, so I wanted to ask other's opinions before I started
mucking about with it.
TIA,
Steve
--
What's another word for "thesaurus"?
-- Steven Wright
pgp7KAwDoSRED.pgp
Description: PGP signature
Re: build failures & compiler versions
On Wed, Oct 30, 2002 at 12:08:53PM -0500, Stephen Gran wrote:
> I am maintaining a package that fails to build on alpha, hppa, and s390.
> It appears that the problem is that those architectures use gcc/g++-3.0,
> rather than 2.95, as the default compiler. The source would need to be
> modified (not hugely, perhaps) to compile with gcc/g++-3.0.
The default compiler on alpha is still gcc 2.95, to the best of my
knowledge. If the autobuilders are using 3.x, this is not reflected in
the default package layout for the architecture.
There is another issue, which is that g++ 2.95 is fairly *broken* on
alphas, and you need to disable optimization by compiling with -O0 to get
most complex C++ code to compile on that arch. For further information
on enabling compile options on an arch-dependent basis, see the rules
file for unixodbc, for example.
> This package also uses the KDE2/Qt2 environment, which I know is due to
> be replaced in unstable. Upstream has written a version that is ported
> over to KDE3/Qt3, and I believe, gcc/g++-3.0.
> I understand that KDE3 is being held up from moving into sid because of
> hold-ups with changing to gcc-3.x. Am I correct in this?
I believe the g++ migration is now the only thing we're waiting on for
KDE3.
> So now I have, I guess, two questions. Does anyone know how long it is
> expected to be before the new default compiler and KDE3 move into sid?
> If it is expected to be relatively shortly, I will concentrate my
> efforts on the new version.
> The other question is, is this acceptable - that is, can I allow a build
> failure on three architectures for a few {weeks,days}, or is that just
> deemed too lazy? My personal feeling is that if the new compiler and
> KDE3 aren't due in sid within about two weeks, I should go ahead and try
> to deal with the source changes. This involves a fair amount of
> research for me, so I wanted to ask other's opinions before I started
> mucking about with it.
Various people have stated an intention to make gcc 3.x (for x >= 2) the
default compiler for sarge. If upstream already has a new version of the
package that works with g++ 3.x and KDE3, I wouldn't recommend that you
spend a lot of time trying to get your current version of the package to
work with gcc 3.x -- especially since, on alpha at least, you *can't*
compile Qt-based packages using g++ 3.x.
If you have some time and energy to devote to the matter, I would suggest
talking with the toolchain maintainers about whether there's anything you
could do to help get the gcc 3.x transition moving forward.
Steve Langasek
postmodern programmer
pgpbqFt5L0tXE.pgp
Description: PGP signature
Re: build failures & compiler versions
Stephen Gran <[EMAIL PROTECTED]> writes:
> Hello all,
>
> I am maintaining a package that fails to build on alpha, hppa, and s390.
> It appears that the problem is that those architectures use gcc/g++-3.0,
> rather than 2.95, as the default compiler. The source would need to be
> modified (not hugely, perhaps) to compile with gcc/g++-3.0.
>
> This package also uses the KDE2/Qt2 environment, which I know is due to
> be replaced in unstable. Upstream has written a version that is ported
> over to KDE3/Qt3, and I believe, gcc/g++-3.0.
>
> I understand that KDE3 is being held up from moving into sid because of
> hold-ups with changing to gcc-3.x. Am I correct in this?
Yep.
> So now I have, I guess, two questions. Does anyone know how long it is
> expected to be before the new default compiler and KDE3 move into sid?
> If it is expected to be relatively shortly, I will concentrate my
> efforts on the new version.
The Qt3 maintainer told me yesterday that he plans to upload Qt3.1
compiled with g++-3.2 within a week. I assume KDE 3 would follow
shortly.
> The other question is, is this acceptable - that is, can I allow a build
> failure on three architectures for a few {weeks,days}, or is that just
> deemed too lazy? My personal feeling is that if the new compiler and
> KDE3 aren't due in sid within about two weeks, I should go ahead and try
> to deal with the source changes. This involves a fair amount of
> research for me, so I wanted to ask other's opinions before I started
> mucking about with it.
You could just change the Architecture: field in the control file to not
attempt to build on the broken arches, for now.
--
People said I was dumb, but I proved them!
Re: build failures & compiler versions
This one time, at band camp, Steve Langasek said: > On Wed, Oct 30, 2002 at 12:08:53PM -0500, Stephen Gran wrote: > > I am maintaining a package that fails to build on alpha, hppa, and > > s390. It appears that the problem is that those architectures use > > gcc/g++-3.0, rather than 2.95, as the default compiler. The source > > would need to be modified (not hugely, perhaps) to compile with > > gcc/g++-3.0. > > The default compiler on alpha is still gcc 2.95, to the best of my > knowledge. If the autobuilders are using 3.x, this is not reflected > in the default package layout for the architecture. This was, admittedly, a guess, as I have no access to the machines. The log files all show the same errors, and as I know hppa uses gcc-3.0, I assumed the others did as well. > There is another issue, which is that g++ 2.95 is fairly *broken* on > alphas, and you need to disable optimization by compiling with -O0 to > get most complex C++ code to compile on that arch. For further > information on enabling compile options on an arch-dependent basis, > see the rules file for unixodbc, for example. I didn't know you could do this, but that's very helpful. I will look into this, if the migration is expected to take some time. > I believe the g++ migration is now the only thing we're waiting on for > KDE3. That was my understanding as well. Do you know the timeframe that this is expected to take? > Various people have stated an intention to make gcc 3.x (for x >= 2) > the default compiler for sarge. If upstream already has a new version > of the package that works with g++ 3.x and KDE3, I wouldn't recommend > that you spend a lot of time trying to get your current version of the > package to work with gcc 3.x -- especially since, on alpha at least, > you *can't* compile Qt-based packages using g++ 3.x. Hmmm . . . that's problematic. Do you know if Qt3 and gcc-3.0 will play nicely on alpha? I have no experience with architectures other than i386. Google, here I come (^8. > Steve Langasek > postmodern programmer Thanks, Steve -- A list is only as strong as its weakest link. -- Don Knuth pgpLo8tqQbIZy.pgp Description: PGP signature
Re: build failures & compiler versions
On Wed, Oct 30, 2002 at 10:25:09AM -0800, Brian Nelson wrote: > You could just change the Architecture: field in the control file to not > attempt to build on the broken arches, for now. Don't discriminate against architectures because of a temporary build failure. Steve Langasek postmodern programmer pgpXjTjfLsmA1.pgp Description: PGP signature
Re: build failures & compiler versions
On Wed, Oct 30, 2002 at 01:25:08PM -0500, Stephen Gran wrote: > > I believe the g++ migration is now the only thing we're waiting on for > > KDE3. > That was my understanding as well. Do you know the timeframe that this > is expected to take? Nope, I'm pretty well removed from the C++ stuff. > > Various people have stated an intention to make gcc 3.x (for x >= 2) > > the default compiler for sarge. If upstream already has a new version > > of the package that works with g++ 3.x and KDE3, I wouldn't recommend > > that you spend a lot of time trying to get your current version of the > > package to work with gcc 3.x -- especially since, on alpha at least, > > you *can't* compile Qt-based packages using g++ 3.x. > Hmmm . . . that's problematic. Do you know if Qt3 and gcc-3.0 will play > nicely on alpha? Since the problem is a bug in gcc 2.95, there shouldn't be any alpha-specific problems with Qt compiled with gcc-3.x. Steve Langasek postmodern programmer pgpFw8DrrxNG5.pgp Description: PGP signature
Re: build failures & compiler versions
This one time, at band camp, Steve Langasek said:
> On Wed, Oct 30, 2002 at 12:08:53PM -0500, Stephen Gran wrote:
> > The other question is, is this acceptable - that is, can I allow a build
> > failure on three architectures for a few {weeks,days}, or is that just
> > deemed too lazy? My personal feeling is that if the new compiler and
> > KDE3 aren't due in sid within about two weeks, I should go ahead and try
> > to deal with the source changes. This involves a fair amount of
> > research for me, so I wanted to ask other's opinions before I started
> > mucking about with it.
>
> Various people have stated an intention to make gcc 3.x (for x >= 2) the
> default compiler for sarge. If upstream already has a new version of the
> package that works with g++ 3.x and KDE3, I wouldn't recommend that you
> spend a lot of time trying to get your current version of the package to
> work with gcc 3.x -- especially since, on alpha at least, you *can't*
> compile Qt-based packages using g++ 3.x.
OK, last question, I swear 8^). The current version is kcdlabel_2.7-3.
Upstream has named their port to KDE3 kcdlabel-2.7-KDE3, so how do I go
about this? kcdlabel_2.7-KDE3-1? -4? Or something else like
kcdlabel-KDE3_2.7-1 (although this would make it a new package name, and
I would have to use replaces/provides fields, I suppose)? I prefer
something like the first one, but it would have been simpler if upstream
just went to 2.8 - it's a fairly large code change, although no feature
change. I suppose as a last resort I could use
kcdlabel_2.8-really2.7-KDE3-1, but I dislike that in principal.
Thanks in advance,
Steve
> Steve Langasek
> postmodern programmer
--
How many surrealists does it take to screw in a lightbulb?
One to hold the giraffe and one to fill the bathtub with brightly colored
power tools.
pgpyD3OoU5ck6.pgp
Description: PGP signature
Re: build failures & compiler versions
On Wed, Oct 30, 2002 at 02:37:38PM -0500, Stephen Gran wrote: > OK, last question, I swear 8^). The current version is kcdlabel_2.7-3. > Upstream has named their port to KDE3 kcdlabel-2.7-KDE3, so how do I go > about this? kcdlabel_2.7-KDE3-1? -4? Or something else like > kcdlabel-KDE3_2.7-1 (although this would make it a new package name, and > I would have to use replaces/provides fields, I suppose)? I prefer > something like the first one, but it would have been simpler if upstream > just went to 2.8 - it's a fairly large code change, although no feature > change. I suppose as a last resort I could use > kcdlabel_2.8-really2.7-KDE3-1, but I dislike that in principal. $ dpkg --compare-versions 2.7-3 lt 2.7-KDE3; echo $? 0 $ So using an upstream version of 2.7-KDE3 would be fine. If you think the new version is different enough (i.e., incompatible), you could change the package name. If you keep the same package name and bump the upstream version, you would reset the Debian version to 1, giving you kdclabel_2.7-KDE3-1. Steve Langasek postmodern programmer pgpPo4MivZ9lS.pgp Description: PGP signature
Re: Debian development
Le Mercredi 30 Octobre 2002 16:07, Russell Coker a écrit : Hello! Thank you for the answer. Yes, i would accept and do that with pleasure. Moreover, as my job let me free time , there 's another packet, which i could take over:ivtools. I've contacted the former maintainer : ivtools.He seems to be agree. So, i am agree for fcron. What i have to do? thank you very much! sam > You may be interested in taking over the fcron package when you become a > developer. > > Having the upstream and the Debian maintainer in the same country wouldn't > do any harm, I don't plan on maintaining fcron long-term and I'm not sure > whether Henrique wants it back when I'm finished with it. -- Samuel Desseaux 01j, square des ormes 59510 Hem tél:03.20.80.12.62 mobile:06.80.96.67.27
Re: build failures & compiler versions
On Oct 30, Steve Langasek ([EMAIL PROTECTED]) wrote: > The default compiler on alpha is still gcc 2.95, to the best of my > knowledge. If the autobuilders are using 3.x, this is not reflected in > the default package layout for the architecture. Where does one find the "default package layout for the architecture"? I am trying to figure out why the build daemon on s390 tried (and failed) to build my package with 3.2, yet the unstable chroot on trex has 2.95.4 (with which it builds fine). -- Neil L. Roeth
Re: build failures & compiler versions
On Wed, Oct 30, 2002 at 10:22:33PM -0500, Neil L. Roeth wrote: > On Oct 30, Steve Langasek ([EMAIL PROTECTED]) wrote: > > The default compiler on alpha is still gcc 2.95, to the best of my > > knowledge. If the autobuilders are using 3.x, this is not reflected in > > the default package layout for the architecture. > Where does one find the "default package layout for the architecture"? I am > trying to figure out why the build daemon on s390 tried (and failed) to build > my package with 3.2, yet the unstable chroot on trex has 2.95.4 (with which it > builds fine). If you're a DD, madison on auric will give you the full listing of what's considered current[1]: $ madison gcc|grep unstable gcc | 2:2.95.4-17 | unstable | alpha, arm, i386, m68k, mips, mipsel, powerpc, s390, sparc gcc | 2:2.96-19 | unstable | ia64 gcc | 2:3.0.4-8 | unstable | hppa gcc |2:3.1-1 | unstable | hurd-i386 $ So, gcc 2.95 is still supposed to be what s390 uses. Sounds like someone has "tweaked" the s390 buildd. Steve Langasek postmodern programmer [1] If not, probably by checking package versions on your local Debian mirror. pgplMLJZRVN9U.pgp Description: PGP signature
advocate location
Hello, Is there some way I can find out how many/which Debian Developers reside in a particular area, in the interests of finding an advocate? Thanks, Levi
Re: advocate location
On Wed, 30 Oct 2002, Levi Bard wrote: > Is there some way I can find out how many/which Debian Developers > reside in a particular area, in the interests of finding an > advocate? Uhm, you don't need to have physical contact with your advocate. All you need to have physical contact for is your keysigning. This page may help: http://www.debian.org/devel/join/nm-step2#key_signature -- Matthew Palmer, Debian Developer [EMAIL PROTECTED] http://www.debian.org
Re: advocate location
On Wed, Oct 30, 2002 at 10:24:03PM -0500, Levi Bard wrote: > Hello, > Is there some way I can find out how many/which Debian Developers > reside in a particular area, in the interests of finding an advocate? ldapsearch -P2 -x -h db.debian.org -b ou=Users,dc=debian,dc=org l= From the ldap-utils package. Steve Langasek postmodern programmer pgpj1XA4X07dr.pgp Description: PGP signature
Re: build failures & compiler versions
Steve Langasek <[EMAIL PROTECTED]> writes: > $ madison gcc|grep unstable madison -s unstable gcc -- James
