Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
On Wed, Nov 20, 2002 at 09:39:15PM +0100, Oden Eriksson wrote: > Now Per Øyvind Karlsen stepped forward about the "dsniff" package, it will > maybe be fixed tonight or tomorrow. This package was a nightmare to get it to > compile, once it did, I ran the softwares and didn't notice anything > strange..., the thing is they don't segfault right away... Well that's excusable. The alternative to removing packages is to downgrade them. If there's a version that was working. Get the spec out of CVS, update the release tag, increase the epoch if neessary, write a changelog explaining the downgrade and reupload it. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org "If you're not making any mistakes, you're flat out not trying hard enough." - Jim Nichols
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
onsdagen den 20 november 2002 21.20 skrev Ben Reser: > On Wed, Nov 20, 2002 at 01:24:35PM +0100, Oden Eriksson wrote: > > Ok, thank you. > > > > What if I needed help with something? > > > > For example the "DarwinStreamingServer-Admin" package is screwy, and > > lately the softwares in the "dsniff" package segfaults, I have asked for > > help several times but no one has stepped forward. Should I just ask > > Mandrake to delete these from contribs? > > IMHO yes. Until you think they are decent. Yes this is a development > tree. But that doesn't mean we should be uploading broken packages... > Though if a project is in process and it's made clear of that in the > changelog then I guess that's okay. But the problem (especially with > contribs) of uploading broken packages is that the fact the package is > broken gets forgetten and ends up getting released with the final > version. Then people think Mandrake sucks because they released broken > stuff. We'd be better off not to have something than having something > that's broken. OK, I will ask them to delete these packages. I will release a new "DarwinStreamingServer" suite without the damn web admin stuff, I think I will drop the "DarwinStreamingServer-Media" package too. That damn admin stuff is a piece of junk anyway, so I don't think people would miss it too much... Now Per Øyvind Karlsen stepped forward about the "dsniff" package, it will maybe be fixed tonight or tomorrow. This package was a nightmare to get it to compile, once it did, I ran the softwares and didn't notice anything strange..., the thing is they don't segfault right away... I think it would be very interesting and also very useful to have the "dsniff" package working... So anyone who can help out to solve this mystery is invited to my hall of fame :) Chears. -- Regards // Oden Eriksson, Deserve-IT Networks Check the "Modules For Apache2" status page at: http://www.deserve-it.com/modules_for_apache2.html
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
On Wed, Nov 20, 2002 at 01:24:35PM +0100, Oden Eriksson wrote: > Ok, thank you. > > What if I needed help with something? > > For example the "DarwinStreamingServer-Admin" package is screwy, and lately > the softwares in the "dsniff" package segfaults, I have asked for help > several times but no one has stepped forward. Should I just ask Mandrake to > delete these from contribs? IMHO yes. Until you think they are decent. Yes this is a development tree. But that doesn't mean we should be uploading broken packages... Though if a project is in process and it's made clear of that in the changelog then I guess that's okay. But the problem (especially with contribs) of uploading broken packages is that the fact the package is broken gets forgetten and ends up getting released with the final version. Then people think Mandrake sucks because they released broken stuff. We'd be better off not to have something than having something that's broken. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org "If you're not making any mistakes, you're flat out not trying hard enough." - Jim Nichols
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
onsdagen den 20 november 2002 01.30 skrev Ben Reser: > On Tue, Nov 19, 2002 at 05:24:49PM +0100, Oden Eriksson wrote: > > I'm sorry but..., if I where to test everything as people expect even > > though I commit only cooker contribs, aka. _development_ stuff..., all my > > time would be spent on that. I have to rely on bugreports. Now..., I > > seldom get any bugreports..., either people are lazy or I do a very well > > job... I could test everything as desired but then I need foundings from > > MandrakeSoft in form of equipment, education and a salary... I strongly > > doubt I will get any of this... So..., there you have it. > > If you're building, installing and making sure the program works then > you're doing all the testing that I'm suggesting. I'm not asking you to > prove that the code is correct or something. A simple cursory install > and test of the software. Ok, thank you. What if I needed help with something? For example the "DarwinStreamingServer-Admin" package is screwy, and lately the softwares in the "dsniff" package segfaults, I have asked for help several times but no one has stepped forward. Should I just ask Mandrake to delete these from contribs? -- Regards // Oden Eriksson, Deserve-IT Networks Check the "Modules For Apache2" status page at: http://www.deserve-it.com/modules_for_apache2.html
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
On Tue, Nov 19, 2002 at 05:24:49PM +0100, Oden Eriksson wrote: > I'm sorry but..., if I where to test everything as people expect even though I > commit only cooker contribs, aka. _development_ stuff..., all my time would > be spent on that. I have to rely on bugreports. Now..., I seldom get any > bugreports..., either people are lazy or I do a very well job... I could test > everything as desired but then I need foundings from MandrakeSoft in form of > equipment, education and a salary... I strongly doubt I will get any of > this... So..., there you have it. If you're building, installing and making sure the program works then you're doing all the testing that I'm suggesting. I'm not asking you to prove that the code is correct or something. A simple cursory install and test of the software. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org "If you're not making any mistakes, you're flat out not trying hard enough." - Jim Nichols
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
torsdagen den 14 november 2002 20.33 skrev Ben Reser: > On Thu, Nov 14, 2002 at 11:23:00AM +0100, Luca Olivetti wrote: > > I don't agree: I suppose that mandrakesoft has an automated build > > procedure, a warning will probably go unnoticed, while a package that > > fails to build will surely get a maintaner attention. The result will be > > many less broken packages (I hope). > > The developer should be doing a build on their own machine *BEFORE* they > upload it to any system that is going to do an automated build. And > ports should only be building packages that have already been built and > tested on i586. > > Unfortunately, so many times people upload packages without bother to > even test them. Yes mistakes will get made. But I have to wonder how > packages with syntax errors in the perl scripts get uploaded Only > thing I can see is that someone didn't bother to test the package first. > > Ultimately this small change will not solve the problem of untested > rpms that are screwy. It will still be a problem, until developers take > responsibility for their packages. I'm sorry but..., if I where to test everything as people expect even though I commit only cooker contribs, aka. _development_ stuff..., all my time would be spent on that. I have to rely on bugreports. Now..., I seldom get any bugreports..., either people are lazy or I do a very well job... I could test everything as desired but then I need foundings from MandrakeSoft in form of equipment, education and a salary... I strongly doubt I will get any of this... So..., there you have it. -- Regards // Oden Eriksson, Deserve-IT Networks Check the "Modules For Apache2" status page at: http://www.deserve-it.com/modules_for_apache2.html
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
Le Jeudi 14 Novembre 2002 20:33, Ben Reser a écrit : > Unfortunately, so many times people upload packages without bother to > even test them. Are you suggesting PLF peoples should actually test their package before uploading? You're crazy, they are far too many rootkits inside :-) -- All components become obsolete. -- Murphy's Computer Laws n°8
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
Hi, OTOH I have seen quite a few RPMS that were build only on the packagers machine. That person rpm now depends on libraries that exist on his machine the don't exist in mdk-cooker. Huh, which packages? This can't be true anymore as there are machine checks. Yeah, that was possible some time ago but Warly strenghtened the rules. What happens sometimes is indeed one machine of the cluster fails to synchronize with others. :-/ Bye, Gwenole
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
On Thu, Nov 14, 2002 at 10:17:04PM +0100, Stefan van der Eijk wrote: > Define "build system". > > It's a mix of cooker & contrib, and never the same (packages being > installed & de-installed all the time). There is little that is going to > make sure that a package built today will have the same functionality as > a package today. It's by sheer coincidence that it goes right most of > the time (ImageMagick and xawtv are recent examples of when it went wrong). Yeah I understand that. I'm not saying that process couldn't be improved. But you know what I mean... > Package quality can be tested in an automated manner. My rebuilding > scripts check the filelist, provides and requires of packages when they > have been rebuilt. This is information which is readly available by > querying the resulting rpm --> should be easy to implement some kind of > automatic system around this. > > Functionality of packaged software will require manual testing of the > package B4 uploading. I'll be honest, the alpha (unsupported distro) > packages my script uploads are not tested. The packages where I change > the BuildRequires are not tested either. It's not good, I know. I was mostly referring to functionality. But yes package quality can be automated to a degree. But never completly. There will always be errors that slip by the test scripts. > It happens... :-(( But it shouldn't. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org "If you're not making any mistakes, you're flat out not trying hard enough." - Jim Nichols
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s)found:
Ben Reser wrote: On Thu, Nov 14, 2002 at 09:10:42PM +0059, Han Boetes wrote: OTOH I have seen quite a few RPMS that were build only on the packagers machine. That person rpm now depends on libraries that exist on his machine the don't exist in mdk-cooker. ie Don't upload binaries built on your machine and use the mdk build-hosts to make them. Yes well the binaries should still be built on the build system. Define "build system". It's a mix of cooker & contrib, and never the same (packages being installed & de-installed all the time). There is little that is going to make sure that a package built today will have the same functionality as a package today. It's by sheer coincidence that it goes right most of the time (ImageMagick and xawtv are recent examples of when it went wrong). I'm just asking for a bit of testing before they get put there to build. :) Package quality can be tested in an automated manner. My rebuilding scripts check the filelist, provides and requires of packages when they have been rebuilt. This is information which is readly available by querying the resulting rpm --> should be easy to implement some kind of automatic system around this. Functionality of packaged software will require manual testing of the package B4 uploading. I'll be honest, the alpha (unsupported distro) packages my script uploads are not tested. The packages where I change the BuildRequires are not tested either. It's not good, I know. Most Perl makefiles support the test target. When I make a Perl-SRPM I turn on that test target just to make sure everything is OK. Yes but mostly I'm referring to the Mandrake perl tools. E.g. how many times has urpmi or various other drake tools been uploaded with a syntax error that breaks them. It happens... :-(( Difficult situation. But indeed it is better to wait at least to the next day when you release a package. Don't rush it out. After a few releases I learned to recognize the feel of the rush and that I had to sit on my hands and wait until the next morning after the coffee to double-check everything. Exactly my point. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
On Thu, Nov 14, 2002 at 09:10:42PM +0059, Han Boetes wrote: > OTOH I have seen quite a few RPMS that were build only on the packagers > machine. That person rpm now depends on libraries that exist on his > machine the don't exist in mdk-cooker. ie Don't upload binaries built on > your machine and use the mdk build-hosts to make them. Yes well the binaries should still be built on the build system. I'm just asking for a bit of testing before they get put there to build. :) > Most Perl makefiles support the test target. When I make a Perl-SRPM I > turn on that test target just to make sure everything is OK. Yes but mostly I'm referring to the Mandrake perl tools. E.g. how many times has urpmi or various other drake tools been uploaded with a syntax error that breaks them. > Difficult situation. But indeed it is better to wait at least to the > next day when you release a package. Don't rush it out. After a few > releases I learned to recognize the feel of the rush and that I had to > sit on my hands and wait until the next morning after the coffee to > double-check everything. Exactly my point. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org "If you're not making any mistakes, you're flat out not trying hard enough." - Jim Nichols
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s)found:
Gwenole Beauchesne wrote: Hi, I don't agree: I suppose that mandrakesoft has an automated build procedure, a warning will probably go unnoticed, while a package that fails to build will surely get a maintaner attention. The result will be many less broken packages (I hope). Exactly! Too maintainers simply don't care about their packages. This is a means to bring attention to possible new files added through packages updates and also fix existing packages that have missing files. Can something also be implemented to check BuildRequires? --> Would help the ports a LOT. It's quite simple to implement: only upload the src.rpm and let the upload robot rebuild it in a clean environment (basesystem + rpm-build) plus installing the BuildRequires. As a matter of fact, I've been doing this with the alpha port for a while now... Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s)found:
Luca Olivetti wrote: Olivier Thauvin wrote: Le Jeudi 14 Novembre 2002 09:20, Stefan van der Eijk a écrit : The rpm package is the victim of itself, lol! Stefan RPM build errors: Installed (but unpackaged) file(s) found: /usr/include/beecrypt/base64.h I like this feature I think it was missing, but a warning would be better to begin than an error... lot of package will failed on rebuild. :) I don't agree: I suppose that mandrakesoft has an automated build procedure, a warning will probably go unnoticed, while a package that fails to build will surely get a maintaner attention. The result will be many less broken packages (I hope). Mandrake has no automated rebuilding process to track the impact of these kind of changes on their packages. A rebuild = a new upload. Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
Ben Reser ([EMAIL PROTECTED]) wrote: > On Thu, Nov 14, 2002 at 11:23:00AM +0100, Luca Olivetti wrote: > > > I don't agree: I suppose that mandrakesoft has an automated build > > procedure, a warning will probably go unnoticed, while a package > > that fails to build will surely get a maintainer attention. The > > result will be many less broken packages (I hope). > > The developer should be doing a build on their own machine *BEFORE* > they upload it to any system that is going to do an automated build. > And ports should only be building packages that have already been > built and tested on i586. OTOH I have seen quite a few RPMS that were build only on the packagers machine. That person rpm now depends on libraries that exist on his machine the don't exist in mdk-cooker. ie Don't upload binaries built on your machine and use the mdk build-hosts to make them. > Unfortunately, so many times people upload packages without bother to > even test them. Yes mistakes will get made. But I have to wonder how > packages with syntax errors in the perl scripts get uploaded Only > thing I can see is that someone didn't bother to test the package > first. Most Perl makefiles support the test target. When I make a Perl-SRPM I turn on that test target just to make sure everything is OK. > Ultimately this small change will not solve the problem of untested > RPMS that are screwy. It will still be a problem, until developers > take responsibility for their packages. Difficult situation. But indeed it is better to wait at least to the next day when you release a package. Don't rush it out. After a few releases I learned to recognize the feel of the rush and that I had to sit on my hands and wait until the next morning after the coffee to double-check everything. I also make packages for OpenBSD and the knowledge of that build-system is very useful for making RPMS, vice versa as well btw. //Han -- http://www.xs4all.nl/~hanb/software
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
Buchan Milne ([EMAIL PROTECTED]) wrote: > > IMHO, a more useful exit would be when a file listed in %doc doesn't > exist. At the moment, if one file in %doc is missing, all the files > after it are excluded, *silently*. You only get the warning about one > missing file, %doc exits non-zero, but rpm happily builds a bad > package. > This has caused samba to ship with only about 15% of it's docs for a > number of (not-in-final-distro) releases. You are absolutely right but that is another problem. It has nothing to do with the problem I just described here. :) //Han -- http://www.xs4all.nl/~hanb/software msg81443/pgp0.pgp Description: PGP signature
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
On Thu, Nov 14, 2002 at 11:23:00AM +0100, Luca Olivetti wrote: > I don't agree: I suppose that mandrakesoft has an automated build > procedure, a warning will probably go unnoticed, while a package that > fails to build will surely get a maintaner attention. The result will be > many less broken packages (I hope). The developer should be doing a build on their own machine *BEFORE* they upload it to any system that is going to do an automated build. And ports should only be building packages that have already been built and tested on i586. Unfortunately, so many times people upload packages without bother to even test them. Yes mistakes will get made. But I have to wonder how packages with syntax errors in the perl scripts get uploaded Only thing I can see is that someone didn't bother to test the package first. Ultimately this small change will not solve the problem of untested rpms that are screwy. It will still be a problem, until developers take responsibility for their packages. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org "If you're not making any mistakes, you're flat out not trying hard enough." - Jim Nichols
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
On Thu, Nov 14, 2002 at 12:48:42PM +0100, Gwenole Beauchesne wrote: > Exactly! Too maintainers simply don't care about their packages. This is > a means to bring attention to possible new files added through packages > updates and also fix existing packages that have missing files. So fire them. And if they aren't staff take away their permissions to modify the tree. There are plenty of us out there that do care and are willing to do a good job packaging. Ultimately bad packagers will still be bad packagers. This is one problem. There are many others that they can make. There are dozens of things that rpmlint warns about but yet packages still get uploaded with pathetic rpmlint errors in them. You have a people problem. A technical solution will not solve your problem. -- Ben Reser <[EMAIL PROTECTED]> http://ben.reser.org "If you're not making any mistakes, you're flat out not trying hard enough." - Jim Nichols
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s)found:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Han Boetes wrote: > Gwenole Beauchesne ([EMAIL PROTECTED]) wrote: > >>Exactly! Too maintainers simply don't care about their packages. This >>is a means to bring attention to possible new files added through >>packages updates and also fix existing packages that have missing >>files. > > > I had to disable the warning for two packages because it complained > about doc-files that were installed by the install target in the wrong > directory. I have to use the %doc macro for the docs. Many packages install docs to the wrong place, they should either be fixed (and the fix upstreamed) or hacked around ... preferably fixed. Of course, many packages insist on needing root permissions in their install target :-(. > > Once again I think it is a good idea to have something that tells me > that I some files are not in the package, but more than a warning is not > good. Now I have to outsmart your script and it will result in me > turning it off and then the script would loose all funtion. > > I always read all output from the rpm build process and I always use > rpmlint to search for possible errors. So if your script would warn it > would be a usefull addition. > IMHO, a more useful exit would be when a file listed in %doc doesn't exist. At the moment, if one file in %doc is missing, all the files after it are excluded, *silently*. You only get the warning about one missing file, %doc exits non-zero, but rpm happily builds a bad package. This has caused samba to ship with only about 15% of it's docs for a number of (not-in-final-distro) releases. I actually put this as a bug in bugzilla against rpm ... Tell me again, is bugzilla going to be used? Buchan - -- |Registered Linux User #182071-| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE908pgrJK6UGDSBKcRAh+qAJ9BpI3ss6iuhEV56bqOgxtpQrlkcACeN4wV hsN/lbAcZ0qbyWy1U0/0gxg= =8+X8 -END PGP SIGNATURE-
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
Gwenole Beauchesne ([EMAIL PROTECTED]) wrote: > > Exactly! Too maintainers simply don't care about their packages. This > is a means to bring attention to possible new files added through > packages updates and also fix existing packages that have missing > files. I had to disable the warning for two packages because it complained about doc-files that were installed by the install target in the wrong directory. I have to use the %doc macro for the docs. Once again I think it is a good idea to have something that tells me that I some files are not in the package, but more than a warning is not good. Now I have to outsmart your script and it will result in me turning it off and then the script would loose all funtion. I always read all output from the rpm build process and I always use rpmlint to search for possible errors. So if your script would warn it would be a usefull addition. //Han -- http://www.xs4all.nl/~hanb/software
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s)found:
Han Boetes wrote:
The real problem anyway is that the rpm spec file is too complex and
error prone.
_------__
| }
/DO NOT FEED THE TROLL \
Here's an example spec file for python in another packaging system. I
don't particularly like the syntax, but if you can tell with a straight
face that the corresponding rpm spec file is simpler, don't know who's
trolling here
W Python Interpreter - An attempt to be better than PERL
S http://www.python.org/ftp/python/{V}/{PV}.tgz
H http://www.python.org
A LICENSE PSF-2.2
R BUILD c-build
R BUILD zlib
R BUILD {READLINE}
R BUILD {READLINE?"ncurses"}
R BUILD {BERKDB}
R BUILD {TCLTK}
R BUILD expat
E Makefile.pre.in s:install-platlib.*:& --install-scripts=$(BINDIR):
A CONFOPT --with-fpectl OPT="{CFLAGS}"
--
Luca Olivetti
Note.- This message reached you today, it may not tomorrow if you
are using MAPS services. They arbitrarily include in their lists
IP addresses not related in any way to spam, and in so doing are
disrupting Internet connectivity. Please stop supporting them.
See http://slashdot.org/article.pl?sid=01/05/21/1944247
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
Luca Olivetti ([EMAIL PROTECTED]) wrote: > Olivier Thauvin wrote: > > >>fails to build will surely get a maintaner attention. The result will be > >>many less broken packages (I hope). > > > > > >Hoo, think to poeple who rebuild about 2000 packages for ppc or alpha, who > >have already to fix lot of packager error about arch specific pb... who > >have already to deal with reject upload. Try to start an automatic rebuild > >for all cooker for i686, and think you should have all packages for this > >arch, you will understand what I am saying... > > yes, I understand, it will be a PITA to fix those packages, but it is > worse to leave them unchanged and non working because of some missing file. > The real problem anyway is that the rpm spec file is too complex and > error prone. _------__ | } /DO NOT FEED THE TROLL \ \__/ ---` |#:| |#:| |#:| \\\|#:|/ / ~~~ //Han -- http://www.xs4all.nl/~hanb/software
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
Hi, Hoo, think to poeple who rebuild about 2000 packages for ppc or alpha, who have already to fix lot of packager error about arch specific pb... who have already to deal with reject upload. This *is* useful for ports. Do you think I added this for fun? Bye, Gwenole.
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
Hi, I don't agree: I suppose that mandrakesoft has an automated build procedure, a warning will probably go unnoticed, while a package that fails to build will surely get a maintaner attention. The result will be many less broken packages (I hope). Exactly! Too maintainers simply don't care about their packages. This is a means to bring attention to possible new files added through packages updates and also fix existing packages that have missing files. Bye, Gwenole
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s)found:
Olivier Thauvin wrote: fails to build will surely get a maintaner attention. The result will be many less broken packages (I hope). Hoo, think to poeple who rebuild about 2000 packages for ppc or alpha, who have already to fix lot of packager error about arch specific pb... who have already to deal with reject upload. Try to start an automatic rebuild for all cooker for i686, and think you should have all packages for this arch, you will understand what I am saying... yes, I understand, it will be a PITA to fix those packages, but it is worse to leave them unchanged and non working because of some missing file. The real problem anyway is that the rpm spec file is too complex and error prone. Bye -- Luca Olivetti Note.- This message reached you today, it may not tomorrow if you are using MAPS services. They arbitrarily include in their lists IP addresses not related in any way to spam, and in so doing are disrupting Internet connectivity. Please stop supporting them. See http://slashdot.org/article.pl?sid=01/05/21/1944247
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
Le Jeudi 14 Novembre 2002 10:23, Luca Olivetti a écrit : > Olivier Thauvin wrote: > > Le Jeudi 14 Novembre 2002 09:20, Stefan van der Eijk a écrit : > >>The rpm package is the victim of itself, lol! > >> > >>Stefan > >> > >>RPM build errors: > >>Installed (but unpackaged) file(s) found: > >> /usr/include/beecrypt/base64.h > > > > I like this feature I think it was missing, but a warning would be better > > to begin than an error... lot of package will failed on rebuild. :) > > I don't agree: I suppose that mandrakesoft has an automated build > procedure, a warning will probably go unnoticed, while a package that > fails to build will surely get a maintaner attention. The result will be > many less broken packages (I hope). Hoo, think to poeple who rebuild about 2000 packages for ppc or alpha, who have already to fix lot of packager error about arch specific pb... who have already to deal with reject upload. Try to start an automatic rebuild for all cooker for i686, and think you should have all packages for this arch, you will understand what I am saying... > > Bye -- Linux pour Mac !? Enfin le moyen de transformer une pomme en véritable ordinateur. - JL. Olivier Thauvin - http://nanardon.homelinux.org/
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s)found:
Olivier Thauvin wrote: Le Jeudi 14 Novembre 2002 09:20, Stefan van der Eijk a écrit : The rpm package is the victim of itself, lol! Stefan RPM build errors: Installed (but unpackaged) file(s) found: /usr/include/beecrypt/base64.h I like this feature I think it was missing, but a warning would be better to begin than an error... lot of package will failed on rebuild. :) I don't agree: I suppose that mandrakesoft has an automated build procedure, a warning will probably go unnoticed, while a package that fails to build will surely get a maintaner attention. The result will be many less broken packages (I hope). Bye -- Luca Olivetti Note.- This message reached you today, it may not tomorrow if you are using MAPS services. They arbitrarily include in their lists IP addresses not related in any way to spam, and in so doing are disrupting Internet connectivity. Please stop supporting them. See http://slashdot.org/article.pl?sid=01/05/21/1944247
Re: [Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
Le Jeudi 14 Novembre 2002 09:20, Stefan van der Eijk a écrit : > The rpm package is the victim of itself, lol! > > Stefan > > RPM build errors: > Installed (but unpackaged) file(s) found: >/usr/include/beecrypt/base64.h I like this feature I think it was missing, but a warning would be better to begin than an error... lot of package will failed on rebuild. :) -- Linux pour Mac !? Enfin le moyen de transformer une pomme en véritable ordinateur. - JL. Olivier Thauvin - http://nanardon.homelinux.org/
[Cooker] rpm-4.0.4-20mdk: Installed (but unpackaged) file(s) found:
The rpm package is the victim of itself, lol! Stefan RPM build errors: Installed (but unpackaged) file(s) found: /usr/include/beecrypt/base64.h /usr/include/beecrypt/beecrypt.h /usr/include/beecrypt/blockmode.h /usr/include/beecrypt/blockpad.h /usr/include/beecrypt/blowfish.h /usr/include/beecrypt/blowfishopt.h /usr/include/beecrypt/dhaes.h /usr/include/beecrypt/dldp.h /usr/include/beecrypt/dlkp.h /usr/include/beecrypt/dlpk.h /usr/include/beecrypt/dlsvdp-dh.h /usr/include/beecrypt/dsa.h /usr/include/beecrypt/elgamal.h /usr/include/beecrypt/endianness.h /usr/include/beecrypt/entropy.h /usr/include/beecrypt/fips180.h /usr/include/beecrypt/fips180opt.h /usr/include/beecrypt/fips186.h /usr/include/beecrypt/hmac.h /usr/include/beecrypt/hmacmd5.h /usr/include/beecrypt/hmacsha1.h /usr/include/beecrypt/hmacsha256.h /usr/include/beecrypt/md5.h /usr/include/beecrypt/memchunk.h /usr/include/beecrypt/mp32.h /usr/include/beecrypt/mp32barrett.h /usr/include/beecrypt/mp32number.h /usr/include/beecrypt/mp32opt.h /usr/include/beecrypt/mp32prime.h /usr/include/beecrypt/mtprng.h /usr/include/beecrypt/rsa.h /usr/include/beecrypt/rsakp.h /usr/include/beecrypt/rsapk.h /usr/include/beecrypt/sha256.h /usr/include/beecrypt/timestamp.h /usr/lib/libbeecrypt.la /usr/lib/libbeecrypt.so.2.2.0 /usr/lib/python2.2/site-packages/poptmodule.a /usr/lib/python2.2/site-packages/poptmodule.la /usr/lib/python2.2/site-packages/poptmodule.so /usr/lib/python2.2/site-packages/rpmmodule.a /usr/lib/python2.2/site-packages/rpmmodule.la /usr/lib/rpm/Specfile.pm /usr/lib/rpm/alphaev5-mandrake-linux/macros /usr/lib/rpm/alphaev56-mandrake-linux/macros /usr/lib/rpm/alphaev6-mandrake-linux/macros /usr/lib/rpm/alphaev67-mandrake-linux/macros /usr/lib/rpm/alphapca56-mandrake-linux/macros /usr/lib/rpm/config.site /usr/lib/rpm/cpanflute2 /usr/lib/rpm/cross-build /usr/lib/rpm/rpm2cpio.sh /usr/lib/rpm/sql.prov /usr/lib/rpm/sql.req /usr/lib/rpm/tcl.req /usr/lib/rpm/trpm
