From rdieter at math.unl.edu Wed Nov 1 13:11:11 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 01 Nov 2006 07:11:11 -0600 Subject: [Fedora-packaging] Re: Fwd: [Bug 206860] GTK+ icon cache "bugs" on ScriptletSnippets In-Reply-To: <200611010110.21540.nman64@n-man.com> References: <200611010110.21540.nman64@n-man.com> Message-ID: <45489CEF.2060607@math.unl.edu> Patrick W. Barnes wrote: > Can we get this reviewed and, if appropriate, fixed on the wiki? > > http://bugzilla.redhat.com/206860 > > I honestly don't care if there's a better solution forthcoming, but as long as > this information is provided on the wiki, it should be as accurate as > possible. Until something better does come along(*), imo, the simplest workaround is to simply ignore gtk-update-icon-cache's output, and use something like: %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor 2>/dev/null || : (*) http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache From meyering at redhat.com Fri Nov 3 20:22:47 2006 From: meyering at redhat.com (Jim Meyering) Date: Fri, 03 Nov 2006 21:22:47 +0100 Subject: [Fedora-packaging] proposed "should" requirement: clean "make check" run w/valgrind Message-ID: <878xiscmaw.fsf@rho.meyering.net> Hello, I'd like to suggest that you add a guideline (perhaps even a "should"-style one) that encourages packagers to ensure their tests pass also when run via valgrind. I suspect that there are far too many packages with serious, latent bugs that would be exposed by such testing. Better that people find them now (ASAP) and fix them, than waiting for reports of hard-to-reproduce failures or news of black hat exploits. It is not onerous to require this, because it is so easy to automate. In addition to running tests via "make check", each package can also run its tests via e.g., env "PATH=/some/new/temp/dir:$PATH" make check 3> log where the temporary directory, /some/new/temp/dir, contains one or more tiny wrapper scripts, each arranging to run a tested application via valgrind. Here's one named "rm" that I've used in testing that program for the GNU coreutils: #!/bin/sh export PATH=/cu/src:/sbin:/usr/sbin:/bin exec /usr/bin/valgrind -v --suppressions=/tmp/cu-vg --log-fd=3 \ --leak-check=full --track-fds=yes --num-callers=15 -- rm "$@" Note how the PATH setting in that script lists the absolute build directory (in my case, "/cu/src"), first in the PATH. The following PATH dirs are necessary in case the program under test uses $PATH -- you might need others, e.g., /usr/local/bin. If you're in a position to generate the file, just append the original value of $PATH. I chose to log to file descriptor 3 (--log-fd=3), so ran the make check with the "3> log" suffix to redirect that output. If you prefer, use --log-file-exactly=log or --log-file=log. When using valgrind, you will inevitably find warnings that should be ignored, say because they come from libraries not under test (and hoping that they are harmless). Such warnings are highly dependent on the version of your C library, valgrind, and maybe on the kernel, too. In order to avoid the distraction of such warnings (about which you can typically do nothing), you can use a valgrind suppression file. Above, I used the --suppressions=/tmp/cu-vg option. The wrapper script above also tracks file descriptor usage (--track-fds=yes), so that if there is a file descriptor leak, valgrind will report it. Similarly, it uses --leak-check=full to check for memory leaks. Finally, I've found it useful to record more than the default number of stack frames (--num-callers=15), but admit that does cause a bit of a performance hit. Jim From jkeating at redhat.com Fri Nov 3 21:16:50 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 3 Nov 2006 16:16:50 -0500 Subject: [Fedora-packaging] proposed "should" requirement: clean "make check" run w/valgrind In-Reply-To: <878xiscmaw.fsf@rho.meyering.net> References: <878xiscmaw.fsf@rho.meyering.net> Message-ID: <200611031616.50908.jkeating@redhat.com> On Friday 03 November 2006 15:22, Jim Meyering wrote: > It is not onerous to require this, because it is so easy to automate. > In addition to running tests via "make check", each package can also > run its tests via e.g., > > ? env "PATH=/some/new/temp/dir:$PATH" make check 3> log > > where the temporary directory, /some/new/temp/dir, contains one or > more tiny wrapper scripts, each arranging to run a tested application > via valgrind. ?Here's one named "rm" that I've used in testing that > program for the GNU coreutils: > > #!/bin/sh > export PATH=/cu/src:/sbin:/usr/sbin:/bin > exec /usr/bin/valgrind -v --suppressions=/tmp/cu-vg --log-fd=3 \ > ? --leak-check=full --track-fds=yes --num-callers=15 -- rm "$@" Is there any way to make this easier? A wrapper around everything perhaps? Something that could be done in mock? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From meyering at redhat.com Sat Nov 4 12:49:55 2006 From: meyering at redhat.com (Jim Meyering) Date: Sat, 04 Nov 2006 13:49:55 +0100 Subject: [Fedora-packaging] proposed "should" requirement: clean "make check" run w/valgrind In-Reply-To: <200611031616.50908.jkeating@redhat.com> (Jesse Keating's message of "Fri, 3 Nov 2006 16:16:50 -0500") References: <878xiscmaw.fsf@rho.meyering.net> <200611031616.50908.jkeating@redhat.com> Message-ID: <878xirbclo.fsf@rho.meyering.net> Jesse Keating wrote: > On Friday 03 November 2006 15:22, Jim Meyering wrote: >> It is not onerous to require this, because it is so easy to automate. >> In addition to running tests via "make check", each package can also >> run its tests via e.g., >> >> env "PATH=/some/new/temp/dir:$PATH" make check 3> log >> >> where the temporary directory, /some/new/temp/dir, contains one or >> more tiny wrapper scripts, each arranging to run a tested application >> via valgrind. Here's one named "rm" that I've used in testing that >> program for the GNU coreutils: >> >> #!/bin/sh >> export PATH=/cu/src:/sbin:/usr/sbin:/bin >> exec /usr/bin/valgrind -v --suppressions=/tmp/cu-vg --log-fd=3 \ >> --leak-check=full --track-fds=yes --num-callers=15 -- rm "$@" > > Is there any way to make this easier? A wrapper around everything perhaps? > Something that could be done in mock? Yes, I think so. The idea is to create this temporary directory, populate it with a 4-line script (like the above) for each binary that is built by the package under test. That's the easy part, since in mock, you'll know the build dir, which needs to be first in PATH, above. The harder part is to arrange for that temporary directory to be at the front of the PATH used for "make check". In coreutils, I ended up changing e.g., tests/rm/Makefile.am from this TESTS_ENVIRONMENT = \ PATH="`pwd`/../../src$(PATH_SEPARATOR)$$PATH" ... to this: TESTS_ENVIRONMENT = \ PATH="$(VG_PATH_PREFIX)`pwd`/../../src$(PATH_SEPARATOR)$$PATH" ... so I can build normally, or set VG_PATH_PREFIX=/tmp/T: to run things through valgrind: (where /tmp/T is the temp. directory containing all of those just-generated scripts) VG_PATH_PREFIX=/tmp/T: make check I've just realized there's a better way to write the script above. Just compute the name of the program under test from the name of the script: #!/bin/sh export PATH=@BUILD_DIR@:/sbin:/usr/sbin:/bin prog=${0##*/} exec /usr/bin/valgrind -v --suppressions=/tmp/cu-vg --log-fd=3 \ --leak-check=full --track-fds=yes --num-callers=15 -- "$prog" "$@" Now, the only variable is the part marked with @BUILD_DIR at . Oh. Also the suppressions file name. From jkeating at redhat.com Sat Nov 4 13:24:35 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 4 Nov 2006 08:24:35 -0500 Subject: [Fedora-packaging] proposed "should" requirement: clean "make check" run w/valgrind In-Reply-To: <878xirbclo.fsf@rho.meyering.net> References: <878xiscmaw.fsf@rho.meyering.net> <200611031616.50908.jkeating@redhat.com> <878xirbclo.fsf@rho.meyering.net> Message-ID: <200611040824.35618.jkeating@redhat.com> On Saturday 04 November 2006 07:49, Jim Meyering wrote: > I've just realized there's a better way to write the script above. > Just compute the name of the program under test from the name of > the script: > > ? ? #!/bin/sh > ? ? export PATH=@BUILD_DIR@:/sbin:/usr/sbin:/bin > ? ? prog=${0##*/} > ? ? exec /usr/bin/valgrind -v --suppressions=/tmp/cu-vg --log-fd=3 \ > ? ? ? --leak-check=full --track-fds=yes --num-callers=15 -- "$prog" "$@" > > Now, the only variable is the part marked with @BUILD_DIR at . > Oh. ?Also the suppressions file name. Wouldn't the reviewer/packager still have to know every binary name produced and write a script for each? Is there no easier way? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From meyering at redhat.com Sat Nov 4 14:38:52 2006 From: meyering at redhat.com (Jim Meyering) Date: Sat, 04 Nov 2006 15:38:52 +0100 Subject: [Fedora-packaging] proposed "should" requirement: clean "make check" run w/valgrind In-Reply-To: <200611040824.35618.jkeating@redhat.com> (Jesse Keating's message of "Sat, 4 Nov 2006 08:24:35 -0500") References: <878xiscmaw.fsf@rho.meyering.net> <200611031616.50908.jkeating@redhat.com> <878xirbclo.fsf@rho.meyering.net> <200611040824.35618.jkeating@redhat.com> Message-ID: <87y7qr9szn.fsf@rho.meyering.net> Jesse Keating wrote: > On Saturday 04 November 2006 07:49, Jim Meyering wrote: >> I've just realized there's a better way to write the script above. >> Just compute the name of the program under test from the name of >> the script: >> >> ? ? #!/bin/sh >> ? ? export PATH=@BUILD_DIR@:/sbin:/usr/sbin:/bin >> ? ? prog=${0##*/} >> ? ? exec /usr/bin/valgrind -v --suppressions=/tmp/cu-vg --log-fd=3 \ >> ? ? ? --leak-check=full --track-fds=yes --num-callers=15 -- "$prog" "$@" >> >> Now, the only variable is the part marked with @BUILD_DIR at . >> Oh. ?Also the suppressions file name. > > Wouldn't the reviewer/packager still have to know every binary name produced > and write a script for each? Is there no easier way? In automake-based packages, the list of binary program names is often in the $(bin_PROGRAMS) makefile variable. Knowing that, it should be easy to create the temporary directory and populate it with one copy of the above script for each name. IMHO, that part is not hard. Here's a Bourne shell snippet to extract the names of programs from a coreutils build directory in which you've already run configure: coreutils=$(echo 'spy:;@echo $(all_programs)' | (cd src; make -f Makefile -f - spy | tr -s '\n ' ' ')) The part that will usually require manual intervention is the one where you arrange for the PATH used by "make check" (or whatever else runs their test suite) to have that temporary directory first. This part is probably manual by definition, since any test suite must first ensure that PATH has the build directory before any other -- so it can test what's just been built. Now, we want some other directory to be first, so have to make that PATH setting be conditional on whether we're trying to test via valgrind or not. -------------------- Hey! Maybe there *is* an easier way. Instead of presuming we have to leave just-built binaries where the build process put them, we could replace each with the little valgrind-invoking wrapper script, and move the original binary into a subdirectory. The only drawback is that once you've replaced the binary with the wrapper script, any attempt to do e.g., "make install" will do the wrong thing. But even that isn't a problem: just be sure to run "make clean" after the tests -- or simply remove all of those scripts. For example, move each binary "down" one level, into say, .vg-tmp, then put a copy of this script in its place: #!/bin/sh saved_binaries_dir="${0%/*}/.vg-tmp" export PATH=$saved_binaries_dir:/sbin:/usr/sbin:/bin prog=${0##*/} exec /usr/bin/valgrind -v --suppressions=/tmp/cu-vg \ --log-file-exactly=/tmp/vg-log \ --leak-check=full --track-fds=yes --num-callers=15 -- "$prog" "$@" Then, there's no need to modify Makefiles at all. I've changed to --log-file-exactly=/tmp/vg-log above, so that you don't have to redirect fd-3 -- that would have been too easy to forget, and when you do, the diagnostic is too cryptic. From jkeating at redhat.com Sat Nov 4 15:23:31 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 4 Nov 2006 10:23:31 -0500 Subject: [Fedora-packaging] proposed "should" requirement: clean "make check" run w/valgrind In-Reply-To: <87y7qr9szn.fsf@rho.meyering.net> References: <878xiscmaw.fsf@rho.meyering.net> <200611040824.35618.jkeating@redhat.com> <87y7qr9szn.fsf@rho.meyering.net> Message-ID: <200611041023.36031.jkeating@redhat.com> On Saturday 04 November 2006 09:38, Jim Meyering wrote: > Hey! ?Maybe there *is* an easier way. So how would you write this up in the wiki to explain to reviewers and packagers? Remember, the majority of our maintainers are just packagers, not necessarily developers. This has to be really easy and simple to do, along the lines of rpmlint. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Sat Nov 4 15:46:42 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 04 Nov 2006 09:46:42 -0600 Subject: [Fedora-packaging] proposed "should" requirement: clean "make check" run w/valgrind In-Reply-To: <200611041023.36031.jkeating@redhat.com> References: <878xiscmaw.fsf@rho.meyering.net> <200611040824.35618.jkeating@redhat.com> <87y7qr9szn.fsf@rho.meyering.net> <200611041023.36031.jkeating@redhat.com> Message-ID: <454CB5E2.7050704@math.unl.edu> Jesse Keating wrote: > On Saturday 04 November 2006 09:38, Jim Meyering wrote: >> Hey! Maybe there *is* an easier way. > > So how would you write this up in the wiki to explain to reviewers and > packagers? Remember, the majority of our maintainers are just packagers, not > necessarily developers. This has to be really easy and simple to do, along > the lines of rpmlint. Imo, this is outside the scope of package reviews, and more in line with a QA SIG. -- Rex From meyering at redhat.com Sat Nov 4 17:11:40 2006 From: meyering at redhat.com (Jim Meyering) Date: Sat, 04 Nov 2006 18:11:40 +0100 Subject: [Fedora-packaging] proposed "should" requirement: clean "make check" run w/valgrind In-Reply-To: <200611041023.36031.jkeating@redhat.com> (Jesse Keating's message of "Sat, 4 Nov 2006 10:23:31 -0500") References: <878xiscmaw.fsf@rho.meyering.net> <200611040824.35618.jkeating@redhat.com> <87y7qr9szn.fsf@rho.meyering.net> <200611041023.36031.jkeating@redhat.com> Message-ID: <87slgz9lwz.fsf@rho.meyering.net> Jesse Keating wrote: > On Saturday 04 November 2006 09:38, Jim Meyering wrote: >> Hey! ?Maybe there *is* an easier way. > > So how would you write this up in the wiki to explain to reviewers and > packagers? Remember, the majority of our maintainers are just packagers, not > necessarily developers. This has to be really easy and simple to do, along > the lines of rpmlint. I can imagine a tool that'd take an RPM -- or even just a tarball where "configure && make" works -- build (maybe with CFLAGS=-g for better stack traces), and use a heuristic to identify the just-built binaries (e.g., find+file so it doesn't depend on whether the package uses automake). Then it would move each binary into a "."-relative temporary subdir and put the wrapper script in its place. Finally, it'd run "make check" or "make test", and search the valgrind log for warnings and errors. Given such a tool, the wiki instructions would be simply: Run this command: vg-rpm your-package.rpm If it reports any errors, or memory or file-descriptor leaks, try to determine whether they originate in your package. Errors may originate in a library used by your package, in which case you should append a valgrind suppression[*] to some well-known file that is already included in your package. If you don't have such a file yet, add it, and ensure that it becomes part of the RPM. Of course, you should also inform the upstream library maintainer of the problem and see if they can fix it. [*] not hard, but would require instructions. From jkeating at redhat.com Sat Nov 4 21:28:29 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 4 Nov 2006 16:28:29 -0500 Subject: [Fedora-packaging] proposed "should" requirement: clean "make check" run w/valgrind In-Reply-To: <87slgz9lwz.fsf@rho.meyering.net> References: <878xiscmaw.fsf@rho.meyering.net> <200611041023.36031.jkeating@redhat.com> <87slgz9lwz.fsf@rho.meyering.net> Message-ID: <200611041628.29322.jkeating@redhat.com> On Saturday 04 November 2006 12:11, Jim Meyering wrote: > Given such a tool, the wiki instructions would be simply: > > Run this command: > > ? vg-rpm your-package.rpm Great! When will this tool land in Extras? (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Tue Nov 7 15:49:52 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 07 Nov 2006 09:49:52 -0600 Subject: [Fedora-packaging] missing today's meeting Message-ID: <4550AB20.7040407@math.unl.edu> Sorry foiks, I won't be able to make today's packaging meeting. -- Rex From jkeating at redhat.com Fri Nov 10 19:19:54 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 10 Nov 2006 14:19:54 -0500 Subject: [Fedora-packaging] python listed explicitly as exception and added to buildsys-build groups Message-ID: <200611101419.54978.jkeating@redhat.com> So at one point in time, it would appear that something in http://fedoraproject.org/wiki/Packaging/Guidelines#head-4cadce5e79d38a63cad3941de1dadc9d25d67d30 pulled in python, according to http://fedoraproject.org/wiki/Extras/FullExceptionList However now it doesn't seem to happen, and python isn't being installed by default in buildroots. Python is a pretty integral part of our distribution and a lot of assumptions are made that python is there, even at build time. I would like to propose that we add python to the Exception list so that it can't ever disappear again. We list perl explicitly, even though its pulled in via rpm-build (and a couple other things), so why not python? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Fri Nov 10 19:21:57 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 10 Nov 2006 14:21:57 -0500 Subject: [Fedora-packaging] python listed explicitly as exception and added to buildsys-build groups In-Reply-To: <200611101419.54978.jkeating@redhat.com> References: <200611101419.54978.jkeating@redhat.com> Message-ID: <20061110192157.GA19385@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > However now it doesn't seem to happen, and python isn't being installed by > default in buildroots. Python is a pretty integral part of our distribution > and a lot of assumptions are made that python is there, even at build time. > I would like to propose that we add python to the Exception list so that it > can't ever disappear again. We list perl explicitly, even though its pulled > in via rpm-build (and a couple other things), so why not python? What expects python to be there that doesn't have a Requires: (build tool) or BuildRequires (source package)? Bill From jkeating at redhat.com Fri Nov 10 19:26:05 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 10 Nov 2006 14:26:05 -0500 Subject: [Fedora-packaging] python listed explicitly as exception and added to buildsys-build groups In-Reply-To: <20061110192157.GA19385@nostromo.devel.redhat.com> References: <200611101419.54978.jkeating@redhat.com> <20061110192157.GA19385@nostromo.devel.redhat.com> Message-ID: <200611101426.08331.jkeating@redhat.com> On Friday 10 November 2006 14:21, Bill Nottingham wrote: > What expects python to be there that doesn't have a Requires: (build tool) > or BuildRequires (source package)? I think all the current python module packages don't BuildRequire python. Nor requires either, since that's automatically done by rpm now (provided python is in the buildroot) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Fri Nov 10 19:27:26 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 10 Nov 2006 14:27:26 -0500 Subject: [Fedora-packaging] python listed explicitly as exception and added to buildsys-build groups In-Reply-To: <200611101426.08331.jkeating@redhat.com> References: <200611101419.54978.jkeating@redhat.com> <20061110192157.GA19385@nostromo.devel.redhat.com> <200611101426.08331.jkeating@redhat.com> Message-ID: <20061110192726.GB19317@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > I think all the current python module packages don't BuildRequire python. Nor > requires either, since that's automatically done by rpm now (provided python > is in the buildroot) Not all of them, and I think it's wrong to think they shouldn't. At least the ones I've packaged BR python & python-devel. Bill From jkeating at redhat.com Fri Nov 10 19:35:42 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 10 Nov 2006 14:35:42 -0500 Subject: [Fedora-packaging] python listed explicitly as exception and added to buildsys-build groups In-Reply-To: <20061110192726.GB19317@nostromo.devel.redhat.com> References: <200611101419.54978.jkeating@redhat.com> <200611101426.08331.jkeating@redhat.com> <20061110192726.GB19317@nostromo.devel.redhat.com> Message-ID: <200611101435.43148.jkeating@redhat.com> On Friday 10 November 2006 14:27, Bill Nottingham wrote: > Not all of them, and I think it's wrong to think they shouldn't. At > least the ones I've packaged BR python & python-devel. Hrm, well, I guess the point here is that python used to get pulled in because of some dep, now it isn't. Do we want to live with this, or do we want to add python back in manually? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tibbs at math.uh.edu Fri Nov 10 19:44:37 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 10 Nov 2006 13:44:37 -0600 Subject: [Fedora-packaging] python listed explicitly as exception and added to buildsys-build groups In-Reply-To: <200611101435.43148.jkeating@redhat.com> References: <200611101419.54978.jkeating@redhat.com> <200611101426.08331.jkeating@redhat.com> <20061110192726.GB19317@nostromo.devel.redhat.com> <200611101435.43148.jkeating@redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> Hrm, well, I guess the point here is that python used to get JK> pulled in because of some dep, now it isn't. Do we want to live JK> with this, or do we want to add python back in manually? Did this break post-FC6? If so, it might be reasonable to move towards living with no Python in the buildroot. Having the minimal buildroot actually be minimal is a worthy goal. However, this would mean that Python module specfiles will have to adapt to some method like what Ruby and PHP modules have to cope with, where the interpreters aren't there during the first pass through the specfile. Generally this is pretty simple to handle. - J< From jkeating at redhat.com Fri Nov 10 19:51:07 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 10 Nov 2006 14:51:07 -0500 Subject: [Fedora-packaging] python listed explicitly as exception and added to buildsys-build groups In-Reply-To: References: <200611101419.54978.jkeating@redhat.com> <200611101435.43148.jkeating@redhat.com> Message-ID: <200611101451.07551.jkeating@redhat.com> On Friday 10 November 2006 14:44, Jason L Tibbitts III wrote: > Did this break post-FC6? ?If so, it might be reasonable to move > towards living with no Python in the buildroot. ?Having the minimal > buildroot actually be minimal is a worthy goal. Yes, it appears this is post-fc6, at what point I haven't researched/figured out yet. > However, this would mean that Python module specfiles will have to > adapt to some method like what Ruby and PHP modules have to cope with, > where the interpreters aren't there during the first pass through the > specfile. ?Generally this is pretty simple to handle. Yeah, and it would mean either doing fun if wrappers on fedora version or forking spec files between devel and FC6<= -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From notting at redhat.com Fri Nov 10 19:52:30 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 10 Nov 2006 14:52:30 -0500 Subject: [Fedora-packaging] python listed explicitly as exception and added to buildsys-build groups In-Reply-To: <200611101451.07551.jkeating@redhat.com> References: <200611101419.54978.jkeating@redhat.com> <200611101435.43148.jkeating@redhat.com> <200611101451.07551.jkeating@redhat.com> Message-ID: <20061110195230.GA11633@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > > However, this would mean that Python module specfiles will have to > > adapt to some method like what Ruby and PHP modules have to cope with, > > where the interpreters aren't there during the first pass through the > > specfile. ?Generally this is pretty simple to handle. > > Yeah, and it would mean either doing fun if wrappers on fedora version or > forking spec files between devel and FC6<= Why would it be something that would break if python is in the build root? Bill From jkeating at redhat.com Fri Nov 10 20:04:12 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 10 Nov 2006 15:04:12 -0500 Subject: [Fedora-packaging] python listed explicitly as exception and added to buildsys-build groups In-Reply-To: <20061110195230.GA11633@nostromo.devel.redhat.com> References: <200611101419.54978.jkeating@redhat.com> <200611101451.07551.jkeating@redhat.com> <20061110195230.GA11633@nostromo.devel.redhat.com> Message-ID: <200611101504.12877.jkeating@redhat.com> On Friday 10 November 2006 14:52, Bill Nottingham wrote: > Why would it be something that would break if python is in the build root? True, it probably wouldn't break, it just wouldn't be necessary. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Nov 10 20:10:07 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 10 Nov 2006 21:10:07 +0100 Subject: [Fedora-packaging] python listed explicitly as exception and added to buildsys-build groups In-Reply-To: <200611101504.12877.jkeating@redhat.com> References: <200611101419.54978.jkeating@redhat.com> <200611101451.07551.jkeating@redhat.com> <20061110195230.GA11633@nostromo.devel.redhat.com> <200611101504.12877.jkeating@redhat.com> Message-ID: <20061110211007.529444af@python3.es.egwn.lan> Jesse Keating wrote : > On Friday 10 November 2006 14:52, Bill Nottingham wrote: > > Why would it be something that would break if python is in the build root? > > True, it probably wouldn't break, it just wouldn't be necessary. Yup. I myself don't find it so odd to have "BuildRequires: python" for all python modules, and that retrofits nicely to any distro release. All this does remind me of the "old days" when python-devel didn't pull in python... it produced even less expected results ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.18-1.2835.fc6 Load : 1.39 1.17 0.73 From jkeating at redhat.com Fri Nov 10 20:13:21 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 10 Nov 2006 15:13:21 -0500 Subject: [Fedora-packaging] python listed explicitly as exception and added to buildsys-build groups In-Reply-To: <20061110211007.529444af@python3.es.egwn.lan> References: <200611101419.54978.jkeating@redhat.com> <200611101504.12877.jkeating@redhat.com> <20061110211007.529444af@python3.es.egwn.lan> Message-ID: <200611101513.21282.jkeating@redhat.com> On Friday 10 November 2006 15:10, Matthias Saou wrote: > Yup. I myself don't find it so odd to have "BuildRequires: python" for > all python modules, and that retrofits nicely to any distro release. > > All this does remind me of the "old days" when python-devel didn't pull > in python... it produced even less expected results Well, for "pure python" packages, there is no 'building' involved. Just copying the files to a specific location. However things that use distutils, then yeah, I can understand build requiring the python dist-utils module, or just python since its included (do we have something for python like perl's perl(Foo::bar) stuff?) -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dlutter at redhat.com Fri Nov 10 23:43:51 2006 From: dlutter at redhat.com (David Lutterkort) Date: Fri, 10 Nov 2006 23:43:51 +0000 Subject: [Fedora-packaging] python listed explicitly as exception and added to buildsys-build groups In-Reply-To: <20061110192726.GB19317@nostromo.devel.redhat.com> References: <200611101419.54978.jkeating@redhat.com> <20061110192157.GA19385@nostromo.devel.redhat.com> <200611101426.08331.jkeating@redhat.com> <20061110192726.GB19317@nostromo.devel.redhat.com> Message-ID: <1163202231.7535.57.camel@localhost.localdomain> On Fri, 2006-11-10 at 14:27 -0500, Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: > > I think all the current python module packages don't BuildRequire python. Nor > > requires either, since that's automatically done by rpm now (provided python > > is in the buildroot) > > Not all of them, and I think it's wrong to think they shouldn't. At > least the ones I've packaged BR python & python-devel. There are definitely some. I got bitten by that a while ago when trying to rebuild an FE package in a RHEL mock root. And I don't see any danger in formalizing that python is an exception; it's been treated that way for a long time. David From Matt_Domsch at dell.com Sat Nov 11 14:08:26 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sat, 11 Nov 2006 08:08:26 -0600 Subject: [Fedora-packaging] python listed explicitly as exception and added to buildsys-build groups In-Reply-To: <1163202231.7535.57.camel@localhost.localdomain> References: <200611101419.54978.jkeating@redhat.com> <20061110192157.GA19385@nostromo.devel.redhat.com> <200611101426.08331.jkeating@redhat.com> <20061110192726.GB19317@nostromo.devel.redhat.com> <1163202231.7535.57.camel@localhost.localdomain> Message-ID: <20061111140826.GA16744@lists.us.dell.com> On Fri, Nov 10, 2006 at 11:43:51PM +0000, David Lutterkort wrote: > On Fri, 2006-11-10 at 14:27 -0500, Bill Nottingham wrote: > > Jesse Keating (jkeating at redhat.com) said: > > > I think all the current python module packages don't BuildRequire python. Nor > > > requires either, since that's automatically done by rpm now (provided python > > > is in the buildroot) > > > > Not all of them, and I think it's wrong to think they shouldn't. At > > least the ones I've packaged BR python & python-devel. > > There are definitely some. I got bitten by that a while ago when trying > to rebuild an FE package in a RHEL mock root. And I don't see any danger > in formalizing that python is an exception; it's been treated that way > for a long time. Exactly why it belongs as a per-package BR, so we don't have to keep track of it in every distro-version's exception list. Everyone loves python, but how often is it necessary for the packages of Fedora Universe? Here's my count of packages that require python after the fact: $ (for f in $(find . -name \*.rpm); do if rpm -qp --requires $f | \ grep "^(python =|/usr/bin/python)" > /dev/null 2>&1; then echo $f; fi; done) | wc -l Core-6-x86_64: 74 / 2931 = 2.5% Extras-6-x86_64: 135 / 4949 = 3.25% Given that there are more .$arch.rpm packages than .src.rpm packages, this means there are fewer than 2.65% of Universe that requires python at runtime, so presumably about that many also *should* require it at build time. Not enough to require it in every buildroot. My $0.02. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From fedora at leemhuis.info Mon Nov 13 06:08:36 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 13 Nov 2006 07:08:36 +0100 Subject: [Fedora-packaging] Conflicts in Core and Extras packages Message-ID: <45580BE4.4080502@leemhuis.info> Hi all! For those of you that are not on fedora-advisory-board find attached a discussion with Michael Schwendt on that list that IMHO falls in the area of the Packaging Committee. Could you guys please handle that? tia! If the Committee thinks some parts of this discussion is the area of the FESCo please notify me or that the PC members that are part of FESCo bring it over to FESCo. Also please try to get Michael involved into this discussion -- he seems to be interested in this so he's probably one of the best people to find a solution for the issue. But I don't think there is anything to do for FESCo *before* there are general packaging rules in the guidelines that clarify when Conflicts are allowed/acceptable and when not (for both Core and Extras). Further: Extras is no second class citizen -- if Core packages are allowed to conflict with other parts of Core then Extras packages should IMHO be allowed to Conflict with packages of Core, too. Sure, that should be controlled and I think FESCo in the future should approve each Conflict before it hits the repo. And we should check the exiositing conflicts -- but we need some guidelines from the PC first when conflicts are acceptable and when not. CU thl -------------- next part -------------- An embedded message was scrubbed... From: Michael Schwendt Subject: Re: [fab] build service Date: Sat, 11 Nov 2006 16:48:17 +0100 Size: 4419 URL: -------------- next part -------------- An embedded message was scrubbed... From: seth vidal Subject: Re: [fab] build service Date: Sat, 11 Nov 2006 12:37:03 -0500 Size: 4592 URL: -------------- next part -------------- An embedded message was scrubbed... From: Michael Schwendt Subject: Fedora Alternatives (Re: [fab] build service) Date: Sat, 11 Nov 2006 19:59:42 +0100 Size: 5712 URL: -------------- next part -------------- An embedded message was scrubbed... From: seth vidal Subject: Re: Fedora Alternatives (Re: [fab] build service) Date: Sat, 11 Nov 2006 17:17:42 -0500 Size: 5197 URL: -------------- next part -------------- An embedded message was scrubbed... From: Thorsten Leemhuis Subject: Re: Fedora Alternatives (Re: [fab] build service) Date: Sun, 12 Nov 2006 17:52:57 +0100 Size: 7075 URL: -------------- next part -------------- An embedded message was scrubbed... From: Jason L Tibbitts III Subject: Re: Fedora Alternatives (Re: [fab] build service) Date: 12 Nov 2006 12:08:34 -0600 Size: 5066 URL: -------------- next part -------------- An embedded message was scrubbed... From: Thorsten Leemhuis Subject: Re: Fedora Alternatives (Re: [fab] build service) Date: Sun, 12 Nov 2006 19:45:05 +0100 Size: 5941 URL: -------------- next part -------------- An embedded message was scrubbed... From: "Mike McGrath" Subject: Re: Fedora Alternatives (Re: [fab] build service) Date: Sun, 12 Nov 2006 14:09:52 -0600 Size: 5591 URL: -------------- next part -------------- An embedded message was scrubbed... From: Michael Schwendt Subject: Re: Fedora Alternatives (Re: [fab] build service) Date: Sun, 12 Nov 2006 21:29:51 +0100 Size: 5100 URL: -------------- next part -------------- An embedded message was scrubbed... From: Thorsten Leemhuis Subject: Re: Fedora Alternatives (Re: [fab] build service) Date: Sun, 12 Nov 2006 22:09:33 +0100 Size: 6267 URL: -------------- next part -------------- An embedded message was scrubbed... From: Michael Schwendt Subject: Re: Fedora Alternatives (Re: [fab] build service) Date: Sun, 12 Nov 2006 22:46:50 +0100 Size: 5967 URL: From paskalis at di.uoa.gr Mon Nov 13 08:12:28 2006 From: paskalis at di.uoa.gr (Sarantis Paskalis) Date: Mon, 13 Nov 2006 10:12:28 +0200 Subject: [Fedora-packaging] Re: Fedora Alternatives (Re: [fab] build service) In-Reply-To: <20061112212951.a0ddff02.bugs.michael@gmx.net> References: <20061110193133.GA19544@nostromo.devel.redhat.com> <4555D4DC.7070706@leemhuis.info> <20061111164817.800fac49.bugs.michael@gmx.net> <1163266623.9312.14.camel@cutter> <20061111195942.f04ccaa0.bugs.michael@gmx.net> <1163283462.9312.30.camel@cutter> <45575169.4060906@leemhuis.info> <20061112212951.a0ddff02.bugs.michael@gmx.net> Message-ID: <20061113081228.GA18721@gallagher.di.uoa.gr> Hi, On Sun, Nov 12, 2006 at 09:29:51PM +0100, Michael Schwendt wrote: > [...] > > Example: > > devel/hunky-fonts/hunky-fonts.spec > > Conflicts: fontconfig < 2.3.93 > > There's no comment that explains this. Can we please require packagers > to explain such unusual things in the spec file? > > Either it's superfluous Conflicts information (overuse of an RPM feature) > or at some point in time the package really conflicted with Core's > fontconfig. In that case, ouch. The same conflict applies to all font packages. Its root is here http://www.redhat.com/archives/fedora-extras-list/2006-January/msg00918.html (A newer version of fontconfig did not create .font-cache-1 or .font-cache-2 in the home directories, so ghosting of those files was removed. The introduction of the Conflict came instead of Requires: th e newer fontconfig). The spec file change was copy-pasted from one font package to most (all?) others. I suspect the correct thing to do was to add a Requires: fontconfig >= 2.3.93 instead of the Conflicts:. Is that correct? Thanks, -- Sarantis From nicolas.mailhot at laposte.net Mon Nov 13 10:35:18 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 13 Nov 2006 11:35:18 +0100 (CET) Subject: [Fedora-packaging] Re: Fedora Alternatives (Re: [fab] build service) In-Reply-To: <20061113081228.GA18721@gallagher.di.uoa.gr> References: <20061110193133.GA19544@nostromo.devel.redhat.com> <4555D4DC.7070706@leemhuis.info> <20061111164817.800fac49.bugs.michael@gmx.net> <1163266623.9312.14.camel@cutter> <20061111195942.f04ccaa0.bugs.michael@gmx.net> <1163283462.9312.30.camel@cutter> <45575169.4060906@leemhuis.info> <20061112212951.a0ddff02.bugs.michael@gmx.net> <20061113081228.GA18721@gallagher.di.uoa.gr> Message-ID: <15055.192.54.193.51.1163414118.squirrel@rousalka.dyndns.org> Le Lun 13 novembre 2006 09:12, Sarantis Paskalis a ?crit : > Hi, > > On Sun, Nov 12, 2006 at 09:29:51PM +0100, Michael Schwendt wrote: >> [...] >> >> Example: >> >> devel/hunky-fonts/hunky-fonts.spec >> >> Conflicts: fontconfig < 2.3.93 >> >> There's no comment that explains this. Can we please require packagers >> to explain such unusual things in the spec file? >> >> Either it's superfluous Conflicts information (overuse of an RPM >> feature) >> or at some point in time the package really conflicted with Core's >> fontconfig. In that case, ouch. > > The same conflict applies to all font packages. Its root is here > http://www.redhat.com/archives/fedora-extras-list/2006-January/msg00918.html That's one reason but not the only one, font systems are fun. >The introduction of the Conflict came instead of Requires: th > e newer fontconfig). The spec file change was copy-pasted from one font > package to most (all?) others. Probably from my dejavu-fonts spec > I suspect the correct thing to do was to > add a Requires: fontconfig >= 2.3.93 instead of the Conflicts:. > > Is that correct? No. We don't want font packages to depend on fontconfig. However if fontconfig is installed it better be a version compatible with the fontconfig stuff the font package does (ghosting of cache files is one thing, another is the conf files we drop in /etc/fonts/conf.d - I have no idea how an older fontconfig would interpret the new syntax and frankly I don't want to test it). The conflict should be no problem as a font package should never conflict with the fontconfig version of the release it's pushed for. It's only a safety should a system update its fontconfig package without updating the font packages at the same time. Regards, -- Nicolas Mailhot From gajownik at gmail.com Mon Nov 13 17:26:58 2006 From: gajownik at gmail.com (Dawid Gajownik) Date: Mon, 13 Nov 2006 18:26:58 +0100 Subject: [Fedora-packaging] Re: Fedora Alternatives (Re: [fab] build service) In-Reply-To: <15055.192.54.193.51.1163414118.squirrel@rousalka.dyndns.org> References: <20061110193133.GA19544@nostromo.devel.redhat.com> <4555D4DC.7070706@leemhuis.info> <20061111164817.800fac49.bugs.michael@gmx.net> <1163266623.9312.14.camel@cutter> <20061111195942.f04ccaa0.bugs.michael@gmx.net> <1163283462.9312.30.camel@cutter> <45575169.4060906@leemhuis.info> <20061112212951.a0ddff02.bugs.michael@gmx.net> <20061113081228.GA18721@gallagher.di.uoa.gr> <15055.192.54.193.51.1163414118.squirrel@rousalka.dyndns.org> Message-ID: <4558AAE2.4070207@gmail.com> Dnia 11/13/2006 11:35 AM, U?ytkownik Nicolas Mailhot napisa?: >> The introduction of the Conflict came instead of Requires: th >> e newer fontconfig). The spec file change was copy-pasted from one font >> package to most (all?) others. > > Probably from my dejavu-fonts spec Yes, you're right. :) I've copied this line from your package spec file. Regards, Dawid -- ^_* From tibbs at math.uh.edu Tue Nov 14 06:15:54 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 14 Nov 2006 00:15:54 -0600 Subject: [Fedora-packaging] Initial LicenseTag proposal Message-ID: I've distilled the discussion at the IRC meetings and have written up an initial document for stimulating discussion about standardizing License: tags. It's at ttp://fedoraproject.org/wiki/PackagingDrafts/LicenseTag Please feel free to look over it and add your comments. - J< From Axel.Thimm at ATrpms.net Tue Nov 14 08:14:39 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 14 Nov 2006 09:14:39 +0100 Subject: [Fedora-packaging] Charter of Fedora Packaging Group (was: Conflicts in Core and Extras packages) In-Reply-To: <45580BE4.4080502@leemhuis.info> References: <45580BE4.4080502@leemhuis.info> Message-ID: <20061114081439.GD7677@neu.nirvana> On Mon, Nov 13, 2006 at 07:08:36AM +0100, Thorsten Leemhuis wrote: > For those of you that are not on fedora-advisory-board find attached a > discussion with Michael Schwendt on that list that IMHO falls in the > area of the Packaging Committee. Could you guys please handle that? tia! > But I don't think there is anything to do for FESCo *before* there are > general packaging rules in the guidelines that clarify when Conflicts > are allowed/acceptable and when not (for both Core and Extras). I think this is wrong (not the contents, but the responsibilities). There is no real charter or manifesto of this group and there are often topics brought up that are questionable on whether this group should be able to decide on it. But I think the implied work is on "how, not why/what" to package. E.g. methology vs policies. It is FC and fesco and any higher boards that setup policies and some of them are even holy grails like conflicts/replacements/overrides between FC and FE. We can't solve such a dispute, we can only implement the boards' decisions. In short: You're god, and we're the apostels writing down your will, but you must first make up your will within the divine trinity or any other god model ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bugs.michael at gmx.net Tue Nov 14 11:02:02 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 14 Nov 2006 12:02:02 +0100 Subject: [Fedora-packaging] Conflicts in Core and Extras packages In-Reply-To: <45580BE4.4080502@leemhuis.info> References: <45580BE4.4080502@leemhuis.info> Message-ID: <20061114120202.ad907665.bugs.michael@gmx.net> On Mon, 13 Nov 2006 07:08:36 +0100, Thorsten Leemhuis wrote: > For those of you that are not on fedora-advisory-board find attached a > discussion with Michael Schwendt on that list that IMHO falls in the > area of the Packaging Committee. Could you guys please handle that? tia! > > If the Committee thinks some parts of this discussion is the area of the > FESCo please notify me or that the PC members that are part of FESCo > bring it over to FESCo. Also please try to get Michael involved into > this discussion -- he seems to be interested in this so he's probably > one of the best people to find a solution for the issue. > But I don't think there is anything to do for FESCo *before* there are > general packaging rules in the guidelines that clarify when Conflicts > are allowed/acceptable and when not (for both Core and Extras). Further: > Extras is no second class citizen -- if Core packages are allowed to > conflict with other parts of Core then Extras packages should IMHO be > allowed to Conflict with packages of Core, too. Sure, that should be > controlled and I think FESCo in the future should approve each Conflict > before it hits the repo. If you had added these extra paragraphs to the original thread on f-a-b list, I would have commented it with: "Why can't FESCO simply decide whether they want Fedora Extras to be free of package conflicts or not?" Or rephrased: "Does FESCO want a full install of Fedora Extras and Core to be possible or not?" About the thing referring to me, I don't like discussions that don't move anything forward. So, let me add a few more comments to make my view clear, hopefully: At fedora.us we have had the bad habit of "abusing" clean-chroot-builds done with mach for the possibility to have conflicting -devel packages, e.g. for an old ABI and a new API of the same thing, never installed in the same buildroot at once. Occasionally, it had been referred to as "lazy packaging", to get something done (i.e. provide working and conflict-free binary rpms) instead of spending extra efforts on preparing conflict-free -devel packages just for an old API to possibly be obsolete an unknown number of weeks later. Only a very few (2-3?) such packages are still in Fedora Extras. Long ago, for Fedora Extras, I believe we've agreed that Fedora Extras shall be free of package conflicts. But this has never found its way onto any policy page. You know what it's like with obvious stuff that is considered common sense, it is hard to find somebody who spends time on documenting it somewhere. So, A) package contributors don't know about such a policy in case it still exists, B) Fedora Alternatives has been killed early, and C) there *are* explicit package conflicts in Extras, at least between Extras packages, and D) there are additional superfluous, dangerous, and questionable conflicts in packages (sometimes probably just old cruft, however). The important question is at the top of my reply, though. Beyond that, it can be decided whether packagers must add comments to every "Conflicts" tag (and not just Conflicts, but also Obsoletes), giving a proper justification. From fedora at leemhuis.info Tue Nov 14 11:35:26 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 14 Nov 2006 12:35:26 +0100 Subject: [Fedora-packaging] Conflicts in Core and Extras packages In-Reply-To: <20061114120202.ad907665.bugs.michael@gmx.net> References: <45580BE4.4080502@leemhuis.info> <20061114120202.ad907665.bugs.michael@gmx.net> Message-ID: <4559A9FE.4020308@leemhuis.info> Michael Schwendt schrieb: > On Mon, 13 Nov 2006 07:08:36 +0100, Thorsten Leemhuis wrote: >> For those of you that are not on fedora-advisory-board find attached a >> discussion with Michael Schwendt on that list that IMHO falls in the >> area of the Packaging Committee. Could you guys please handle that? tia! >> >> If the Committee thinks some parts of this discussion is the area of the >> FESCo please notify me or that the PC members that are part of FESCo >> bring it over to FESCo. Also please try to get Michael involved into >> this discussion -- he seems to be interested in this so he's probably >> one of the best people to find a solution for the issue. > >> But I don't think there is anything to do for FESCo *before* there are >> general packaging rules in the guidelines that clarify when Conflicts >> are allowed/acceptable and when not (for both Core and Extras). Further: >> Extras is no second class citizen -- if Core packages are allowed to >> conflict with other parts of Core then Extras packages should IMHO be >> allowed to Conflict with packages of Core, too. Sure, that should be >> controlled and I think FESCo in the future should approve each Conflict >> before it hits the repo. > If you had added these extra paragraphs to the original thread on f-a-b > list, I would have commented it with: > "Why can't FESCO simply decide whether they want Fedora Extras > to be free of package conflicts or not?" We *should* not "simply decide" without evaluating first if there are valid reasons for conflicts. All we have until now is this discussion -- we don't have rules or guidelines when conflicts are acceptable and when not. And I don't see any reasons why those rules or guidelines need to be different between Core and Extras, and thus it's IMHO business for the packaging committee. If Spot/the Committee clearly says "No, that's not our area of work" then I'll consider it a task for FESCo again. > Or rephrased: > "Does FESCO want a full install of Fedora Extras and Core to be > possible or not?" Well, Core has conflicts with other core packages afaik. So the above will never work afaics, with or without Extras. > [...] > > Beyond that, it can be decided whether packagers must add comments to > every "Conflicts" tag (and not just Conflicts, but also Obsoletes), > giving a proper justification. +1 CU thl From fedora at leemhuis.info Tue Nov 14 11:41:28 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 14 Nov 2006 12:41:28 +0100 Subject: [Fedora-packaging] Re: Charter of Fedora Packaging Group In-Reply-To: <20061114081439.GD7677@neu.nirvana> References: <45580BE4.4080502@leemhuis.info> <20061114081439.GD7677@neu.nirvana> Message-ID: <4559AB68.8020005@leemhuis.info> Axel Thimm schrieb: > On Mon, Nov 13, 2006 at 07:08:36AM +0100, Thorsten Leemhuis wrote: >> For those of you that are not on fedora-advisory-board find attached a >> discussion with Michael Schwendt on that list that IMHO falls in the >> area of the Packaging Committee. Could you guys please handle that? tia! > >> But I don't think there is anything to do for FESCo *before* there are >> general packaging rules in the guidelines that clarify when Conflicts >> are allowed/acceptable and when not (for both Core and Extras). > > I think this is wrong (not the contents, but the responsibilities). > > There is no real charter or manifesto of this group and there are > often topics brought up that are questionable on whether this group > should be able to decide on it. But I think the implied work is on > "how, not why/what" to package. E.g. methology vs policies. Sure, policies like "Extras does not replace packages from Core" or "Extras packages don't conflict with Core" are FESCo business. But is a Conflicts: kernel < 2.6.16 a conflict with Core or is that an acceptable way in Core and Extras to say "if you have a kernel it needs to be at least 2.6.16"? That's clearly packaging afaics. CU thl From bugs.michael at gmx.net Tue Nov 14 11:52:22 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 14 Nov 2006 12:52:22 +0100 Subject: [Fedora-packaging] Conflicts in Core and Extras packages In-Reply-To: <4559A9FE.4020308@leemhuis.info> References: <45580BE4.4080502@leemhuis.info> <20061114120202.ad907665.bugs.michael@gmx.net> <4559A9FE.4020308@leemhuis.info> Message-ID: <20061114125222.0e4c1a22.bugs.michael@gmx.net> On Tue, 14 Nov 2006 12:35:26 +0100, Thorsten Leemhuis wrote: > Michael Schwendt schrieb: > > On Mon, 13 Nov 2006 07:08:36 +0100, Thorsten Leemhuis wrote: > >> For those of you that are not on fedora-advisory-board find attached a > >> discussion with Michael Schwendt on that list that IMHO falls in the > >> area of the Packaging Committee. Could you guys please handle that? tia! > >> > >> If the Committee thinks some parts of this discussion is the area of the > >> FESCo please notify me or that the PC members that are part of FESCo > >> bring it over to FESCo. Also please try to get Michael involved into > >> this discussion -- he seems to be interested in this so he's probably > >> one of the best people to find a solution for the issue. > > > >> But I don't think there is anything to do for FESCo *before* there are > >> general packaging rules in the guidelines that clarify when Conflicts > >> are allowed/acceptable and when not (for both Core and Extras). Further: > >> Extras is no second class citizen -- if Core packages are allowed to > >> conflict with other parts of Core then Extras packages should IMHO be > >> allowed to Conflict with packages of Core, too. Sure, that should be > >> controlled and I think FESCo in the future should approve each Conflict > >> before it hits the repo. > > If you had added these extra paragraphs to the original thread on f-a-b > > list, I would have commented it with: > > "Why can't FESCO simply decide whether they want Fedora Extras > > to be free of package conflicts or not?" > > We *should* not "simply decide" without evaluating first if there are > valid reasons for conflicts. No, such "evaluation" is off-topic for this list. You're trying to complicate matters. Perhaps based on a misunderstanding of what types of conflicts are "in the wild". For a moment, just forget your corner-cases I've commented on before. > All we have until now is this discussion -- > we don't have rules or guidelines when conflicts are acceptable and when > not. > > And I don't see any reasons why those rules or guidelines need to be > different between Core and Extras, and thus it's IMHO business for the > packaging committee. If Spot/the Committee clearly says "No, that's not > our area of work" then I'll consider it a task for FESCo again. > > > Or rephrased: > > "Does FESCO want a full install of Fedora Extras and Core to be > > possible or not?" > > Well, Core has conflicts with other core packages afaik. So the above > will never work afaics, with or without Extras. Is that true? The stuff I'm interested in first is "Conflicts: foo" which actually prevent multiple packages to be installed at once. Such conflicts do exist in Fedora Extras and asks for steering. A simple decision without any need to argue about it. From fedora at leemhuis.info Tue Nov 14 12:06:23 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 14 Nov 2006 13:06:23 +0100 Subject: [Fedora-packaging] Conflicts in Core and Extras packages In-Reply-To: <20061114125222.0e4c1a22.bugs.michael@gmx.net> References: <45580BE4.4080502@leemhuis.info> <20061114120202.ad907665.bugs.michael@gmx.net> <4559A9FE.4020308@leemhuis.info> <20061114125222.0e4c1a22.bugs.michael@gmx.net> Message-ID: <4559B13F.1050900@leemhuis.info> Michael Schwendt schrieb: > On Tue, 14 Nov 2006 12:35:26 +0100, Thorsten Leemhuis wrote: >> Michael Schwendt schrieb: >>> Or rephrased: >>> "Does FESCO want a full install of Fedora Extras and Core to be >>> possible or not?" >> Well, Core has conflicts with other core packages afaik. So the above >> will never work afaics, with or without Extras. > Is that true? I did a quick recheck, could not find any, sorry, seems I was wrong on that. > The stuff I'm interested in first is "Conflicts: foo" which actually > prevent multiple packages to be installed at once. Such conflicts do exist > in Fedora Extras and asks for steering. I'm all for that rule -- but for *both Core and Extras* and thus from the packaging committee. E.g. something like this: "Packages should not explicitly conflict with other packages that are part of the same release of Fedora Core or Extras." And I'd like to see some guidelines from the packaging committee in what situations it's okay to use the Conflicts tag for other purposes (e.g. Conflicts: kernel < 2.6.16). CU thl From tibbs at math.uh.edu Tue Nov 14 14:59:25 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 14 Nov 2006 08:59:25 -0600 Subject: [Fedora-packaging] Conflicts in Core and Extras packages In-Reply-To: <4559B13F.1050900@leemhuis.info> References: <45580BE4.4080502@leemhuis.info> <20061114120202.ad907665.bugs.michael@gmx.net> <4559A9FE.4020308@leemhuis.info> <20061114125222.0e4c1a22.bugs.michael@gmx.net> <4559B13F.1050900@leemhuis.info> Message-ID: >>>>> "TL" == Thorsten Leemhuis writes: TL> "Packages should not explicitly conflict with other packages that TL> are part of the same release of Fedora Core or Extras." I still contend that such a statement needs to come from FESCo or the FAB (perhaps working together), not the packaging committee. It's purely a policy decision not relating to the form of packages. TL> And I'd like to see some guidelines from the packaging committee TL> in what situations it's okay to use the Conflicts tag for other TL> purposes (e.g. Conflicts: kernel < 2.6.16). That is reasonable. Perhaps we can brainstorm a bit at our meeting today and get a volunteer to write up a proposal. - J< From nicolas.mailhot at laposte.net Tue Nov 14 18:01:01 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 14 Nov 2006 19:01:01 +0100 Subject: [Fedora-packaging] Conflicts in Core and Extras packages In-Reply-To: <20061114125222.0e4c1a22.bugs.michael@gmx.net> References: <45580BE4.4080502@leemhuis.info> <20061114120202.ad907665.bugs.michael@gmx.net> <4559A9FE.4020308@leemhuis.info> <20061114125222.0e4c1a22.bugs.michael@gmx.net> Message-ID: <1163527267.9150.1.camel@rousalka.dyndns.org> Le mardi 14 novembre 2006 ? 12:52 +0100, Michael Schwendt a ?crit : > On Tue, 14 Nov 2006 12:35:26 +0100, Thorsten Leemhuis wrote: > > Well, Core has conflicts with other core packages afaik. So the above > > will never work afaics, with or without Extras. > > Is that true? The kernel package, for example, has a boatload of versionned conflicts to prevent installation on a system with the wrong userspace level. -- Nicolas Mailhot From bugs.michael at gmx.net Tue Nov 14 18:32:05 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 14 Nov 2006 19:32:05 +0100 Subject: [Fedora-packaging] Conflicts in Core and Extras packages In-Reply-To: <1163527267.9150.1.camel@rousalka.dyndns.org> References: <45580BE4.4080502@leemhuis.info> <20061114120202.ad907665.bugs.michael@gmx.net> <4559A9FE.4020308@leemhuis.info> <20061114125222.0e4c1a22.bugs.michael@gmx.net> <1163527267.9150.1.camel@rousalka.dyndns.org> Message-ID: <20061114193205.3ef88d6a.bugs.michael@gmx.net> On Tue, 14 Nov 2006 19:01:01 +0100, Nicolas Mailhot wrote: > Le mardi 14 novembre 2006 ? 12:52 +0100, Michael Schwendt a ?crit : > > On Tue, 14 Nov 2006 12:35:26 +0100, Thorsten Leemhuis wrote: > > > > Well, Core has conflicts with other core packages afaik. So the above > > > will never work afaics, with or without Extras. > > > > Is that true? > > The kernel package, for example, has a boatload of versionned conflicts > to prevent installation on a system with the wrong userspace level. Void. The right userspace tools are part of Core, so these conditional conflicts only become active under corner-case conditions and then create artificial hurdles. From paul at city-fan.org Tue Nov 14 18:40:45 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 14 Nov 2006 18:40:45 +0000 Subject: [Fedora-packaging] Conflicts in Core and Extras packages In-Reply-To: <20061114193205.3ef88d6a.bugs.michael@gmx.net> References: <45580BE4.4080502@leemhuis.info> <20061114120202.ad907665.bugs.michael@gmx.net> <4559A9FE.4020308@leemhuis.info> <20061114125222.0e4c1a22.bugs.michael@gmx.net> <1163527267.9150.1.camel@rousalka.dyndns.org> <20061114193205.3ef88d6a.bugs.michael@gmx.net> Message-ID: <455A0DAD.5020502@city-fan.org> Michael Schwendt wrote: > On Tue, 14 Nov 2006 19:01:01 +0100, Nicolas Mailhot wrote: > >> Le mardi 14 novembre 2006 ? 12:52 +0100, Michael Schwendt a ?crit : >>> On Tue, 14 Nov 2006 12:35:26 +0100, Thorsten Leemhuis wrote: >>>> Well, Core has conflicts with other core packages afaik. So the above >>>> will never work afaics, with or without Extras. >>> Is that true? >> The kernel package, for example, has a boatload of versionned conflicts >> to prevent installation on a system with the wrong userspace level. > > Void. > > The right userspace tools are part of Core, so these conditional conflicts > only become active under corner-case conditions and then create artificial > hurdles. There have been times in the past where I wanted to try a rawhide kernel on a current-release Fedora version to see if it fixed an issue I was having. The versioned requires/conflicts that the kernel has were very useful at that time, as it told me what else I needed to pull from rawhide to do the experiment. Paul. From rc040203 at freenet.de Tue Nov 14 18:41:43 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 14 Nov 2006 19:41:43 +0100 Subject: [Fedora-packaging] Conflicts in Core and Extras packages In-Reply-To: <20061114193205.3ef88d6a.bugs.michael@gmx.net> References: <45580BE4.4080502@leemhuis.info> <20061114120202.ad907665.bugs.michael@gmx.net> <4559A9FE.4020308@leemhuis.info> <20061114125222.0e4c1a22.bugs.michael@gmx.net> <1163527267.9150.1.camel@rousalka.dyndns.org> <20061114193205.3ef88d6a.bugs.michael@gmx.net> Message-ID: <1163529703.3891.71.camel@mccallum.corsepiu.local> On Tue, 2006-11-14 at 19:32 +0100, Michael Schwendt wrote: > On Tue, 14 Nov 2006 19:01:01 +0100, Nicolas Mailhot wrote: > > > Le mardi 14 novembre 2006 ? 12:52 +0100, Michael Schwendt a ?crit : > > > On Tue, 14 Nov 2006 12:35:26 +0100, Thorsten Leemhuis wrote: > > > > > > Well, Core has conflicts with other core packages afaik. So the above > > > > will never work afaics, with or without Extras. > > > > > > Is that true? > > > > The kernel package, for example, has a boatload of versionned conflicts > > to prevent installation on a system with the wrong userspace level. > > Void. > > The right userspace tools are part of Core, so these conditional conflicts > only become active under corner-case conditions and then create artificial > hurdles. == bug Frankly speaking, I am having difficulties to imagine valid reasons when an explicit "Conflicts:" in an rpm.spec makes any sense, and am inclined to think all such explicit "Conflicts:" actually are packaging bugs. Am I missing something? Ralf From tibbs at math.uh.edu Tue Nov 14 18:28:30 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 14 Nov 2006 12:28:30 -0600 Subject: [Fedora-packaging] Initial LicenseTag proposal In-Reply-To: References: Message-ID: My apologies for sending this proposal. I seem to have misunderstood the previous discussions on the issue, and hereby withdraw the draft. - J< From bugs.michael at gmx.net Tue Nov 14 19:14:04 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 14 Nov 2006 20:14:04 +0100 Subject: [Fedora-packaging] Conflicts in Core and Extras packages In-Reply-To: <455A0DAD.5020502@city-fan.org> References: <45580BE4.4080502@leemhuis.info> <20061114120202.ad907665.bugs.michael@gmx.net> <4559A9FE.4020308@leemhuis.info> <20061114125222.0e4c1a22.bugs.michael@gmx.net> <1163527267.9150.1.camel@rousalka.dyndns.org> <20061114193205.3ef88d6a.bugs.michael@gmx.net> <455A0DAD.5020502@city-fan.org> Message-ID: <20061114201404.86d8fa49.bugs.michael@gmx.net> On Tue, 14 Nov 2006 18:40:45 +0000, Paul Howarth wrote: > Michael Schwendt wrote: > > On Tue, 14 Nov 2006 19:01:01 +0100, Nicolas Mailhot wrote: > > > >> Le mardi 14 novembre 2006 ? 12:52 +0100, Michael Schwendt a ?crit : > >>> On Tue, 14 Nov 2006 12:35:26 +0100, Thorsten Leemhuis wrote: > >>>> Well, Core has conflicts with other core packages afaik. So the above > >>>> will never work afaics, with or without Extras. > >>> Is that true? > >> The kernel package, for example, has a boatload of versionned conflicts > >> to prevent installation on a system with the wrong userspace level. > > > > Void. > > > > The right userspace tools are part of Core, so these conditional conflicts > > only become active under corner-case conditions and then create artificial > > hurdles. > > There have been times in the past where I wanted to try a rawhide kernel > on a current-release Fedora version to see if it fixed an issue I was > having. The versioned requires/conflicts that the kernel has were very > useful at that time, as it told me what else I needed to pull from > rawhide to do the experiment. No. Read your own paragraph once more. You write "requires/conflicts" and mix _two_ things. The versioned "Requires" were "very useful", because they told you what you needed, and you then fetched sufficient upgrades. On the contrary, "Conflicts" don't tell you the way out. From nicolas.mailhot at laposte.net Tue Nov 14 19:20:46 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 14 Nov 2006 20:20:46 +0100 Subject: [Fedora-packaging] Conflicts in Core and Extras packages In-Reply-To: <20061114201404.86d8fa49.bugs.michael@gmx.net> References: <45580BE4.4080502@leemhuis.info> <20061114120202.ad907665.bugs.michael@gmx.net> <4559A9FE.4020308@leemhuis.info> <20061114125222.0e4c1a22.bugs.michael@gmx.net> <1163527267.9150.1.camel@rousalka.dyndns.org> <20061114193205.3ef88d6a.bugs.michael@gmx.net> <455A0DAD.5020502@city-fan.org> <20061114201404.86d8fa49.bugs.michael@gmx.net> Message-ID: <1163532047.9150.14.camel@rousalka.dyndns.org> Le mardi 14 novembre 2006 ? 20:14 +0100, Michael Schwendt a ?crit : > The versioned "Requires" were "very useful", because they told you what > you needed, and you then fetched sufficient upgrades. On the contrary, > "Conflicts" don't tell you the way out. Conflicts : - save your ass before you hose your system with an unsupported combination - don't force you to have half the distro as installed requires just to be sure there's no version conflict - tell you A won't work with B (version). So the obvious way out is : a. install a compatible b version b. remove B if you don't really need it -- Nicolas Mailhot From notting at redhat.com Tue Nov 14 19:29:01 2006 From: notting at redhat.com (Bill Nottingham) Date: Tue, 14 Nov 2006 14:29:01 -0500 Subject: [Fedora-packaging] Conflicts in Core and Extras packages In-Reply-To: <1163532047.9150.14.camel@rousalka.dyndns.org> References: <45580BE4.4080502@leemhuis.info> <20061114120202.ad907665.bugs.michael@gmx.net> <4559A9FE.4020308@leemhuis.info> <20061114125222.0e4c1a22.bugs.michael@gmx.net> <1163527267.9150.1.camel@rousalka.dyndns.org> <20061114193205.3ef88d6a.bugs.michael@gmx.net> <455A0DAD.5020502@city-fan.org> <20061114201404.86d8fa49.bugs.michael@gmx.net> <1163532047.9150.14.camel@rousalka.dyndns.org> Message-ID: <20061114192901.GB3043@nostromo.devel.redhat.com> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: > Conflicts : > - save your ass before you hose your system with an unsupported > combination > - don't force you to have half the distro as installed requires just to > be sure there's no version conflict > - tell you A won't work with B (version). So the obvious way out is : a. > install a compatible b version b. remove B if you don't really need it Exactly. The kernel doesn't *require* that you have oprofile installed, but it may not work with a sufficiently old oprofile. Bill From bugs.michael at gmx.net Tue Nov 14 21:23:48 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 14 Nov 2006 22:23:48 +0100 Subject: [Fedora-packaging] Conflicts in Core and Extras packages In-Reply-To: <20061114192901.GB3043@nostromo.devel.redhat.com> References: <45580BE4.4080502@leemhuis.info> <20061114120202.ad907665.bugs.michael@gmx.net> <4559A9FE.4020308@leemhuis.info> <20061114125222.0e4c1a22.bugs.michael@gmx.net> <1163527267.9150.1.camel@rousalka.dyndns.org> <20061114193205.3ef88d6a.bugs.michael@gmx.net> <455A0DAD.5020502@city-fan.org> <20061114201404.86d8fa49.bugs.michael@gmx.net> <1163532047.9150.14.camel@rousalka.dyndns.org> <20061114192901.GB3043@nostromo.devel.redhat.com> Message-ID: <20061114222348.2da57340.bugs.michael@gmx.net> On Tue, 14 Nov 2006 14:29:01 -0500, Bill Nottingham wrote: > Nicolas Mailhot said: > > Conflicts : > > - save your ass before you hose your system with an unsupported > > combination > > - don't force you to have half the distro as installed requires just to > > be sure there's no version conflict > > - tell you A won't work with B (version). So the obvious way out is : a. > > install a compatible b version b. remove B if you don't really need it > > Exactly. The kernel doesn't *require* that you have oprofile installed, > but it may not work with a sufficiently old oprofile. That's why a sufficiently new oprofile is provided together with the kernel in the same distribution. Only if you leave this package universe and want to use a kernel or oprofile from elsewhere, introducing such versioned conflicts may be justified. And hopefully they are well-maintained. But still, it only relocates a packaging problem from build-time to install-time. It would be much better, if compatibility were checked at build-time --> refuse to build when something in the distribution is insufficient. And if it's a fully optional package and smart, it would examine the system for compatibility at run-time. Anyway, just that it's not forgotten. There are non-versioned conflicts in Extras, and those are of primary interest. From chris.stone at gmail.com Mon Nov 20 05:34:30 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 19 Nov 2006 21:34:30 -0800 Subject: [Fedora-packaging] Fedora Packaging Member forking Fedora/Causing problems with community and users In-Reply-To: <1161199994.23519.12.camel@localhost.localdomain> References: <45366A73.1070801@math.unl.edu> <1161199994.23519.12.camel@localhost.localdomain> Message-ID: On 10/18/06, Tom 'spot' Callaway wrote: > On Wed, 2006-10-18 at 11:02 -0700, Christopher Stone wrote: > > On 10/18/06, Rex Dieter wrote: > > > Christopher Stone wrote: > > > > > > > I suggest that we have a comittee (possibly the packaging comittee) > > > > create a wiki page which reviews 3rd party repositories for such > > > > things as: > > > > > > IMO, this is outside the scope of the packaging committee's > > > mandate/rights/responsibility. > > > > > > I'd suggest you start a new SIG if you feel so strongly about this subject. > > > > I would be perfectly happy with this, even If its a one man SIG > > consisting of only me. As long as there is a wiki page on the Fedora > > wiki which has this information and users can be pointed to this page > > to learn about the consequences of installing another repository I > > would be happy. > > > > However, I think it would be better to have a comittee review other > > repositories instead of a single person who might be biased such as > > myself. > > I even think it would be more productive to highlight the FC or > FE packages that atrpms is providing overrides for, and start a > discussion around why these packages exist, and if there exists the > possibility to merge the changes into the FC or FE package and retire > the atrpms packages. I'm sure that Axel would welcome that discussion, > as less packages means less work for him. :) I have filed over one-hundred bugs a month ago, and while some Fedora users made an effort to try and reduce the conflicts, Axel has not made a single response to a single bug report. May I now proceed with my original idea of making an official wiki page on fedoraproject.org which warns people of the potential dangers from using ATrpms and other items discussed above? From fedora at leemhuis.info Mon Nov 20 06:10:42 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 20 Nov 2006 07:10:42 +0100 Subject: [Fedora-packaging] Fedora Packaging Member forking Fedora/Causing problems with community and users In-Reply-To: References: <45366A73.1070801@math.unl.edu> <1161199994.23519.12.camel@localhost.localdomain> Message-ID: <456146E2.20500@leemhuis.info> Christopher Stone schrieb: > [...] > May I now proceed with my original idea of making an official wiki > page on fedoraproject.org which warns people of the potential dangers > from using ATrpms and other items discussed above? No, don't mention ATrpms (or freshrpms, or livna) in the wiki. Not in good ways, but especially not in bad ways, as that would be a sign of bad politics. Axel is trying hard to contribute to Extras (at least until you scare him away with your campaign and then I'll be vary angry on you) and I'm quite confident that those problems you reported will get solved sooner or later, but it all takes time. Side note: I know that Axels time for Atrpms and Extras stuff is quite limited ATM, so please be even more patient. CU thl From rdieter at math.unl.edu Mon Nov 20 14:49:43 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 20 Nov 2006 08:49:43 -0600 Subject: [Fedora-packaging] Re: Fedora Packaging Member forking Fedora/Causing problems with community and users References: <45366A73.1070801@math.unl.edu> <1161199994.23519.12.camel@localhost.localdomain> Message-ID: Christopher Stone wrote: > On 10/18/06, Tom 'spot' Callaway wrote: >> I even think it would be more productive to highlight the FC or >> FE packages that atrpms is providing overrides for, and start a >> discussion around why these packages exist, and if there exists the >> possibility to merge the changes into the FC or FE package and retire >> the atrpms packages. I'm sure that Axel would welcome that discussion, >> as less packages means less work for him. :) > > I have filed over one-hundred bugs a month ago, and while some Fedora > users made an effort to try and reduce the conflicts, Axel has not > made a single response to a single bug report. spot's suggestion was to start a (constructive) dialog regarding this issue. IMO, mass-filing formletter-type bugs is certainly no way to go about that, and I'm not a bit surprised by Axel's (non)response. -- Rex From chris.stone at gmail.com Mon Nov 20 17:59:48 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 20 Nov 2006 09:59:48 -0800 Subject: [Fedora-packaging] Re: Fedora Packaging Member forking Fedora/Causing problems with community and users In-Reply-To: References: <45366A73.1070801@math.unl.edu> <1161199994.23519.12.camel@localhost.localdomain> Message-ID: On 11/20/06, Rex Dieter wrote: > Christopher Stone wrote: > > > On 10/18/06, Tom 'spot' Callaway wrote: > > >> I even think it would be more productive to highlight the FC or > >> FE packages that atrpms is providing overrides for, and start a > >> discussion around why these packages exist, and if there exists the > >> possibility to merge the changes into the FC or FE package and retire > >> the atrpms packages. I'm sure that Axel would welcome that discussion, > >> as less packages means less work for him. :) > > > > I have filed over one-hundred bugs a month ago, and while some Fedora > > users made an effort to try and reduce the conflicts, Axel has not > > made a single response to a single bug report. > > spot's suggestion was to start a (constructive) dialog regarding this issue. > IMO, mass-filing formletter-type bugs is certainly no way to go about that, > and I'm not a bit surprised by Axel's (non)response. Using bugzilla for discussion is not the way to go? Wow. This is mind boggling. Just how do you expect me to start a discussion? Is there a ATrpms mailing list or something? Even if there was a mailing list, why would bugzilla be less appropriate? I am totally dumbfounded... From bpepple at fedoraproject.org Mon Nov 20 18:42:02 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 20 Nov 2006 13:42:02 -0500 Subject: [Fedora-packaging] Re: Fedora Packaging Member forking Fedora/Causing problems with community and users In-Reply-To: References: <45366A73.1070801@math.unl.edu> <1161199994.23519.12.camel@localhost.localdomain> Message-ID: <1164048122.13183.7.camel@Chuck> On Mon, 2006-11-20 at 09:59 -0800, Christopher Stone wrote: > On 11/20/06, Rex Dieter wrote: > > > > spot's suggestion was to start a (constructive) dialog regarding this issue. > > IMO, mass-filing formletter-type bugs is certainly no way to go about that, > > and I'm not a bit surprised by Axel's (non)response. > > Using bugzilla for discussion is not the way to go? > > Wow. This is mind boggling. Just how do you expect me to start a > discussion? Is there a ATrpms mailing list or something? Even if > there was a mailing list, why would bugzilla be less appropriate? I > am totally dumbfounded... Umm, how about filing a couple of bugs initially, instead of carpet-bombing him? It came off as very antagonist filing all those bugs, especially given how you started this whole discussion. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rdieter at math.unl.edu Tue Nov 21 15:33:21 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 21 Nov 2006 09:33:21 -0600 Subject: [Fedora-packaging] Re: Package forking In-Reply-To: References: <45366A73.1070801@math.unl.edu> <1161199994.23519.12.camel@localhost.localdomain> Message-ID: <45631C41.1060704@math.unl.edu> Christopher Stone wrote: > Using bugzilla for discussion is not the way to go? bugzilla is for *bugs*, not discussion (imo anyway). > Wow. This is mind boggling. Just how do you expect me to start a > discussion? Is there a ATrpms mailing list or something? Yes there is, several: http://lists.atrpms.net/mailman/listinfo/atrpms-users http://lists.atrpms.net/mailman/listinfo/atrpms-devel the latter may be the best place to start. -- Rex From chris.stone at gmail.com Tue Nov 21 15:20:39 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Tue, 21 Nov 2006 07:20:39 -0800 Subject: [Fedora-packaging] Re: Package forking In-Reply-To: <45631C41.1060704@math.unl.edu> References: <45366A73.1070801@math.unl.edu> <1161199994.23519.12.camel@localhost.localdomain> <45631C41.1060704@math.unl.edu> Message-ID: On 11/21/06, Rex Dieter wrote: > Christopher Stone wrote: > > > Using bugzilla for discussion is not the way to go? > > bugzilla is for *bugs*, not discussion (imo anyway). > > > Wow. This is mind boggling. Just how do you expect me to start a > > discussion? Is there a ATrpms mailing list or something? > > Yes there is, several: > http://lists.atrpms.net/mailman/listinfo/atrpms-users > http://lists.atrpms.net/mailman/listinfo/atrpms-devel > the latter may be the best place to start. I still don't see how this would be a better place than bugzilla. If you want to discuss why someone is forking a package, you have to do it on a per-package basis. Having a single thread on a mailing list discussing 100+ different packages is impractical and indeed starting 100 different threads on a mailing list is also impractical. From rdieter at math.unl.edu Tue Nov 21 15:42:39 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 21 Nov 2006 09:42:39 -0600 Subject: [Fedora-packaging] Re: Package forking In-Reply-To: References: <45366A73.1070801@math.unl.edu> <1161199994.23519.12.camel@localhost.localdomain> <45631C41.1060704@math.unl.edu> Message-ID: <45631E6F.9080609@math.unl.edu> Christopher Stone wrote: > On 11/21/06, Rex Dieter wrote: >> Christopher Stone wrote: >> >> > Using bugzilla for discussion is not the way to go? >> >> bugzilla is for *bugs*, not discussion (imo anyway). >> >> > Wow. This is mind boggling. Just how do you expect me to start a >> > discussion? Is there a ATrpms mailing list or something? >> >> Yes there is, several: >> http://lists.atrpms.net/mailman/listinfo/atrpms-users >> http://lists.atrpms.net/mailman/listinfo/atrpms-devel >> the latter may be the best place to start. > > I still don't see how this would be a better place than bugzilla. If > you want to discuss why someone is forking a package, you have to do > it on a per-package basis. Having a single thread on a mailing list > discussing 100+ different packages is impractical and indeed starting > 100 different threads on a mailing list is also impractical. It's clear (to me anyway) your current approach has no realistic chance of getting results. You have to start somewhere. I'd suggest initiating (constructive!) dialog one package at a time (or by similar pkgs in groups whatever). -- Rex From rdieter at math.unl.edu Tue Nov 21 17:44:57 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 21 Nov 2006 11:44:57 -0600 Subject: [Fedora-packaging] Rex will be awol today Message-ID: <45633B19.30004@math.unl.edu> Sorry for the late notice, but I'll miss (what's remaining of anyway) the packaging comittee meeting today, I'm @ home with an ill child. -- Rex From orion at cora.nwra.com Wed Nov 22 21:50:05 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 22 Nov 2006 14:50:05 -0700 Subject: [Fedora-packaging] How to make a Provides based on package contents? Message-ID: <4564C60D.40204@cora.nwra.com> octave defines an API version in: octave-2.9.9/src/version.h: #define OCTAVE_API_VERSION "api-v22" Modules compiled against one version will not load in another. I'd like to get this put into the rpms like: Provides: octave(api) = api-v22 This can be done automatically on the module side with something like: Requires: octave(api) = %(octave-config -p API_VERSION) But, how to extract this automatically from src/version.h in the octave package itself? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From ville.skytta at iki.fi Fri Nov 24 18:00:59 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 24 Nov 2006 20:00:59 +0200 Subject: [Fedora-packaging] How to make a Provides based on package contents? In-Reply-To: <4564C60D.40204@cora.nwra.com> References: <4564C60D.40204@cora.nwra.com> Message-ID: <1164391259.3568.12.camel@viper.local> On Wed, 2006-11-22 at 14:50 -0700, Orion Poplawski wrote: > octave defines an API version in: > > octave-2.9.9/src/version.h: > #define OCTAVE_API_VERSION "api-v22" > > Modules compiled against one version will not load in another. I'd like > to get this put into the rpms like: > > Provides: octave(api) = api-v22 > > This can be done automatically on the module side with something like: > > Requires: octave(api) = %(octave-config -p API_VERSION) > > But, how to extract this automatically from src/version.h in the octave > package itself? One KISS way to handle this is to just hardcode the API version in a macro in the octave specfile, bump it between package versions as appropriate, and add a test in %check which will cause the octave package build to fail if you forgot to bring the hardcoded value up to date with the sources when updating the package. For a concrete example, see %{apiver} in the FE vdr package. From Axel.Thimm at ATrpms.net Sat Nov 25 22:37:40 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 25 Nov 2006 23:37:40 +0100 Subject: [Fedora-packaging] Re: --vendor fedora, rationale/motivation? In-Reply-To: References: Message-ID: <20061125223740.GD1614@neu.nirvana> Hi, this discussion resulted in some recommendations in the guidelines and elsewhere, but old packages are supposed to keep any naming (vendor) they used for backwards compatibility with menu editors, correct? I just removed the fedora- prefix from the smart package and Ville (correctly) raised the guidelines violation flag. While I just did the change w/o reading/understanding the compatibility note, afterwards I came up with similar reasoning as to why all packages should get fixed as Rex below. My main arguments in favour of properly fixing it are: o EPEL support: I don't want to fork a package specfiles just for supporting a legacy buglet, nor do I want to overcomplicate it with checing for fedora vs rhel. o buglet propagation: Most if not all packagers reuse their work. When I need a desktop/info install or something similar I cut and paste from one of my older packages, or perhaps from another good package. If such legacy buglets are kept then they get copied all along. Of course commenting would help. All in all the pain with doing such a change is that some customized user menues may suddenly lose en entry, which the user can easily dnd back. Therefore I don't think it is worth while to keep the pain in the specfiles, instead upon updating of such a specfile it should be cleaned up desktop-file-wise. What do you think? On Fri, Mar 03, 2006 at 09:47:47AM -0600, Rex Dieter wrote: > Per > http://fedoraproject.org/wiki/Extras/FedoraDesktopEntryGuidelines: > The vendor prefix (desktop-file-install --vendor=...) must be set to > fedora". > > I don't understand the rationale/motivation behind requiring '--vendor > fedora' > > I can, however, see that desktop-file-install's current > implementation(*) of prepending %{vendor}- to the .desktop file name has > some problems/issues: > 1. .desktop filename now varies from upstream > 2. --vendor may change when/if Extras bits are pulled into Core and/or > RHEL. > 3. *In particular*: when users start employing menu editors, since > most(all?) of them base their customizations on the .desktop file name. > > -- Rex > > (*) If desktop-file-install's implementation instead followed something > like kde's practice of using a vendor directory (e.g. > /usr/share/applications/kde), then (1) and (3) would no longer be an issue. > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Nov 25 22:51:26 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 25 Nov 2006 23:51:26 +0100 Subject: [Fedora-packaging] fedora-packaging meetings In-Reply-To: <1162927651.27894.3.camel@dhcp-32-109.ord.redhat.com> References: <20061107143331.GI31227@neu.nirvana> <1162927651.27894.3.camel@dhcp-32-109.ord.redhat.com> Message-ID: <20061125225126.GE1614@neu.nirvana> On Tue, Nov 07, 2006 at 01:27:31PM -0600, Tom 'spot' Callaway wrote: > On Tue, 2006-11-07 at 15:33 +0100, Axel Thimm wrote: > > I'll probably not be able to attend today's meeting again, I'm > > currently at job acquisition mode and that eats up my afternoon > > timeslots. > > > > This will most likely continue until the end of the year. Should I > > set back to make space for s/o else? > > Entirely up to you. If you feel like you won't be able to give it the > time necessary, please let me know and we'll start the process to find > someone to take your place. I'm moving this to the list, I already lost two meetings w/o prior notice (I didn't know that I wouldn't be able to attend until shortly before w/o net access), and I don't know whether I'll be able to make the next ones (I know I won't be able to make the very next one), and I can't give a estimate of when free time will come by again. :/ I don't want to stall any work here as has happened in the past with another member with little time to attend meetings/votes etc. I'd either have to step back or my vote should get frozen for now (e.g. the quorum recalculated with 1 vote less). I haven't managed to push any of the improvements I proposed anyway, so it's not going to be a big loss content-wise. I've asked thl, but he's not up to yet another task, I could think of Matthias Saou and/or Dominik (ratthan) as good candidates for this committee. Thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pertusus at free.fr Mon Nov 27 09:11:46 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 27 Nov 2006 10:11:46 +0100 Subject: [Fedora-packaging] static linking draft Message-ID: <20061127091146.GA2803@free.fr> Hello, I think that the http://fedoraproject.org/wiki/PackagingDrafts/StaticLinkage could be ameliorated, and also I am opposed to one point. * I think that in the motivation a link to Ulrich page could be a good thing, since there are other valid arguments listed there: http://people.redhat.com/drepper/no_static_linking.html * As showed by the thread https://www.redhat.com/archives/fedora-devel-list/2006-November/msg00713.html there is a valid use of static libraries, namely in trusted environements statically linking executables enhance their portability (although, sadly since FC-5 this portability is limited to kernel 2.6.9). Doing the same with dynamically linking is also possible (by providing the libs and using ld hacks), but much less unconvenient. I think that this should be explained in the draft. * I think that asking for FESCO permission to ship a static lib is wrong, for 3 reasons. One is that packagers may know better than FESCO members if the package is in his area of expertise. Second because I think it is not the FESCO role to participate in reviews. For me FESCO is about general issues, or last resort arbitrage in case of dispute, and there is enough work for FESCO already with those issues. If FESCO is meant to be involved in reviews, it should grow in size over time. And the third reason is that it unnecessarily slow down things and add work to reviewers/submitters. -- Pat From rc040203 at freenet.de Mon Nov 27 09:38:50 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 27 Nov 2006 10:38:50 +0100 Subject: [Fedora-packaging] static linking draft In-Reply-To: <20061127091146.GA2803@free.fr> References: <20061127091146.GA2803@free.fr> Message-ID: <1164620331.29498.67.camel@mccallum.corsepiu.local> On Mon, 2006-11-27 at 10:11 +0100, Patrice Dumas wrote: > Hello, > > I think that the > http://fedoraproject.org/wiki/PackagingDrafts/StaticLinkage > could be ameliorated, Well, FPC's vote on this proposal had been unanimous. Nevertheless, I am open to listen to further proposals. > and also I am opposed to one point. > * I think that in the motivation a link to Ulrich page could be > a good thing, since there are other valid arguments listed there: > http://people.redhat.com/drepper/no_static_linking.html Ulrich is approaching this issue from a completely different angle. We were addressing this issue from a "distro's point of view" having maintainability of the distro itself in mind. > * As showed by the thread > https://www.redhat.com/archives/fedora-devel-list/2006-November/msg00713.html > there is a valid use of static libraries, namely in trusted environements > statically linking executables enhance their portability (although, sadly > since FC-5 this portability is limited to kernel 2.6.9). As many others already pointed out, this claim simply is not true. IMO, the fact static linkage appears to work for you ("scientific apps"), probably only stems from the simplicity of such applications, because such kind of applications typically don't use much of the OS's resources. If they were, you'd probably notice the brokenness of this approach. > * I think that asking for FESCO permission to ship a static lib is wrong, > for 3 reasons. One is that packagers may know better than FESCO members if > the package is in his area of expertise. Second because I think it is not > the FESCO role to participate in reviews. For me FESCO is about general > issues, or last resort arbitrage in case of dispute, and there is enough > work for FESCO already with those issues. If FESCO is meant to be involved > in reviews, it should grow in size over time. And the third reason is that > it unnecessarily slow down things and add work to reviewers/submitters. Our motivation for getting FESCO involved is us wanting to collect a list of precedences of cases "when to allow "*-static*" packages". Technically, there never should be any necessity to allow any static libraries - I.e. "when to allow exceptions" essentially is a _political_ decision - That's why we want to get "political organs" involved. Ralf From pertusus at free.fr Mon Nov 27 10:27:56 2006 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 27 Nov 2006 11:27:56 +0100 Subject: [Fedora-packaging] static linking draft In-Reply-To: <1164620331.29498.67.camel@mccallum.corsepiu.local> References: <20061127091146.GA2803@free.fr> <1164620331.29498.67.camel@mccallum.corsepiu.local> Message-ID: <20061127102756.GA2975@free.fr> On Mon, Nov 27, 2006 at 10:38:50AM +0100, Ralf Corsepius wrote: > > We were addressing this issue from a "distro's point of view" having > maintainability of the distro itself in mind. Indeed, but the fact that some nss and iconv things won't work with statically linked apps seems of relevance to me here. > > > * As showed by the thread > > https://www.redhat.com/archives/fedora-devel-list/2006-November/msg00713.html > > there is a valid use of static libraries, namely in trusted environements > > statically linking executables enhance their portability (although, sadly > > since FC-5 this portability is limited to kernel 2.6.9). > As many others already pointed out, this claim simply is not true. As many others have already pointed out, this claim is true. To be more precise, this claim may be true or not depending on the precise case, there is no general case (if I understand well, there are some things that prevent for sure static linking, that should of course be taken into account). > IMO, the fact static linkage appears to work for you ("scientific > apps"), probably only stems from the simplicity of such applications, > because such kind of applications typically don't use much of the OS's > resources. If they were, you'd probably notice the brokenness of this > approach. Of course, I have never said something different, and that's why I think that static libraries shouldn't be packaged for all the packages. I think it doesn't makes much sense for kde, gnome apps, for example. But for data processing and numerical computations, linking statically enhance portability a lot, and allow to run binaries on computer the user doesn't administer. > Our motivation for getting FESCO involved is us wanting to collect a > list of precedences of cases "when to allow "*-static*" packages". Ok, that makes sense (more generally, documenting difficult packaging issues would be interesting), but then it shouldn't be to ask permission, only to register the packagers decisions. > Technically, there never should be any necessity to allow any static > libraries - I.e. "when to allow exceptions" essentially is a _political_ > decision - That's why we want to get "political organs" involved. I disagree, it is a technical decision, not a political one. -- Pat From dominik at greysector.net Mon Nov 27 11:22:35 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 27 Nov 2006 12:22:35 +0100 Subject: [Fedora-packaging] fedora-packaging meetings In-Reply-To: <20061125225126.GE1614@neu.nirvana> References: <20061107143331.GI31227@neu.nirvana> <1162927651.27894.3.camel@dhcp-32-109.ord.redhat.com> <20061125225126.GE1614@neu.nirvana> Message-ID: <20061127112235.GC4522@rathann.pekin.waw.pl> On Saturday, 25 November 2006 at 23:51, Axel Thimm wrote: > On Tue, Nov 07, 2006 at 01:27:31PM -0600, Tom 'spot' Callaway wrote: > > On Tue, 2006-11-07 at 15:33 +0100, Axel Thimm wrote: > > > I'll probably not be able to attend today's meeting again, I'm > > > currently at job acquisition mode and that eats up my afternoon > > > timeslots. > > > > > > This will most likely continue until the end of the year. Should I > > > set back to make space for s/o else? > > > > Entirely up to you. If you feel like you won't be able to give it the > > time necessary, please let me know and we'll start the process to find > > someone to take your place. > > I'm moving this to the list, I already lost two meetings w/o prior > notice (I didn't know that I wouldn't be able to attend until shortly > before w/o net access), and I don't know whether I'll be able to make > the next ones (I know I won't be able to make the very next one), and > I can't give a estimate of when free time will come by again. :/ That is unfortunate, but I do understand you all too well. Please don't overwork yourself. ;) > I don't want to stall any work here as has happened in the past with > another member with little time to attend meetings/votes etc. I'd > either have to step back or my vote should get frozen for now (e.g. > the quorum recalculated with 1 vote less). I haven't managed to push > any of the improvements I proposed anyway, so it's not going to be a > big loss content-wise. > > I've asked thl, but he's not up to yet another task, I could think of > Matthias Saou and/or Dominik (ratthan) as good candidates for this > committee. Thanks for the recommendation. I will do my best, should I get selected. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From rc040203 at freenet.de Mon Nov 27 15:59:57 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 27 Nov 2006 16:59:57 +0100 Subject: [Fedora-packaging] fedora-packaging meetings In-Reply-To: <20061127112235.GC4522@rathann.pekin.waw.pl> References: <20061107143331.GI31227@neu.nirvana> <1162927651.27894.3.camel@dhcp-32-109.ord.redhat.com> <20061125225126.GE1614@neu.nirvana> <20061127112235.GC4522@rathann.pekin.waw.pl> Message-ID: <1164643197.6317.79.camel@mccallum.corsepiu.local> Hi Dominik, Please don't read too much into what I'm going to write below ... On Mon, 2006-11-27 at 12:22 +0100, Dominik 'Rathann' Mierzejewski wrote: > On Saturday, 25 November 2006 at 23:51, Axel Thimm wrote: > > I don't want to stall any work here as has happened in the past with > > another member with little time to attend meetings/votes etc. I'd > > either have to step back or my vote should get frozen for now (e.g. > > the quorum recalculated with 1 vote less). I haven't managed to push > > any of the improvements I proposed anyway, so it's not going to be a > > big loss content-wise. > > > > I've asked thl, but he's not up to yet another task, I could think of > > Matthias Saou and/or Dominik (ratthan) as good candidates for this > > committee. > > Thanks for the recommendation. I will do my best, should I get selected. Could you provide some references and details about you, to provide people with "ammunition" to vote for rsp. against you? So far, I've not noticed you extensively participating in Fedora, nor do I know you personally nor have I met you in any project I've been working with/on. Therefore, I would have to vote "0" (should FPC vote) because I don't have an opinion on you ;) Regards, Ralf From dominik at greysector.net Mon Nov 27 21:03:53 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 27 Nov 2006 22:03:53 +0100 Subject: [Fedora-packaging] fedora-packaging meetings In-Reply-To: <1164643197.6317.79.camel@mccallum.corsepiu.local> References: <20061107143331.GI31227@neu.nirvana> <1162927651.27894.3.camel@dhcp-32-109.ord.redhat.com> <20061125225126.GE1614@neu.nirvana> <20061127112235.GC4522@rathann.pekin.waw.pl> <1164643197.6317.79.camel@mccallum.corsepiu.local> Message-ID: <20061127210353.GB10795@rathann.pekin.waw.pl> On Monday, 27 November 2006 at 16:59, Ralf Corsepius wrote: > Hi Dominik, > > Please don't read too much into what I'm going to write below ... > > On Mon, 2006-11-27 at 12:22 +0100, Dominik 'Rathann' Mierzejewski wrote: > > On Saturday, 25 November 2006 at 23:51, Axel Thimm wrote: [...] > > > I've asked thl, but he's not up to yet another task, I could think of > > > Matthias Saou and/or Dominik (ratthan) as good candidates for this > > > committee. > > > > Thanks for the recommendation. I will do my best, should I get selected. > > Could you provide some references and details about you, to provide > people with "ammunition" to vote for rsp. against you? > > So far, I've not noticed you extensively participating in Fedora, nor do > I know you personally nor have I met you in any project I've been > working with/on. > > Therefore, I would have to vote "0" (should FPC vote) because I don't > have an opinion on you ;) Right. Let's see... Currently I'm in the top 30 of Fedora Extras package maintainers (and working my way up :>), see owners.list and my wikipage at fedoraproject.org for details. I actively participate in discussions on various Fedora lists and IRC (I've founded the #fedora-pl channel). I usually attend both FPC and FESCo meetings to listen in on current issues. A couple of years ago I started my own repository and started to move the packages into Fedora and Livna when it became too much of a burden to maintain (which happened about a year ago). I've been packaging software since at least 2001 (that's how far some of my changelogs in specfiles go anyway - see http://rpm.greysector.net/). Apart from Fedora, I'm currently involved in MPlayer development and docs translation. I also did some work for AuroraLinux (ask my sponsor spot :>). If you have any questions, feel free to ask, though I'm sure those who are curious enough will find lots of information about me on the Internet (mostly on anti-spam and Linux-related newsgroups). Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From orion at cora.nwra.com Mon Nov 27 23:09:21 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 27 Nov 2006 16:09:21 -0700 Subject: [Fedora-packaging] How to make a Provides based on package contents? In-Reply-To: <1164391259.3568.12.camel@viper.local> References: <4564C60D.40204@cora.nwra.com> <1164391259.3568.12.camel@viper.local> Message-ID: <456B7021.6050602@cora.nwra.com> Ville Skytt? wrote: > > One KISS way to handle this is to just hardcode the API version in a > macro in the octave specfile, bump it between package versions as > appropriate, and add a test in %check which will cause the octave > package build to fail if you forgot to bring the hardcoded value up to > date with the sources when updating the package. How does this sound: octave.spec: @@ -1,3 +1,6 @@ +# From src/version.h:#define OCTAVE_API_VERSION +%define octave_api api-v22 + Name: octave Version: 2.9.9 Release: 1%{?dist} @@ -18,6 +21,7 @@ BuildRequires: readline-devel glibc-devel fftw-devel gperf ghostscript BuildRequires: ufsparse-devel glpk-devel gnuplot desktop-file-utils BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) +Provides: octave(%{octave_api}) %description @@ -49,6 +53,12 @@ %prep %setup -q +# Check that octave_api is set correctly +if ! grep -q '^#define OCTAVE_API_VERSION "%{octave_api}"' src/version.h +then + echo "octave_api variable in spec does not match src/version.h" + exit 1 +fi %build Then in an octave module: %{!?octave_api: %define octave_api %(octave-config -p API_VERSION)} Requires: octave(%{octave_api}) I went with octave(%{octave_api}) rather than octave(api) = %{octave_api} because I was getting errors when starting to build a package in mock that octave(api) was not being set to anything (during the buildroot setup phase - octave-config is unavailable there). If someone can point me around that, that would be great. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From tibbs at math.uh.edu Mon Nov 27 23:26:27 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 Nov 2006 17:26:27 -0600 Subject: [Fedora-packaging] How to make a Provides based on package contents? In-Reply-To: <456B7021.6050602@cora.nwra.com> References: <4564C60D.40204@cora.nwra.com> <1164391259.3568.12.camel@viper.local> <456B7021.6050602@cora.nwra.com> Message-ID: >>>>> "OP" == Orion Poplawski writes: OP> I went with octave(%{octave_api}) rather than octave(api) = OP> {octave_api} because I was getting errors when starting to build a OP> package in mock that octave(api) was not being set to anything OP> (during the buildroot setup phase - octave-config is unavailable OP> there). If someone can point me around that, that would be great. You just have to make sure it's defined to something like 0 so that the specfile is syntactically correct. Usually this is done with something like: %{!?octave_api: %define octave_api %(octave-config -p API_VERSION || 0)} assuming that even parses. - J< From tibbs at math.uh.edu Mon Nov 27 23:31:03 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 Nov 2006 17:31:03 -0600 Subject: [Fedora-packaging] How to make a Provides based on package contents? In-Reply-To: References: <4564C60D.40204@cora.nwra.com> <1164391259.3568.12.camel@viper.local> <456B7021.6050602@cora.nwra.com> Message-ID: >>>>> "JLT" == Jason L Tibbitts writes: JLT> assuming that even parses. Which it obviously doesn't; should be "|| echo 0" at the end there. - J< From tibbs at math.uh.edu Tue Nov 28 07:11:11 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Nov 2006 01:11:11 -0600 Subject: [Fedora-packaging] Revived License: tag proposal Message-ID: I have revived the License: tag proposal, simplified to a basic standardization of the tags used for some common licenses. I have not attempted to pick a list of those common licenses, although I have provided some data on what License: tags are in use. http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag Again, I wish to remind folks that this is just a proposal. - J< From dominik at greysector.net Tue Nov 28 14:18:27 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 28 Nov 2006 15:18:27 +0100 Subject: [Fedora-packaging] Revived License: tag proposal In-Reply-To: References: Message-ID: <20061128141827.GC19109@rathann.pekin.waw.pl> On Tuesday, 28 November 2006 at 08:11, Jason L Tibbitts III wrote: > I have revived the License: tag proposal, simplified to a basic > standardization of the tags used for some common licenses. I have not > attempted to pick a list of those common licenses, although I have > provided some data on what License: tags are in use. > > http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > > Again, I wish to remind folks that this is just a proposal. Old BSD... how about naming it "Original BSD", per http://www.fsf.org/licensing/licenses/index_html#OriginalBSD Also, why not PHPL instead of PHP License? Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From Axel.Thimm at ATrpms.net Tue Nov 28 14:28:32 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 28 Nov 2006 15:28:32 +0100 Subject: [Fedora-packaging] Re: Revived License: tag proposal In-Reply-To: References: Message-ID: <20061128142832.GD9632@neu.nirvana> Hi, On Tue, Nov 28, 2006 at 01:11:11AM -0600, Jason L Tibbitts III wrote: > I have revived the License: tag proposal, simplified to a basic > standardization of the tags used for some common licenses. I have not > attempted to pick a list of those common licenses, although I have > provided some data on what License: tags are in use. > > http://fedoraproject.org/wiki/PackagingDrafts/LicenseTag > > Again, I wish to remind folks that this is just a proposal. there was some talk some time ago about what "distributable" is supposed to mean, and what it implies, e.g. is the source or the binary (re)distributable? Many firmwares have been tagged as distributable. Or the arpack package in the submission queue is also distributable, but possibly not modifiable (which is a blocker, and the authors have been requested to modify the wording, but that's OT). In fact it opens up the general issue of what the tag really associates to, the source or the binary or both. Technically the main package and the source package have to share the same license text, subpackages can have different licenses (and there are real life examples having different licenses in subpackages). Also since there is a distinction of GPL<=2 and GPL3, the LGPL should also deserve its own license tag. While currently the disute about GPL2 vs GPL3 is still ringing in our ears, the differences between GPL and LGPL are bigger IMHO. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Tue Nov 28 15:03:20 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 28 Nov 2006 09:03:20 -0600 Subject: [Fedora-packaging] Re: --vendor fedora, rationale/motivation? In-Reply-To: <20061125223740.GD1614@neu.nirvana> References: <20061125223740.GD1614@neu.nirvana> Message-ID: <456C4FB8.5010704@math.unl.edu> Axel Thimm wrote: > this discussion resulted in some recommendations in the guidelines and > elsewhere, but old packages are supposed to keep any naming (vendor) > they used for backwards compatibility with menu editors, correct? Yep, that is the primary(only?) motivation for keeping dir+vendor+desktop_file_name constant. > What do you think? I agree with your sentiments. Package maintainers need to weigh the pros/cons of continuing the use of --vendor=fedora. If you feel the advantages of dropping it outweigh the disadvantage of possibly breaking users' customized menus, I see no problem with that. -- Rex From tibbs at math.uh.edu Tue Nov 28 15:20:39 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Nov 2006 09:20:39 -0600 Subject: [Fedora-packaging] Re: Revived License: tag proposal In-Reply-To: <20061128142832.GD9632@neu.nirvana> References: <20061128142832.GD9632@neu.nirvana> Message-ID: >>>>> "AT" == Axel Thimm writes: AT> Also since there is a distinction of GPL<=2 and GPL3, the LGPL AT> should also deserve its own license tag. Of course it does; is there anything that doesn't use a tag of "LGPL" to indicate the LGPL? Does your statement indicate that you think something should be changed about the draft? I haven't yet presented a list of licenses that should receive standardized tags. - J< From tibbs at math.uh.edu Tue Nov 28 15:21:52 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Nov 2006 09:21:52 -0600 Subject: [Fedora-packaging] Revived License: tag proposal In-Reply-To: <20061128141827.GC19109@rathann.pekin.waw.pl> References: <20061128141827.GC19109@rathann.pekin.waw.pl> Message-ID: >>>>> "DM" == Dominik 'Rathann' Mierzejewski writes: DM> Old BSD... how about naming it "Original BSD", per DM> http://www.fsf.org/licensing/licenses/index_html#OriginalBSD That would be a reasonable item for discussion. DM> Also, why not PHPL instead of PHP License? Does any existing package use "PHPL"? I don't see any. Several packages use "PHP License". - J< From Axel.Thimm at ATrpms.net Tue Nov 28 15:48:10 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 28 Nov 2006 16:48:10 +0100 Subject: [Fedora-packaging] Re: Revived License: tag proposal In-Reply-To: References: <20061128142832.GD9632@neu.nirvana> Message-ID: <20061128154810.GB19780@neu.nirvana> On Tue, Nov 28, 2006 at 09:20:39AM -0600, Jason L Tibbitts III wrote: > >>>>> "AT" == Axel Thimm writes: > > AT> Also since there is a distinction of GPL<=2 and GPL3, the LGPL > AT> should also deserve its own license tag. > > Of course it does; is there anything that doesn't use a tag of "LGPL" > to indicate the LGPL? > > Does your statement indicate that you think something should be > changed about the draft? I haven't yet presented a list of licenses > that should receive standardized tags. OK, I thought the list of the 8 licenses beneath the "plan" heading was already what you were suggesting as a set, sorry for the noise. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Wed Nov 29 20:09:24 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 29 Nov 2006 22:09:24 +0200 Subject: [Fedora-packaging] How to make a Provides based on package contents? In-Reply-To: <456B7021.6050602@cora.nwra.com> References: <4564C60D.40204@cora.nwra.com> <1164391259.3568.12.camel@viper.local> <456B7021.6050602@cora.nwra.com> Message-ID: <1164830964.3435.17.camel@viper.local> On Mon, 2006-11-27 at 16:09 -0700, Orion Poplawski wrote: > I went with octave(%{octave_api}) rather than octave(api) = > %{octave_api} The potential problem with that is that it has severely limited possibilities of versioned dependencies - only an exact match works, you can't do eg. ">=" with it. You know better than me whether that's actually ever likely to become a problem in this case. In the VDR case, I'm using the API version like "Provides: vdr(abi) = ..." and "Provides: vdr-devel(api) = ..." in the main and -devel packages, and "BuildRequires: vdr-devel(api) >= ..." and "Requires: vdr(abi) = ..." in plugin packages. > because I was getting errors when starting to build a > package in mock that octave(api) was not being set to anything (during > the buildroot setup phase - octave-config is unavailable there). If > someone can point me around that, that would be great. Like tibbs said, just make sure it parses correctly even if octave is not available. The %{apiver} definition in vdr-subtitles and vdr-osdteletext packages contain one example way to do it. From ville.skytta at iki.fi Wed Nov 29 20:29:46 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Wed, 29 Nov 2006 22:29:46 +0200 Subject: [Fedora-packaging] Re: --vendor fedora, rationale/motivation? In-Reply-To: <456C4FB8.5010704@math.unl.edu> References: <20061125223740.GD1614@neu.nirvana> <456C4FB8.5010704@math.unl.edu> Message-ID: <1164832186.3435.24.camel@viper.local> On Tue, 2006-11-28 at 09:03 -0600, Rex Dieter wrote: > Package maintainers need to weigh the > pros/cons of continuing the use of --vendor=fedora. If you feel the > advantages of dropping it outweigh the disadvantage of possibly breaking > users' customized menus, I see no problem with that. Maybe it's just me, but the only case I can come up with at the moment that would warrant breaking people's menus or desktop icons would be if it'd be necessary in order to resolve a filename conflict. From dominik at greysector.net Wed Nov 29 21:58:05 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 29 Nov 2006 22:58:05 +0100 Subject: [Fedora-packaging] Revived License: tag proposal In-Reply-To: References: <20061128141827.GC19109@rathann.pekin.waw.pl> Message-ID: <20061129215805.GC12081@rathann.pekin.waw.pl> On Tuesday, 28 November 2006 at 16:21, Jason L Tibbitts III wrote: > >>>>> "DM" == Dominik 'Rathann' Mierzejewski writes: > > DM> Old BSD... how about naming it "Original BSD", per > DM> http://www.fsf.org/licensing/licenses/index_html#OriginalBSD > > That would be a reasonable item for discussion. Are there any dissenting opinions? > DM> Also, why not PHPL instead of PHP License? > > Does any existing package use "PHPL"? I don't see any. Several > packages use "PHP License". Or maybe simply "PHP". It's short and License: PHP conveys the full meaning, I think. I don't care much if it stays "PHP License", though. Just throwing ideas. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From orion at cora.nwra.com Wed Nov 29 23:41:19 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 29 Nov 2006 16:41:19 -0700 Subject: [Fedora-packaging] Where to put pixmaps Message-ID: <456E1A9F.2060104@cora.nwra.com> The latest apcupsd ships a Gtk gui and by default installs the following pixmaps: %{_datadir}/pixmaps/apcupsd.png %{_datadir}/pixmaps/charging.png %{_datadir}/pixmaps/gapc_prefs.png %{_datadir}/pixmaps/onbatt.png %{_datadir}/pixmaps/online.png %{_datadir}/pixmaps/unplugged.png The names are sufficiently generic enough to seem like this is a bad spot. Is there a standard? Don't see anything on the wiki. Thanks! - Orion -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From rdieter at math.unl.edu Thu Nov 30 12:54:17 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 30 Nov 2006 06:54:17 -0600 Subject: [Fedora-packaging] Re: Where to put pixmaps References: <456E1A9F.2060104@cora.nwra.com> Message-ID: Orion Poplawski wrote: > The latest apcupsd ships a Gtk gui and by default installs the following > pixmaps: > > %{_datadir}/pixmaps/apcupsd.png > %{_datadir}/pixmaps/charging.png > %{_datadir}/pixmaps/gapc_prefs.png > %{_datadir}/pixmaps/onbatt.png > %{_datadir}/pixmaps/online.png > %{_datadir}/pixmaps/unplugged.png > > The names are sufficiently generic enough to seem like this is a bad > spot. Is there a standard? Don't see anything on the wiki. Standards? yes: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html -- Rex From laurent.rineau__fedora_extras at normalesup.org Thu Nov 30 13:07:38 2006 From: laurent.rineau__fedora_extras at normalesup.org (Laurent Rineau) Date: Thu, 30 Nov 2006 14:07:38 +0100 Subject: [Fedora-packaging] Re: Where to put pixmaps In-Reply-To: References: <456E1A9F.2060104@cora.nwra.com> Message-ID: <200611301407.38580@rineau.schtroumpfette> On Thursday 30 November 2006 13:54, Rex Dieter wrote: > Standards? yes: > http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html > http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html FreeDesktop.org does not pusblish standards, but proposals. According to http://www.freedesktop.org/wiki/Standards, the "Icon Theme" spec is quite agreed, but the "Icon Naming" is too new. What is the relationship between Fedora and FreeDesktop.org? What fd.o proposals should be considered as guidelines for Fedora? Has it been discuted by Fesco? Is there a Wiki page on the subject? As far as I understand, FreeDesktop is more a guide for upstream developpers than for downstream. -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau