Description of problem: In the postinstall script of mailman this is found: postinstall scriptlet (using /bin/sh): # Clean out any byte-compiled python modules and recompile them. find /var/mailman -name "*.pyc" -exec rm -f '{}' ';' /usr/bin/python -c 'from compileall import *; compile_dir("/var/mailman",10,"/var/mailman")' > /dev/null 2>&1 Because of this, rpm -V is virtually worthless and rpm -Va has lots extra output. Is this a problem? I don't know. SM5....T /var/mailman/pythonlib/email/Charset.pyc SM5....T /var/mailman/pythonlib/email/Encoders.pyc SM5....T /var/mailman/pythonlib/email/Errors.pyc SM5....T /var/mailman/pythonlib/email/Generator.pyc SM5....T /var/mailman/pythonlib/email/Header.pyc SM5....T /var/mailman/pythonlib/email/Iterators.pyc SM5....T /var/mailman/pythonlib/email/MIMEAudio.pyc SM5....T /var/mailman/pythonlib/email/MIMEBase.pyc SM5....T /var/mailman/pythonlib/email/MIMEImage.pyc SM5....T /var/mailman/pythonlib/email/MIMEMessage.pyc SM5....T /var/mailman/pythonlib/email/MIMEMultipart.pyc SM5....T /var/mailman/pythonlib/email/MIMENonMultipart.pyc SM5....T /var/mailman/pythonlib/email/MIMEText.pyc SM5....T /var/mailman/pythonlib/email/Message.pyc SM5....T /var/mailman/pythonlib/email/Parser.pyc SM5....T /var/mailman/pythonlib/email/Utils.pyc SM5....T /var/mailman/pythonlib/email/__init__.pyc SM5....T /var/mailman/pythonlib/email/_compat21.pyc SM5....T /var/mailman/pythonlib/email/_compat22.pyc SM5....T /var/mailman/pythonlib/email/_parseaddr.pyc SM5....T /var/mailman/pythonlib/email/base64MIME.pyc SM5....T /var/mailman/pythonlib/email/quopriMIME.pyc SM5....T /var/mailman/pythonlib/japanese/__init__.pyc SM5....T /var/mailman/pythonlib/japanese/aliases/__init__.pyc SM5....T /var/mailman/pythonlib/japanese/c/__init__.pyc SM5....T /var/mailman/pythonlib/japanese/c/euc_jp.pyc SM5....T /var/mailman/pythonlib/japanese/c/iso_2022_jp.pyc SM5....T /var/mailman/pythonlib/japanese/c/iso_2022_jp_1.pyc SM5....T /var/mailman/pythonlib/japanese/c/iso_2022_jp_ext.pyc SM5....T /var/mailman/pythonlib/japanese/c/ms932.pyc SM5....T /var/mailman/pythonlib/japanese/c/shift_jis.pyc SM5....T /var/mailman/pythonlib/japanese/euc_jp.pyc SM5....T /var/mailman/pythonlib/japanese/iso_2022_jp.pyc SM5....T /var/mailman/pythonlib/japanese/iso_2022_jp_1.pyc SM5....T /var/mailman/pythonlib/japanese/iso_2022_jp_ext.pyc SM5....T /var/mailman/pythonlib/japanese/jis_7.pyc SM5....T /var/mailman/pythonlib/japanese/jis_x_0201_katakana.pyc SM5....T /var/mailman/pythonlib/japanese/jis_x_0201_roman.pyc SM5....T /var/mailman/pythonlib/japanese/mappings/__init__.pyc SM5....T /var/mailman/pythonlib/japanese/mappings/euc_jp.pyc SM5....T /var/mailman/pythonlib/japanese/mappings/jis_x_0208.pyc SM5....T /var/mailman/pythonlib/japanese/mappings/jis_x_0212.pyc SM5....T /var/mailman/pythonlib/japanese/mappings/shift_jis.pyc SM5....T /var/mailman/pythonlib/japanese/ms932.pyc SM5....T /var/mailman/pythonlib/japanese/python/__init__.pyc SM5....T /var/mailman/pythonlib/japanese/python/euc_jp.pyc SM5....T /var/mailman/pythonlib/japanese/python/iso_2022_jp.pyc SM5....T /var/mailman/pythonlib/japanese/python/iso_2022_jp_1.pyc SM5....T /var/mailman/pythonlib/japanese/python/iso_2022_jp_ext.pyc SM5....T /var/mailman/pythonlib/japanese/python/shift_jis.pyc SM5....T /var/mailman/pythonlib/japanese/shift_jis.pyc SM5....T /var/mailman/pythonlib/japanese/sjis.pyc SM5....T /var/mailman/pythonlib/japanese/ujis.pyc SM5....T /var/mailman/pythonlib/japanese/windows_31j.pyc SM5....T /var/mailman/pythonlib/korean/__init__.pyc SM5....T /var/mailman/pythonlib/korean/aliases.pyc SM5....T /var/mailman/pythonlib/korean/c/__init__.pyc SM5....T /var/mailman/pythonlib/korean/c/cp949.pyc SM5....T /var/mailman/pythonlib/korean/c/euc_kr.pyc SM5....T /var/mailman/pythonlib/korean/cp949.pyc SM5....T /var/mailman/pythonlib/korean/euc_kr.pyc SM5....T /var/mailman/pythonlib/korean/hangul.pyc SM5....T /var/mailman/pythonlib/korean/iso_2022_kr.pyc SM5....T /var/mailman/pythonlib/korean/johab.pyc SM5....T /var/mailman/pythonlib/korean/mappings/__init__.pyc SM5....T /var/mailman/pythonlib/korean/mappings/johab_ideograph.pyc SM5....T /var/mailman/pythonlib/korean/mappings/ksc5601_hangul.pyc SM5....T /var/mailman/pythonlib/korean/mappings/ksc5601_ideograph.pyc SM5....T /var/mailman/pythonlib/korean/mappings/ksc5601_misc.pyc SM5....T /var/mailman/pythonlib/korean/mappings/uhc.pyc SM5....T /var/mailman/pythonlib/korean/python/__init__.pyc SM5....T /var/mailman/pythonlib/korean/python/cp949.pyc SM5....T /var/mailman/pythonlib/korean/python/euc_kr.pyc SM5....T /var/mailman/pythonlib/korean/python/hangul.pyc SM5....T /var/mailman/pythonlib/korean/python/iso_2022_kr.pyc SM5....T /var/mailman/pythonlib/korean/python/johab.pyc SM5....T /var/mailman/pythonlib/korean/python/qwerty2bul.pyc SM5....T /var/mailman/pythonlib/korean/python/unijohab.pyc SM5....T /var/mailman/pythonlib/korean/qwerty2bul.pyc SM5....T /var/mailman/pythonlib/korean/unijohab.pyc
This should really be done as part of %build/%install, not %post.
It can't be done as part of %build/%install or I would have. The problem is that when the python files are compiled they reference files in their installed location (sans the buildroot), hence the compilation fails. Compiling the python files in %post is a far easier solution than reworking the upstream sources. FWIW, mailman is explicitly designed to be built on the machine its being installed on, thats the upstream philosophy, this has played havoc over and over again with our rpm which builds another way. I've made many fixes to accomodate our build already. Compiling in %post feels like the right level of investment. BTW, the real problem is that when the build is done, pathnames have been hardcoded into the sources as part of the build process.
added you Bill to the CC list as my last edit was in reply to you.
Created attachment 94766 [details] python byte-compiler Here's a way to do it that should fix paths too. It's been discussed to make this a normal thing done as part of the build process.
"FWIW, mailman is explicitly designed to be built on the machine its being installed on, thats the upstream philosophy" AFAIK this is no longer the case with Mailman 2.1.2 (released 04/2003). From the NEWS file: - When running make to build Mailman, you can specify $DESTDIR to the install target to specify an alternative location for installation, without influencing the paths stored in e.g. Defaults.py. This is useful to package managers.
feh...maybe that doesn't apply to the bytecode...
I'll look into it, but for what its worth its not Defaults.py thats the culprit, its paths.py. I'm going on memory here so I may get some of the details wrong but I believe what happens is this: paths.py is created from paths.py.in as part of "configure", this creates a paths.py with path names that are for the actual installation, these are from configure. The effect is that paths.py has hardcoded paths. There are several files that get byte compiled which import paths.py and reference files off one of those paths, the compiler can't find the file during an rpm build because the file really lives in buildroot. I would be surprised if the python module Bill referenced would help in this instance as I believe its modifying default python paths and would not effect a fully qualified pathname being referenced during an import.
Oh, sorry, paths *in mailman*. I thought you meant the traceback paths in the compiled python files.
Similar issue for up2date is bug 69205.
http://togami.com/~warren/fedora/mailman-2.1.4-2test.src.rpm * Tue May 04 2004 Warren Togami <wtogami> 3:2.1.4-2test - #105638 fix bytecompile and rpm -V - postun /etc/postfix/aliases fix - clean uninstall (no more empty dirs) I haven't tested this in runtime, but msw said that this *should* fix it. I could be wrong however... Please test.
Warren, I rebuilt, and upgraded to this version and I can report that rpm -V mailman no longer produces changed md5sums. This is the output I get after upgrade: [helios@fc1 i386]$ rpm -V mailman S.5....T c /etc/httpd/conf.d/mailman.conf S.5....T /var/mailman/Mailman/mm_cfg.pyc [helios@fc1 i386]$ I was previously getting the changed hashs as reported by Dax Kelson. ALso, if it matters, mailman still functions correctly. Is this the kind of test feedback required?
Yes that is exactly the feedback I needed. I hope to get more positive feedback though from other users. If you can, please test other less commonly used functions like creating/deleting lists, and other stuff in the bin directory.
OK. Summary of tests: o ./rmlist -a old-list - worked fine o ./newlist test-list test-list-admin tlapass - worked fine o ./add_members -r emaillist test-list - worked fine o ./remove_members -f emaillist -nN test-list - worked fine o ./change_pw -l test-list -p newtlapass - worked fine o ./arch --wipe test-list - worked fine o Sending email to the list as a newly created member - worked fine o Viewing archives - worked fine o Changing options in administrative interface - worked fine So, yea, everything seems dandy. :-) Anything else you'd like tested I didn't cover?
mailman-2.1.4-4 heading to rawhide, pretty much the same thing as the above test package.
Will a similar fix be added to up2date and other python packages?