Re: Change to DSO-linking semantics of the compiler
Charley Wang wrote: > A rebuild was conducted, and a preliminary (unsorted) list of packages > that have implicit linkage errors can be found here: > > https://fedoraproject.org/wiki/DSOLinkBugs I still think that a backwards-incompatible change to something as central as linking semantics (the implicit linking is more or less part of ELF semantics) hitting so many packages is a very bad idea and that it's unrealistic to get them all fixed for F13. I also think that this change will probably force us to ship .la files. The only reason we didn't need them so far was that implicit linking feature. Sadly, my concerns got ignored at the FESCo meeting where this "feature" was discussed:-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
Charley Wang wrote: > Please note that many of the packages may be failing because of a few > DSO's. Further exploration is needed to evaluate this possibility so > we can apply one patch to the source of the problem instead of dozens of > superfluous patches. We also need (and would appreciate help with) the > linking of failed build logs to their package owners. And how would you fix that in the DSO other than by adding a .la file (which is against our packaging guidelines) or a linker script (which basically amounts to the same) to force the extra -l flag? Linking the DSO to the one providing the symbols is not enough due to the very change which is causing the problems. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
On Wednesday 13 January 2010, Adam Williamson wrote: > On Tue, 2010-01-12 at 01:59 +0100, Milos Jakubicek wrote: > > Also I have really doubts what concerns upstreamability of the necessary > > changes in packages. Especially if other distributions will (???) > > continue shipping ld with the traditional semantics, this means hours of > > headache discussions with upstream not willing to accept the patch. > > I may be misunderstanding, but I believe this is the same thing Mandriva > refers to as underlinking: > > http://wiki.mandriva.com/en/Underlinking No, it's not the same thing: Consider an executable a, a library libb.so and a library libc.so, and a is linked against -lb: * underlinking is if libb.so uses symbols from libc.so, but does not link against -lc. Then you have to link a explicitly against -lb -lc even if it only uses symbols from libb.so. This is a bug in libb.so. * what is being discussed here is if libb.so DOES link libc.so, but now executable a uses symbols from libc.so without also using -lc. If libb shipped a libb.la file which did -lb -lc (which .la files tend to do), then a will link file everywhere else, just not on Fedora because we delete .la files. The old semantics made this case work without the .la file, the new semantics lead to programs failing to link in Fedora, making Fedora incompatible with upstream (unless we start to ship .la files again). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Change to DSO-linking semantics of the compiler
On Wednesday 13 January 2010, Adam Williamson wrote: > On Tue, 2010-01-12 at 01:59 +0100, Milos Jakubicek wrote: > > Also I have really doubts what concerns upstreamability of the necessary > > changes in packages. Especially if other distributions will (???) > > continue shipping ld with the traditional semantics, this means hours of > > headache discussions with upstream not willing to accept the patch. > > I may be misunderstanding, but I believe this is the same thing Mandriva > refers to as underlinking: > > http://wiki.mandriva.com/en/Underlinking No, it's not the same thing: Consider an executable a, a library libb.so and a library libc.so, and a is linked against -lb: * underlinking is if libb.so uses symbols from libc.so, but does not link against -lc. Then you have to link a explicitly against -lb -lc even if it only uses symbols from libb.so. This is a bug in libb.so. * what is being discussed here is if libb.so DOES link libc.so, but now executable a uses symbols from libc.so without also using -lc. If libb shipped a libb.la file which did -lb -lc (which .la files tend to do), then a will link file everywhere else, just not on Fedora because we delete .la files. The old semantics made this case work without the .la file, the new semantics lead to programs failing to link in Fedora, making Fedora incompatible with upstream (unless we start to ship .la files again). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gvfs causes hangs
Adam Williamson wrote: > I don't believe it was ever escalated as a blocker. I probably didn't > consider promoting it as one at the time as FUSE isn't used for any > normal native Linux mount. Probably the most common use of FUSE is for > mounting NTFS partitions via ntfs-3g, but I'm not sure that's vital / > common enough to block a release. The problem is that gvfs also uses FUSE (AIUI, it can work without, but FUSE mounting for the benefit of non-gvfs-enabled apps is enabled by default). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning xerces-c
Peter Lemenkov wrote: > Seems that things are getting even worse. I found the only way to > completely resign from the maintainership of xerces-c - by pressing > the "Retire Package" button. And now the package has "Deprecated" > status and no other buttons are active. "Retire package" is for when you want to completely remove a package from the distribution, it was the "big red button" you were not supposed to hit. Now only a cvsadmin can fix your mess. But you'd have needed an admin anyway to reassign ownership directly and thus bypass this "automatically reassign to the comaintainer" "feature". Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gvfs causes hangs
Steve Grubb wrote:
> Digging into this further, if you run lsof, it hangs when it gets to
> ~/.gvfs:
It is possible to disable FUSE mounting in gvfs, see:
http://lists.fedoraproject.org/pipermail/users/2009-August/084569.html
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OpenModelica users wanting to have rpms?
Christoph Höger wrote: > I have started converting MetaModelica to autootols to boot-bootstrap > the omc build process. May I suggest using CMake instead? It's easier to use, its new versions are more backwards-compatible with older ones, it's more portable to other (inferior ;-) ) operating systems, it doesn't require or expect you to ship generated files in source tarballs, it supports nice features like progress percentages, it's faster and it's successfully used in more and more upstream projects, including all of KDE. On the other hand, CMake would probably be less than helpful for the SML parts, which comprise a significant portion of the codebase as far as I can see, you'd have to work with add_custom_command which isn't that wonderful. (For common languages like C/C++ and a few others, CMake does a lot of stuff for you, but less common ones aren't really supported and you end up having to write CMake commands equivalent to makefile rules.) So each tool has its advantages and drawbacks. > Building the rml compiler and the related libraries was easy, but now I > could need some help and advice on how to build the testcases. > In the original buildsystem from > https://openmodelica.ida.liu.se/svn/MetaModelica there are some examples > with own makefiles, but those refer to the buildsystem itself. > I am not sure how to handle this with automake (obviously it would > require to build the compiler before the tests). > So currently I am wondering if the examples should have a build system > that requires the compiler to be installed, any thoughts? Normally testsuites can use the just-built compiler directly from the source tree. Look at existing projects and how they handle this. As you're using autotools, I guess GCC would be a good place to look. > On the other hand, there are some "style" questions, I'd like to be > answered: > > This package builds three slightly different libraries in three differen > flavors: called (librml_plain|librml_mask|librml_diff)(_g|_p|).so > Those flavors only differ by the CFLAGS set upon compilation (_p means > -p, _g -g). > Upstream told me, they require them all, but would this be acceptable? Sure, I don't see why not. You just need to be careful when building (you need to build the object files to different places so they don't conflict). > Is the name rml ok for a library in /usr/lib or shall I > use /usr/lib/rml/ by default? (Same for headers) Hmmm, that's a bit at the limit, 3 letters are a bit short for a unique name. :-( But there's no librml.so in Fedora yet as far as repoquery tells me, so at least there's no current conflict. Let's see what others think. > What with the name? Is MetaModelica even a good name, if the main binary > is rmlc? If that's the upstream project name (used in things like tarballs), it's fine. (But is the MixedCase really necessary? :-( Usually things like tarball and package names are all lowercase, but sometimes MixedCase is used by upstream and the Fedora packages usually match that. Probably something to discuss with upstream.) > The package builds a compiler driver, essentially a shell script, by > copying some configuration variables into a shell template (mainly how > to invoke cc). Would this be fine as a /usr/bin script? Yes, but beware of multilib conflicts: if that script is in the same package as some libraries, that package will end up multilibbed due to the libraries and if the script is not identical for 32-bit and 64-bit, there will be a conflict between the 2 multilibbed packages. (Splitting out the libraries into a -libs package is a way to work around that.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Purging the F13 orphans
Jesse Keating wrote: > Unblocked orphan gtk-qt-engine This one was basically retired by rdieter (kcm-gtk Obsoletes it, though it contains only the KCM part, the theme engine was unstable and is dead upstream), I guess the retiring process was just not completed properly. So I guess this one can just die. > Unblocked orphan qtoctave I'll pick this one up, it's useful (a Free Software equivalent to the MATLAB GUI), it's in my area of expertise (Mathematics tool, and Qt-based, even), there's AFAIK no obvious replacement and upstream seems active. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Purging the F13 orphans
Kevin Kofler wrote: > Jesse Keating wrote: >> Unblocked orphan qtoctave > > I'll pick this one up, it's useful (a Free Software equivalent to the > MATLAB GUI), it's in my area of expertise (Mathematics tool, and Qt-based, > even), there's AFAIK no obvious replacement and upstream seems active. Actually, it looks like this one already got taken care of (nucleo picked it up), but I filed for comaintainership. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100128 changes
[snip] > New package OpenGTL > Graphics Transformation Languages > New package aseqmm > C++/Qt4 wrapper around the ALSA library sequencer interface > New package bristol > Synthesizer emulator > New package certmonger > Certificate status monitor and PKI enrollment client > New package font-manager > A font management application for the GNOME desktop environment > New package iwl5150-firmware [and it ends here] The report got truncated yet again. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: best practice for packing programs that use strlcpy()?
Eric Smith wrote: > What is considered the best practice for packaging a program that uses > strlcpy()? > Is there a Fedora library that provides strlcpy() and friends? > Should I add an implmentation of strlcpy() to the package as an > additional source or patch? > Should I modify the program to not need strlcpy()? (I really don't like > this idea.) You're the victim of a longstanding feud between people who think strlcpy and friends are essential for security (including the OpenBSD community, who invented them, and several application developers) and those who think they're just useless nonstandard functions (including Ulrich Drepper, the glibc maintainer), with no resolution in sight, unfortunately. :-( Well, technically: > Is there a Fedora library that provides strlcpy() and friends? libkdefakes.so.5 provides strlcat and strlcpy, but as that's part of kdelibs it's probably not the answer you were looking for. ;-) libbsd sounds like a decent solution, probably the best you'll get due to the conflict cited above. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Draft privilege escalation policy for comments
Adam Williamson wrote: > Please do provide any and all feedback on the proposed policy. if we can > get it into a shape which most people on the list would find acceptable, > my next step will be to take it back to FESco for them to review. > Thanks. >From the proposal: > Add, remove, upgrade or downgrade any system-wide application or shared > resource (packaged or otherwise) The current PackageKit policy in F12 updates still allows upgrading (as opposed to installing or removing, not sure about downgrading, does PackageKit even support that?) packages without root authentication. Is this intended to be changed as part of the proposal or should the proposal be fixed instead (just remove "upgrade" from the sentence)? > New and changed privilege escalation mechanisms Is the bureaucracy in this section really necessary? AFAICT what was missing when the F12 PackageKit change was made was the informative part of the proposal, the maintainer just didn't know what he should be allowing and what not. I don't think the enforcement part is really needed, maintainers should be able to get it right on their own given the detailed list of evil things to avoid which the proposal provides and I haven't seen any evidence as to the contrary (again, the PackageKit example is not applicable because the PackageKit maintainer did NOT have such a list to go by when he made his change; there's no reason to believe he'd have made that change in spite of it). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
Liu Yu Fei Eric wrote:
> I noticed firefox was stuck on 3.5.6 for a rather long time.
> What about 3.5.7 and the recently 3.6? They are even not in koji.
http://blog.famillecollet.com/post/2010/01/22/Firefox-3.6-en
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Draft privilege escalation policy for comments
Adam Williamson wrote: > I think it's sensible, yeah. It's not really much bureaucracy; I don't > think it would ever be a good idea to introduce a new privilege > escalation mechanism without FESco knowing about it... Right now we're in a phase where a lot of stuff (system-config-*, several parts of KDE and some other stuff) is getting ported from running the whole app under consolehelper or kdesu to PolicyKit mechanisms. This is generally seen as a *good* thing. It'd be really annoying to have to go through a FESCo vote for every single one of those. At the very least, I'd suggest adding the following clause to that paragraph: "Any mechanism which requires administrative authentication to perform the privileged action (e.g. auth_admin policy in PolicyKit, kdesu etc.) is NOT a privilege escalation mechanism for the purposes of this paragraph." Rationale: Such a policy does not impact the system's security as you have to enter the root password before doing anything dangerous, so none of the invariants under "Requirements" can be violated. And additionally, you can always as a user run the whole app under e.g. kdesu and thus "escalate your privileges" using the root password, so it doesn't make sense to police apps providing such a mechanism. What really matters for security is what you can do WITHOUT the root password. This is not really clear from the policy as written now, adding the suggested sentence would clarify it. (That said, I don't see even the clarified policy as being necessary. We have a set of guidelines, maintainers should follow them, why do we have to police them? As I explained before, there is no evidence that this is necessary or useful. The PackageKit issue was caused by lack of a policy, not lack of enforcement.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
Wes Shull wrote: > yum --enablerepo=rawhide update firefox NEVER do that!!! You probably have way more Rawhide packages than just Firefox now. At least xulrunner and all the stuff using its "unstable API", probably also sqlite and a lot more stuff. Each time your package depends on a newer library with a new ABI, you end up dragging in the new library, which in turn drags in rebuilt versions of ALL programs using that library! And of course this continues in a transitive chain! That quickly sums up to half of the distro leaving you with an unsupportable mix of F12 and Rawhide. And even if it worked for you, it is a big mistake to recommend this to other users who do not understand the implications. Please NEVER recommend this to another user again!!! (And I'd also STRONGLY recommend against doing that again yourself.) The ONLY safe use of --enablerepo=rawhide is a full "yum --enablerepo=rawhide update", at which point you're running Rawhide with all its warts, something I'd NOT recommend to an average user. Selective upgrades from Rawhide are NOT SUPPORTED and will in many cases NOT work as expected due to dependencies and reverse dependencies. (IMHO, it might make sense for yum to reject --enablerepo=rawhide for anything other than a full upgrade.) This is what repositories like Remi's are for! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
Mail Lists wrote:
> I think we need to use sun java as green tea is not yet on new api
> anyway is it?
The IcedTea plugin is in Fedora (as java-1.6.0-openjdk-plugin). Fedora does
not and will not ship proprietary software such as the Sun Java plugin (from
the non-open JDK or JRE).
A new version of IcedTea with a new plugin which supports Firefox 3.6 is
being imported into Rawhide. This would have to be backported if Firefox 3.6
were to be pushed to F12.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
Frank Murphy wrote: > You can update to 3.6 > from Rawhide, > then disable rawhide again. > > Which is what I have done, > no problems yet. NEVER do that!!! You probably have way more Rawhide packages than just Firefox now. At least xulrunner and all the stuff using its "unstable API", probably also sqlite and a lot more stuff. Each time your package depends on a newer library with a new ABI, you end up dragging in the new library, which in turn drags in rebuilt versions of ALL programs using that library! And of course this continues in a transitive chain! That quickly sums up to half of the distro leaving you with an unsupportable mix of F12 and Rawhide. And even if it worked for you, it is a big mistake to recommend this to other users who do not understand the implications. Please NEVER recommend this to another user again!!! (And I'd also STRONGLY recommend against doing that again yourself.) The ONLY safe use of --enablerepo=rawhide is a full "yum --enablerepo=rawhide update", at which point you're running Rawhide with all its warts, something I'd NOT recommend to an average user. Selective upgrades from Rawhide are NOT SUPPORTED and will in many cases NOT work as expected due to dependencies and reverse dependencies. (IMHO, it might make sense for yum to reject --enablerepo=rawhide for anything other than a full upgrade.) This is what repositories like Remi's are for! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
Christopher Brown wrote: > This is because 3.5.7 doesn't affect us. Stability issue is for > Windows people and update notification is patched out for obvious > reasons. > > https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20status1.9.1%3A.7-fixed What about the NTLM issue? That looks like it could affect Fedora users if they are behind a Window$ Vi$ta or 7 proxy. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fast-track Nonresponsive maintainer: Frank Büttner (frankb)
Frank Büttner wrote:
> I have done some like at my first package, and then to my was spoken,
> that I use local mock and not the infrastructure. But after some updates
> of mock, mock it now dead. The no response from them maintainer.
Don't worry, even I get away with my intensive use of Koji. ;-) I rarely do
local mock builds (mostly only if I build stuff for repo.calcforge.org or if
I can't use a Koji build for some reason, like not having the right stuff in
the buildroot), I just send everything straight to Koji and I maintain more
stuff than you. ;-)
FWIW, I usually only scratch build if the package is pending review.
Otherwise, I just do this routine:
* commit change
* make tag
* make build BUILD_FLAGS=--nowait
* while (build failed) {
* commit fix
* make tag TAG_OPTS=-F
* koji resubmit taskid --nowait
}
The advantage over scratch builds is: if you scratch-build, once it's
successful, you have to redo the build as a real build, so you waste one
build. With my workflow, you save that build. Saves both Koji resources and
your time. Also saves your time over local mock builds where you also have
this "one wasted build" problem.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to take ownership of a package in rawhide branch? - Was: [Taking ownership of the orphaned packages: bytelist, jcodings, jvyamlb]
Victor Vasilyev wrote: > I'm trying to complete the step 3 of the "Claiming Ownership of an > Orphaned Package Procedure" [1] that says: > "3. Press the "Take Ownership" button for each active branch that you > want to maintain." > > However, I don't see such buttons associated with the rawhide for all > mentioned packages, i.e. bytelist, jcodings, and jvyamlb. > How I can take ownership of the packages in the devel branch, but not in > Fedora 11? Those packages have been marked as retired because they have been orphaned for more than 3 months. You need to submit new review requests, specifying that this are packages which were previously in Fedora and are being resurrected. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reordering in package changelogs (was Re: rawhide report: 20100129 changes)
Nicolas Mailhot wrote: > This is one reason I prefer to use the following changelog style > > * Thu Jan 28 2010 Michael Schwendt > - 2.2-10 > - Fix tuple_copy() further (it was completely broken as the mowgli > dict wasn't copied at all). > - 2.2-9 > - Let set_tuple_cb() work on a copied tuple > (the metadata updates flood is too racy IMO). > - Fix tuple_copy(). This style is not compliant with the Fedora packaging guidelines. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Draft privilege escalation policy for comments
Miloslav Trmač wrote: > That's not the intent: "mechanism" is "the code that causes running > something as root", in this case DBus activation, not "the code running > as root" (a DBus server). Oh, if that's the intent, that's of course perfectly fine. I'd be happy to provide any needed documentation about KAuth, but you'll only really need it if you want to run checks on the source code, as KAuth uses existing mechanisms (PolicyKit (both 1 and 0.9 are supported), D-Bus activation) for the actual privilege escalation, it's just a source-level abstraction layer (so for example, you won't find a PolicyKit policy in the source code, but a KAuth policy which is converted to a PolicyKit policy at build time). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 Milestone Reached: Feature and Spin Submission Deadlines
Bruno Wolff III wrote:
> https://fedoraproject.org/wiki/Category:Spins_Fedora_13
>
> Some of those are kickstart only and won't have prebuilt isos for
> download.
In addition to these spins, there are also the 2 permanent live spins (GNOME
and KDE) and the non-live installers (DVD, CD set, netinstall).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reordering in package changelogs (was Re: rawhide report: 20100129 changes)
Nicolas Mailhot wrote: > Sure it is, it's changelog style #3 of > http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs No, it's not style #3. It's 2 or more style #3 entries collapsed into 1, which is not one of the allowed formats. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reordering in package changelogs (was Re: rawhide report: 20100129 changes)
Nicolas Mailhot wrote: > That is your interpretation. I see nothing on this page to support this > claim. And actually it is contrary to format #3 logic, since its main > difference with other changelog formats is that the version is not part of > the entry header, so there's no reason to limit one entry to one version It's blatantly obvious that all these formats have one thing in common: there's one entry per new EVR. Our automated tools (e.g. make clog as already pointed out by Michael Schwendt) also expect that. But I guess I'll need to get the FPC to officially clarify this. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: KDE-SIG meeting report (05/2010)
Richard Hughes wrote: > On 2 February 2010 15:12, Sebastian Vahl > wrote: >> * setroubleshoot introduced a hard dependency on gnome-packagekit >> (#561001) * The dependency should be made generic or setroubleshoot has >> to be removed from KDE spin. > > Is it just a dep on the PackageKit session API? If so can't we just > add a virtual provide "PackageKit-session" to gnome-packagekit and > kpackagekit, and switch setroubleshoot to require that? It's a dependency on something which is no longer used, it seems (instead, they use yum directly in the current code), so they just removed it in Rawhide: https://bugzilla.redhat.com/show_bug.cgi?id=561001 Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reordering in package changelogs (was Re: rawhide report: 20100129 changes)
Nicolas Mailhot wrote:
> This changelog style conforms to the existing spec, it has been in use in
> Fedora for several years, it may surprise you, but changing the spec
> retroactively is not the way to prove your point.
Uh, the Fedora packaging guidelines DO have the power to change the
requirements, they're not cast in stone. Even existing changelogs can be
fixed.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is PulseAudio dead?
I wrote: > s/desktop/GNOME/ > > KDE packages are tracking upstream closely and are regularly updated, > including upstream bugfixes. Plus, we backport or sometimes even develop > bugfixes of our own. > > To me, this shows that a model where upstream versions are tracked by > updates is much more viable than attempting (and miserably failing) to > backport bug fixes only. > > It also shows that KDE SIG actually has more and/or more efficient > packaging (as opposed to upstream development) manpower than the GNOME > folks, unlike what has been frequently claimed. PS: And since PulseAudio is a shared technology also used by other desktops than just GNOME, I'd be willing to pick up comaintainership, but then it'd very likely be maintained in KDE SIG style, aggressively tracking upstream development. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is PulseAudio dead?
Matthias Clasen wrote: > I was on vacation for two weeks, but I'm back now. So our manpower > should be even again :-) LOL, it's true that you do a lot of work all by yourself. ;-) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Neal Becker wrote:
> OK, got mercurial updated for devel, apparantly OK. Now try to update
> f13:
[snip a bunch of git tribulations]
It's quite telling that the git workflow is so arcane and exotic that even
the maintainer of another DVCS cannot figure it out! Git just has to do
everything in its own bizarre, confusing and broken way. :-(
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is PulseAudio dead?
Rahul Sundaram wrote: > IMO, if you want to be a co-maintainer, you will have to coordinate > and work with the model preferred by the primary maintainer. Otherwise > disputes will make the process worse and not better. This (or rather, the differences in update conception) is exactly why I haven't applied for comaintainership of PulseAudio. I think that this conservative model is really unhelpful as it often lets bugs linger for ages (backporting is a lot of work, so it's rarely done, and sometimes it's outright impractical, not to mention that some very conservative people judge even backporting of non-critical bugfixes to be inappropriate for an update) and that it's very sad that the Board and FESCo are now actively pushing for such a bad model as a global Fedora policy, despite strong evidence that our users do not want this model, and despite the fact that this makes us lose our niche, compete directly with distributions we CANNOT compete with (we stand no chance against Ubuntu's massive marketing machine) and leave users in our current niche out there in the cold with no way to go. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is PulseAudio dead?
Rahul Sundaram wrote: > I believe a co-maintainer if he/she wants to collaborate wouldn't > constrained by differences in approaches and can participate and help > out regardless of that. If you review bug reports, I suspect you will > find ways to help. It just requires letting go of the notion that my > approach is the only right one. I don't believe it is possible to fix PulseAudio bugs effectively without tracking upstream more closely. Upstream is where Lennart focuses his bugfixing. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Matt McCutchen wrote: > Are you comparing git to Mercurial or to a centralized VCS? Both. Git is just a PITA in its own league, but DVCSes as a whole are a broken (*) and unhelpful (inherently hard to use) concept. (*) e.g. because of the strong reliance on hashes, which can make the whole thing break down in the event of a hash collision, and which make commit IDs nonsequential and unpredictable > Some of the complexity is intrinsic to distributed VCS and has to be > weighed against the significant benefits to people who build custom > packages, like me. I don't see how dist-git makes it any easier to build customized packages. If you really want a local git mirror of a centralized repository, you can also use git-cvs, git-svn or the like. For SVN, SVK is also a nice solution. All this dist-git migration has brought us is chaos, a much higher barrier to entry and much harder work for existing packagers. (And yes, I've also tried to make these points BEFORE the migration, but nobody listened.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is PulseAudio dead?
Rahul Sundaram wrote:
> Since there is no new upstream release, you will have to triage bugs,
> cherry pick patches and push them as updates. What else do you mean by
> tracking upstream closely?
If there's no new release, I'd just ship a snapshot.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Matt McCutchen wrote: > "Broken" in the past tense is inaccurate: no SHA-1 collision has been > published yet. I would like to see DVCSes switch to a stronger hash > algorithm sooner rather than later, but it's not enough of a concern > that I would avoid using them. If it makes you feel any better, git > will not allow a fetched object to replace a local one with the same > hash, so you can only lose if you fetch from the attacker first. I'm not talking about intentional collisions, I'm talking about accidental collisions, which ALL hash algorithms are vulnerable to, no matter how strong. Hashes are inherently non-injective and mathematically CANNOT be otherwise. Now the probability of an accidental collision is very low, but it is not zero, so the algorithm is unreliable. And low probabilities add up the more projects use DVCSes. Sooner or later some project will be hit by a collision. And the shorter the hash, the more likely a collision (exponentially!), so the "abbreviated hashes" git uses are particularly collision-prone. > For sequential commit numbering, try "git describe". Nobody actually uses those numbers though (and in fact I doubt those numbers can be used in all the ways SVN revision IDs can be used). What everyone uses is hashes, leaving you to wonder whether deadbeef or c0cac01a is the newer revision (assuming that both are snapshots from master or at least from the same branch, which is usually the case when comparing 2 packaged snapshots). > The problems with CVS were amply explained there, but it's less clear to > me whether there were compelling reasons to choose git over (e.g.) SVN + > git-svn or the people involved just happened to like distributed version > control, as I do. Sure they do, but the problem is that they're FORCING their preference onto everyone, whereas using SVN would have allowed them to work their way (using SVK or git-svn) without breaking our workflow, and SVN has all the required features (e.g. atomic commits and thus repository-wide revision IDs). Sadly, more and more projects are getting infected by the git virus, KDE is also moving to git, several other upstream projects already did. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Matt McCutchen wrote: > The only potentially confusing behavior was that git defaulted to > pushing all branches. Given that, the push failed due to a concurrent > change to a different branch on the destination, and it was necessary to > switch to that branch in order to perform the merge (well, rebase, but > the difference isn't important here). I see nothing arcane, exotic, > bizarre, or broken about that. And I don't think I would change the > default push behavior: I can envision forgetting to push a change to a > non-current branch until someone complains about it. The whole idea of having more than one branch in a checkout is confusing. I really don't see why I'd want to have a complete clone of the repository on my HDD rather than a working copy which contains all I actually work on (the current revision of one branch; if I work on multiple branches, that's what directories on my file system are for). (And this is another reason why I consider DVCSes to be broken by design.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is PulseAudio dead?
Rahul Sundaram wrote: > Nevertheless, if you really want to try this method, use > http://repos.fedorapeople.org, No thanks. repos.fedorapeople.org is a very sorry excuse for a PPA infrastructure, it's basically only storage with a list of repos, you have to manage everything by hand, there's no build system integration of any kind (e.g. if you try to build 2 packages which depend on each other, you have to build them outside of Koji; and there's also no direct upload from Koji), you can't even run createrepo on the server (or at least the instructions explicitly tell you not to)! I already have more helpful infrastructure than that on repo.calcforge.org, at least I can run createrepo and repoview on the server, and I can also maintain my specfiles and patches on svn.calcforge.org. (And I used to think that my infrastructure is very poor due to how much stuff I have to manage manually. Guess what, the one now officially offered to us is worse!) What is needed to offer proper support for personal repositories: * automatic creation of *-release packages, * self-populating Koji build targets, so dependent packages can be built, * automatic (maybe triggered by Bodhi or some similar tool) uploading of build results from Koji, including signing the output and running createrepo and repoview, * revision control for the custom packages. (Yes, git allows me to put up a repo on my HDD or on fedorapeople.org. No, I don't want to have to do this manually, and a local repo on my HDD makes me vulnerable to data loss. Plus, the manual approach means every maintainer will put his repositories in a different place, so good luck finding some maintainer's repository if you need it.) Frankly, repos.fedorapeople.org is really poor compared to e.g. the OpenSUSE Build Service (OBS), and in fact I'd recommend the latter (it can also target Fedora) if it weren't for some important issues with their Fedora targets: they don't support Rawhide nor Branched (at least last I checked), they build against GA with no updates (unless they fixed that recently) and they do strange things to specfiles (like automatically bumping Revision) and encourage the use of constructs which don't work outside of OBS. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Peter Hutterer wrote: > I think this may be the main issue here - there is no meaning of "newer" > in git. There is a partial order given by ancestry, and 2 revisions you want to compare WILL in general be ordered. (In fact, whenever it makes sense to numerically compare SVN revision IDs, the commits will also be ordered in a DVCS. Comparing revision IDs from different branches or even different repositories does not make sense in SVN either, but that's not what people are interested in anyway.) > Don't rely on it an you'll be fine. What matters is whether a change is in > a repository or not. Which one is newer hardly ever matters. Nonsense. If, say, Fedora ships foo-12345678 and Ubuntu ships foo-abcdef00, you'll want to know whether 12345678 or abcdef00 is the newer snapshot from the master of foo. (And if they're both snapshots from master, they WILL be ordered unless upstream rewrote their published history, which is just plain evil.) Or, another use case, if we have foo-3.14-0.17.12345678git.fc12 and foo-3.14-0.18.abcdef00git.fc13, how do you verify that the upgrade path is correct and does not in fact downgrade foo when upgrading to F13? The sequence number before (17 vs. 18) might have been incremented due to one or more plain rebuild(s), it doesn't necessarily reflect the sequence of upstream snapshots being packaged. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Matt McCutchen wrote: > That's not strictly true: you're welcome to write svn-git. But the > point is taken, and that's why I invited clarification as to the reasons > for choosing git. Bolting a distributed client onto a central server makes sense. A central client with a distributed server doesn't. Git doesn't (by design) support the required server-side operations. I'd have to set up an SVN gateway to the repository on some server. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Matt McCutchen wrote: > You might like this article: > > http://valerieaurora.org/review/hash.html That article makes my point pretty well. > I'm willing to accept the miniscule probability of a collision. If you > aren't, I have some other windmills for you to tilt at. I am not willing to silently accept anything with a nonzero probability of failure on perfect hardware. Any such algorithm is just incorrect. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Peter Hutterer wrote:
> this is imo superior to re-editing spec files, possibly forgetting to
> update sources/cvsignore in other branches (which has happened in the
> past). I know what the original commit did, so cherry-picking it to other
> branches will do the same.
With the CVS workflow, I usually just copied the specfile, sources and
.cvsignore from devel, no re-editing.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Oh, and I forgot: Peter Hutterer wrote: > it's likely that one you get used to git you'll be using branches heavily. > And once you start using several branches interchangably, directories > don't cut it anymore compared to git. > > one example: updating to a new version of the wacom driver was a matter of > fedpkg clone xorg-x11-drv-wacom > > fedpkg commit && fedpkg push && fedpkg build > > fedpkg switch-branch f14 > git cherry-pick master > fedpkg commit && fedpkg push && fedpkg build > > fedpkg switch-branch f13 > git cherry-pick master > fedpkg commit && fedpkg push && fedpkg build I don't see why I'd want to magically switch the branch of my directory to do this. This makes much more sense (assuming a fedpkg clone -B that actually works, I don't know whether they already fixed that, and I guess you need to do those extra git pull operations if you work that way due to git's ugly design): fedpkg clone -B xorg-x11-drv-wacom cd xorg-x11-drv-wacom/master fedpkg commit && fedpkg push && fedpkg build cd ../f14 git pull git cherry-pick master fedpkg commit && fedpkg push && fedpkg build cd ../f13 git pull git cherry-pick master fedpkg commit && fedpkg push && fedpkg build That way the contents of your directories always contain the same branch, so you don't end up accidentally committing to the wrong one. But I guess git will be storing a lot of redundant stuff and forcing extra pulls if you work that way. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Peter Hutterer wrote:
> consider the use-case where the spec files aren't 100% identical because
> they have different changelog history, or build instructions, or any other
> reason a part of the spec file may be differnt to the ones being changed
> right now. by copying it over, you destroy that information.
I always just lived with that. I'm rebuilding the Rawhide package as an
update for releases, so the changelog is the one which lead to the Rawhide
package, I don't care if the previous branch changelog gets trashed.
If there are functional differences between the releases (e.g.
BuildRequires), that's what 0%{?fedora} is for.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Matt McCutchen wrote: > If you want to talk about correctness of algorithms, there is a notion > of "negligible" (less than inverse polynomial) probability of failure > that can be used. In the real world, you are not doing yourself any > measurable good by professing to go after this risk which is orders of > magnitude smaller than all the others you face every day. I'm a mathematician, for me there's no such thing as a "negligible" failure probability. The probability of failure is either zero (i.e. the algorithm works) or not (i.e. the algorithm doesn't work). Using an algorithm which doesn't work is unacceptable. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is PulseAudio dead?
Bastien Nocera wrote: > Shipping snapshots doesn't require much brain waves, knowing what to put > in the snapshots, knowing what to backport does. This is exactly why I suggest to ship snapshots from master wholesale, then we don't have to bother with cherry-picking. Of course, ideally, we'd have an actual upstream release to ship. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git branch help?
Chris Adams wrote: > Still using Token Ring because that evil random Ethernet could fail? No (we're basically all being forced to use Ethernet, it's everywhere), but Ethernet's design makes me feel extremely uncomfortable. Give it enough load and it WILL break down under the collisions. > How do you verify RPMs (or any other signed data for that matter)? Hashes work for signatures because they only need to protect against intentional collisions. But yes, they won't give you 100% certainty that the package hasn't been tampered with, just strong evidence. (But that'd be the case even if you sign the whole bytestream, since there's always the eventuality that the attacker has secretly compromised the signature algorithm or the signing key.) It's better to have 99.9% certainty of an untampered package than no certainty at all. That said, I've installed enough stuff with no signature checking at all… In fact, almost all of us did at some point, e.g. the first time you install a third-party repository's *-release RPM, you can't check its signature. (Well, you could download the key from the web page and check manually, but how do you verify that the key you downloaded is the correct one?) In addition, even packages legitimately signed by the repository could have been compromised at some other point in the chain. Signature mechanisms are NOT the perfectly tamper-proof protection they're advertised as. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git tag question
Dennis Gilmore wrote: > the plan is to have something watching for successful builds and to apply > a tag to git then. We don't currently have that piece yet Then why was dist-git brought live without this ESSENTIAL component? Why did we have to rush migration to buggy (see all the complaints about fedora-packager/fedpkg bugs) and incomplete infrastructure? New infrastructure should first be COMPLETED before it is migrated to. I see no reason why the switchover to git couldn't have waited until later (say, after the F14 release), with the missing pieces in place. And once that component is in place, will it also retroactively tag git for all the builds that are happening now or will we be stuck with builds without a matching named tag in the repo forever? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git tag question
Jarod Wilson wrote:
> I'm not having any problems submitting builds and adding tags by hand
> *which is exactly what we did in cvs*. What exactly is ESSENTIAL about
> the nvr tags being automated for you?
The fact that most builds will end up with no named tags at all because
dist-git doesn't enforce manual tagging nor is it in the packager SOP.
Having successfully built versions be tagged in the SCM so that the sources
corresponding to a given NVR can be easily checked out at any time was
posted as one of the essential requirements on the SCM setup. The current
implementation does not comply to that essential requirement. Thus, this is
a showstopper which should have blocked putting dist-git into production.
Plus, automatic tagging was promised as THE reason we switch to dist-git in
the first place.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
Bill Nottingham wrote:
> Orphan: nas
> gstreamer-plugins-bad-free requires nas-devel = 1.9.1-6.fc12
> gstreamer-plugins-bad-free-extras requires libaudio.so.2
> speech-dispatcher requires libaudio.so.2
> speech-dispatcher requires nas-devel = 1.9.1-6.fc12
I suggest that these be just built without NAS support. NAS is basically an
older competitor to PulseAudio with fewer features (it focuses on network
transparency, which is just one of the things PulseAudio does), it is not
compatible with PulseAudio, few to no people use it.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: EsounD (was: Re: [ACTION REQUIRED] orphaned packages in F-14)
Michael Schwendt wrote: > Does anybody think the same about EsounD? > We still include it in Fedora. We still build lots of audio packages > for it. But is it still being used by anyone? PulseAudio emulates the ESounD protocol and for some legacy applications (not even all proprietary), it's the best or even the only way to get them to talk to PulseAudio. We also don't ship the esd daemon itself, only the libraries and protocol emulation in PulseAudio. That's quite different from the situation with NAS, where the only implementation is NAS itself, which is incompatible with PulseAudio and which is supported by few applications. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
Petr Pisar wrote:
> PulseAudio is interresting project, but it's absolutely unusable on old
> slow hardware. Last time I checked it out on Pentium TSC (no MMX)
> running at 200 MHz,
Fedora doesn't support that hardware anymore (the minimum is i686 = Pentium
Pro).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: feature freeze?
Peter Czanik wrote: > While I guess, it's too late now to make a switch now, here is some good > news: > http://bazsi.blogs.balabit.com/2010/07/syslog-ng-contributions- redefined.html > Dual licensing will be gone with the upcoming syslog-ng v3.2. Nothing has really changed for practical purposes. There's still a non-Free "Premium Edition" with added features and a crippleware "Open Source Edition". The only thing which has changed is the way the non-Free features are delivered (as plugins instead of relicensing the whole thing). This doesn't resolve the complaint that upstream will be unwilling to add features which are specific to the non-Free edition. Crippleware "OSE"s suck. Fedora should not encourage this practice. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root-doc subpackage slightly obese
Toshio Kuratomi wrote: > I don't think we could just say don't package documentation that's > ridiculously large but perhaps we could make some sort of guideline about > not duplicating formats on extra large docs. Is the case with root-docs > (and/or kdelibs-apidocs) that we have docs in text + html + tex + pdf > + your_format_here? kdelibs-apidocs is only in one format (HTML). However, we may want to add a second format (QCH, which is basically an archive of HTML files) soon because that way we could get Qt Assistant, and with minimal code changes also KDevelop, to display that documentation. (It would be a separate subpackage.) Though shipping only the QCH might also be worth considering. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Alpha Can Still Ship on Time IF these bugs get attention TODAY
Tom "spot" Callaway wrote: > On 08/05/2010 12:59 PM, John Poelstra wrote: >> 597858 [NEW - high - dwa...@redhat.com - --- -] "SELinux is preventing >> firefox from making its memory writable and executable." crashes rawhide >> firefox start > > The update to fix this one out is here: > > https://admin.fedoraproject.org/updates/selinux-policy-3.8.8-10.fc14 As much as I dislike SELinux (and would thus generally tend towards lax SELinux policies), allowing a browser (!!!) to bypass memory protection strikes me as an awfully bad idea. Those JavaScript JITs are a really bad security risk. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root-doc subpackage slightly obese
Jonathan Underwood wrote: > As I said in the bug report, I don't think building docs client side > is the right way to go at all. In the general case this would require > end users to install extra tools to build the docs, and defeats the > purpose of a package managed system such as Fedora. +1 It also bypasses RPM's file ownership system. Scriptlets should really ONLY be used when it is IMPOSSIBLE to package the files in another way. (See also how dropping files into a someconfig.d is preferred to scriptlets tweaking someconfig.) Fedora is NOT a source-based distribution. Whatever can be generated on the build system MUST be generated on the build system, not on the client. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root-doc subpackage slightly obese
Jonathan Dieter wrote: > While in the general case, I would agree with you, in this specific > case, I think it's worth building on the client. 687MB is a very large > download, over 90 minutes on a 1mbit/s link, and 45 minutes on a 2mbit/s > link. Because of the large size and number of files, it also takes a > non-trivial amount of time to actually install the rpm; on my laptop six > minutes. > > In comparison, generating the html documents after installing root-* > (excluding root-doc) took 37 minutes on my laptop. The total install > time is the same for someone with someone with a 3mbit/s link, and > client-side building is faster for someone with a slower link. At what > point would you say it's worth the tradeoff? You need to also think of slow computers. My Pentium 4 Northwood is not going to be as fast at generating the files than a Core i7. And a Pentium Pro (the oldest CPU we support) is going to be a lot slower than even my P4. As for the Internet connection: I've just downloaded root-doc in 4 minutes, at 2.5 megaBYTES per second. And that's in Vienna, Austria. There are places with even faster Internet connections. Not everyone has slow Internet and a fast CPU. In my case, it'd take 20+ times as long to build the documentation on the client than to download it! Plus, there's also other technical issues, e.g. that the files generated that way bypass RPM's file ownership concept. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root-doc subpackage slightly obese
Jonathan Dieter wrote: > I've taken a look at the root source rpm, and it looks like root-doc is > generated by root itself *after* root has been completely built (rather > than as part of root's build process). > > I've opened a bug, https://bugzilla.redhat.com/show_bug.cgi?id=621812 > suggesting that the documentation generation be moved even later, into > the %post section of the root-doc install. This means the documentation > will be generated on the user's machine, eliminating the need for a > massive download. In addition to the issues I pointed out elsewhere in this thread, this means you need to install the source code (!) of the package on the client. This is in itself a significant download and it's something Fedora does not normally do. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100806 changes
Debarshi Ray wrote:
> Waiting for Devhelp to be downgraded to 2.31.x after Fedora 14 Alpha
> is released.
This report is about Rawhide (now targeting F15+), not the F14 branch.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: cvs2cl orphaned
Ville Skyttä wrote: > I no longer use cvs2cl, so I've orphaned it in package database. Go grab > it if you want it. I picked it up, in Fedora only. I'm not interested in EPEL, so if anybody wants it in EPEL, feel free to grab it there and I'll also grant you comaintainership in Fedora if you apply. I'm also fine with any Fedora-only comaintainers, just apply through pkgdb. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root-doc subpackage slightly obese
Toshio Kuratomi wrote: > Depending on the technologies and applications involved I could see > duplication being okay when one format is meant for people utilizing > less /usr/share/doc/foo/* vs running /usr/bin/documentationviewer or > /usr/bin/programmer-ide That's the case for the KDE stuff: plain HTML is for plain browsers, QCH is for Qt Assistant and KDevelop. The only issue is: kdelibs-apidocs is one of the largest binary packages in Fedora… But IMHO we'll really want that QCH. (In fact, we've been discussing building it for a while, I've just been caught up in other stuff.) KDevelop not showing KDE apidocs is a poor state of affairs and a regression from Fedora 12 / KDevelop 3.5. At least the QCH is one file, so it won't bloat the file list in the repository metadata. :-) FYI, I've put up QCH apidocs for discussion in the next KDE SIG meeting (Tuesday 14:00 UTC / 16:00 CEST / 10:00 (AM) EDT / 07:00 (AM) PDT). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root-doc subpackage slightly obese
I wrote: > As for the Internet connection: I've just downloaded root-doc in 4 > minutes, at 2.5 megaBYTES per second. And that's in Vienna, Austria. There > are places with even faster Internet connections. PS: That's my HOME connection. You don't want to know how fast I could download that file at my university. :-p Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root-doc subpackage slightly obese
Chen Lei wrote: > How about qt-doc? Currently, it bundles src/qch/html docs, the src > image files are completely useless and duplicate with files in html > directory. The content of the qch and html docs is identical, since > assistant_adp is dropped by qt 4.7, I suggest to split html docs into > another subpackage or simply drop html docs. Personally, I only use > assistant to open qch format docs. Yes, qt-doc should be split per format. Dropping the HTML docs entirely (in favor of the QCH) is also something I'd consider (for all Qt-based libraries). IMHO, showing those docs is what Qt Assistant is for. We'll discuss this in the meeting. (That said, assistant_adp is NOT dropped in Fedora, we ship a qt-assistant- adp compatibility package because some apps need it. But viewing Qt docs in the compatibility Assistant isn't of much use.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
pbrobin...@gmail.com wrote:
> While the XO-1 is a comparitatively relative higher HW spec (433 mhz
> from memory, so not massive but still double) it might be a worthwhile
> canditdate as there's quite a few of them around the community for
> testing, its not overly powerful and sees similar issues as well.
The N900 also uses PulseAudio (though not on Fedora).
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: feature freeze?
Peter Czanik wrote: > OSE is nothing near to being a crippleware. Most features arrive > simultaneously to OSE and PE (like support for the new syslog spec, > etc.) or appear in PE first and then migrated quickly to OSE (like SSL > and database support). Automatic testing of PE also helped to fix more > bugs in OSE than the community ever did. So the time and energy spent on > PE automagically helps to improve the OSE too. I completely understand why you want to defend your project and why you think your way of doing it is different. The thing is, most if not all of the people who do "Open Core" crippleware try to justify themselves that way. (It's always THEIR project which is alleged to be completely different from all the others.) But the facts speak clear: you (the company you work for) sell a proprietary edition which intentionally has more features than the Free one, ergo the Free one is deliberately crippled. Even if the features eventually show up in the Free edition, that still means people are getting them later than they could. The normal way to develop features in established Free Software projects is to develop them in public, in the development tree (which is also Free Software, obviously), using what is often called the "Open Source Development Model". In fact, several people in the Open Source camp defend Open Source / Free Software specifically BECAUSE it allows that kind of development model. Compared to such a model, yours means having to wait much longer for the features, and being clearly pressured into buying the proprietary version, giving up the freedoms that come with Free Software. (As you can see, I'm familiar with both the Free Software and the Open Source view of things. Your approach satisfies neither.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] adding missing systemd links in rawhide/F14 upgrades
Frank Murphy wrote:
> I guess they are waiting to iron out a few bugs on F14
> systemd\selinux\udev? Before they push the same broken updates to
> F15(Rawhide)
Normally, development is supposed to happen in Rawhide FIRST.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!
Jaroslav Reznik wrote: > On Wednesday, August 11, 2010 04:28:07 pm Michał Piotrowski wrote: >> Hi, >> >> 2010/8/11 Andre Robatino : >> > Fedora 14 Alpha RC3 is now available [1]. Please refer to the >> > following pages for download links and testing instructions. >> >> I downloaded >> http://alt.fedoraproject.org/pub/alt/nightly-composes/desktop/desktop- x86_ >> 64-20100810.15.iso - it is too large to fit on the CD. > > Same for Plasma Desktop ISO - we are oversized now, we know it. FYI, what he calls the "Plasma Desktop ISO" is the KDE-Live spin. KDE upstream now wants people to refer to "KDE" only when talking about the project, the desktop is the "Plasma Desktop" or "KDE Plasma Desktop", the libraries are the "KDE Development Platform", the applications are the "KDE Applications" and the whole thing is the "KDE Software Compilation" (but upstream prefers it if people are specific about what parts of the compilation they talk about rather than just using s/KDE/KDE SC/g). We hope that we will be able to meet the size constraints for the KDE (Plasma Desktop) spin for the Beta and Final. We just had other priorities for the Alpha. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning all my packages
seth vidal wrote:
> All your packages are now orphaned.
>
> Thanks for letting us know.
Do we have a list of the packages that got orphaned? Unfortunately, querying
pkgdb doesn't help anymore now that you set the stuff to orphaned.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning all my packages
Mike McGrath wrote:
> Luckily Remi got a list:
>
> http://lists.fedoraproject.org/pipermail/devel/2010-August/140708.html
Unfortunately, Remi's list only covers php-*, I think there are other
affected packages too. He links to pkgdb for the full list, but that doesn't
work anymore because the packages are now orphaned.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Luke Macken wrote: > - Package update acceptance criteria compliance >https://fedoraproject.org/wiki/Package_update_acceptance_criteria >- Disable direct-to-stable pushes > (https://fedorahosted.org/bodhi/ticket/434) >- Minimum time-in-testing requirements >- Every day bodhi will look for updates that have been > in testing for N days (fedora: N=7, epel: N=14), and will > add a comment notifying the maintainer that the update is > now able to be pushed to stable. >- When someone tries to push an update to stable, bodhi will > look to see if it has the appropriate karma, or if it has > been in testing for more than N days. I think that this is really going to break our workflow! For example, for the Fedora 14 under development, we now have to wait a full week to be able to push fixes for broken dependencies! Fixes for broken dependencies MUST go out to stable ASAP! This draconian crap must be disabled at least for unreleased branches. It's really keeping us from doing our work. A package cannot be any worse than a package that doesn't install at all! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Kevin Fenzi wrote: > Well, this has nothing to do with that. We are currently only pushing > to stable those updates that are needed to fix Alpha release blockers > in F14. So, it wouldn't matter here. It will matter after the Alpha release when urgent dependency fixes will be withheld for 1 week for no reason. (Right now there's a reason they're being withheld, even though I think this really needs to be handled in a better way (a subbranch for the Alpha, maybe? Or even just a f14-alpha tag in Koji, while letting dist-f14 move on?).) > Barring that tho, if they are broken now in f14, it should be very easy > to verify that the update fixes the broken deps and is installable no? Except that the policy needs THREE people to verify that in most cases (given that that's what Bodhi defaults the update threshold to), or two if one is a provenpackager (if that feature has even been implemented, it is in the spec at least, and only because I fought hard to get at least that into the spec, all my really significant amendments have been shot down). >> This draconian crap must be disabled at least for unreleased >> branches. It's really keeping us from doing our work. >> >> A package cannot be any worse than a package that doesn't install at >> all! > > Sure it can. It can eat data, it can remove other packages. it can > break more important ones, it could be broken in different and more > subtle way, etc. All obscure corner cases that have never actually happened (and are realistically just not going to happen with a straight rebuild for dependencies). On the other hand, packages which don't install and cause errors, also blocking updates for the affected people, do happen, very often, and this stupid policy now delays the fixes for them, also preventing some people from installing critical security updates. > We all want a better Fedora. Unfortunately, our conceptions of "better" are VERY different, to the point that I've come to doubt whether you really want a better Fedora. IMHO you just want a DIFFERENT one, one which doesn't fill its niche anymore and is instead yet another conservative distribution, of which there are way too many already. And stuff like broken dependencies just hurts everyone, even the conservative faction. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!
Bruno Wolff III wrote: > I hope to occasionally push back a little against this. When LZMA squashfs > makes it upstream (it looks like it won't happen in time for F14) we will > probably gain about 10% on what we can fit in a given size image. It's quite sad that we're waiting for upstream there. The feature exists, we could ship it, yet we prefer crippling our live images by dropping more and more applications to meet the size constraints with obsolete compression technology. What happened to the leading-edge Fedora? > Another change that could happen is droppong the embedded ext3 image and > use squashfs directly. (Selinux should now be usable on squashsfs file > systems.) That might gain us a bit more space. Won't that break liveinst? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Orcan Ogetbil wrote: > Now without any further testing the package can be pushed to stable, > which contradicts the purpose of this whole change in bodhi. Sssh, why can't you keep quiet about this?! > I think, for packages that are modified during the testing period, > this N should be calculated from the day the last push was made to > testing. NO! I really don't want any small fix to my update to restart the whole testing cycle from scratch! Imagine I want to edit something in the update notes, e.g. add a Bugzilla reference, I have to edit the update for that, but does this warrant new testing? No! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Luke Macken wrote: > Fixed in > https://fedorahosted.org/bodhi/changeset/97b1a9d1f9ceecaaa2128837cc5bbd7f8e495f36 That "fix" is really unhelpful and makes it a PITA to edit updates! In the past, KDE SIG has often edited in some trivial fixes into the final stable push of a KDE grouped update which has been in testing for a long time. Your "fix" breaks that. Plus, edits can also be only to the description or bug references, Bodhi doesn't allow me to edit those without editing the whole update. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The slip down memory lane
Bruno Wolff III wrote: > We've tried that in the past and it didn't work. Slipping the whole > schedule right away is better than slipping piecewise when it comes to > planning. Huh? What's the worst that can happen? That we slip again, being at the same release date as with the cascading slip system. Whereas with the cascading slips, we risk accumulating ANOTHER slip on top of the one that was already there. So I think the practice of cascading slips is actually detrimental to the timeliness of our releases. We shouldn't cascade slips by default. If we then end up having to re-slip the next milestone, then well, that was kinda expected, so it shouldn't be counted as a failure. But we should at least TRY not to cascade the slips. (This is just a generalization of the principle of: slips WILL happen, so schedule for an EARLIER date than your actual target. If you schedule for a later date outright, you won't solve the problem, you'll just make it worse.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The slip down memory lane
Jason L Tibbitts III wrote: > To me this implies that we should begin testing earlier (or, perhaps, > never stop testing) and treat any new failure as an event of > significance. It's tough to meet a six month cycle if we spend half of > it telling people to expect everything to be broken. We HAVE to accept that Rawhide is sometimes broken to be able to do active development. If we need Rawhide to be always 100% regression-free, we will never get anywhere. It's Rawhide for a reason. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The slip down memory lane
Nathaniel McCallum wrote: > I disagree, the feature is shipping on time. Shipping on time enables > others in the Fedora community (people who build on, deploy, etc) know > with some assurance what their schedules will look like. If I were a > project manager looking at using a Linux OS in my project, a > demonstrated lack of ability to ship on time is a *huge* mark against > using that OS. If you need a schedule you can depend on, just add 2-3 weeks to the official schedule. Maybe even a month, waiting for the first sets of updates can't hurt anyway, they tend to fix a lot of bugs. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The slip down memory lane
Will Woods wrote: > This is a good point, and it's one of the reasons the 'critpath' stuff > exists. It's the same concept, applied somewhat differently: rather than > freeze the 'CoreOS' stuff earlier, we freeze it harder - we require more > testing for those pieces. The problem is, "freezing harder" doesn't work, freezing earlier, on the other hand, MIGHT help, see e.g. the fallout from the incompatible change to ld rushed in the day of the F13 feature freeze, with both the feature owners and FESCo refusing to see any problem in that. That said, rather than a hard freeze, I'd like to see some risk-benefit analysis of the change. In the case of the incompatible ld change, the benefit was zero and the fallout was clearly visible, it's insane that this was considered a "feature" at all, but the ONLY time for such a "feature" is in Rawhide immediately after the branch (i.e. they could have put it into F14 instead of F13 at the same time, that would have been borderline acceptable, what they did was absolutely not!). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The slip down memory lane
drago01 wrote: > It isn't broken so there is nothing to fix; slipping to fix issues > found is a feature not a bug. > We don't have any reason to "rush". +1 Slips DO and WILL happen. It's just a matter of fact. It also happens in other projects. We just need to accept this. If we really want to meet specific target dates for the release, e.g. May/Nov 1, then we need to schedule at least 2 weeks EARLIER, i.e. officially schedule for Apr/Oct 15 and compute all deadlines accordingly. Then the inevitable slips will just do the rest. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Orcan Ogetbil wrote:
> The F-(x) package will have higher EVR than the F-(x+1) one. This
> will break the upgrade path. Is there any measures to prevent this?
No. In fact FESCo specifically refused to consider this as an issue, they
say separate releases need separate testing and so they refuse to accept the
Fn karma as grounds to push the Fn+1 update. No amount of arguing helped.
Such broken upgrade paths are now going to be extremely common with this
useless, broken and inflexible procedure.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Luke Macken wrote: > Ok, so the problem here is that bodhi unpushes updates when you edit > *anything* in it. If it only unpushed an updated when you add/remove > builds from it, then this scenario would be sane. There's still the "We've been testing a new KDE release for 2-3 weeks, now we need to edit in a one-line regression fix to one package of the huge group before pushing this to stable." scenario. This has been the case quite often. With your "fix", we'd have the choice between pushing the update with a known regression (yuck!!!) or waiting another full week (also quite a bad option). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The slip down memory lane
Nicolas Mailhot wrote: > So perhaps the delay between "invasive features autorized" and "alpha" > is too short. It's true that sometimes very invasive features have been rushed in right before the feature freeze, often irrespective of the (lack of) benefits (at least at their state of development at the time). In particular, I'm thinking of the incompatible change to ld which redefined decades-old ELF semantics, which broke the build of half of the distro and which was rushed in the day of F13's feature freeze. That said, there must also be ample time for invasive changes in Rawhide, Fedora can't be leading without the occasional breakage in Rawhide. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
List Troll wrote:
> If you have been *testing* it for 2-3 weeks surely you have no problem
> to find two testers to confirm the small fix?
This argument has been brought up all the time. The thing is, it takes time
to find people to +1 updates. It takes even longer if the people actually
test the updates before +1ing them (as they're expected to). This excessive
and useless QA adds delays over delays.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
I wrote: > This argument has been brought up all the time. The thing is, it takes > time to find people to +1 updates. It takes even longer if the people > actually test the updates before +1ing them (as they're expected to). This > excessive and useless QA adds delays over delays. But FWIW, when it comes to KDE in particular, the whole thing is moot or soon to be moot anyway because parts of KDE are now being redefined as "critical path", resulting in even more annoying update policies, even though there was clear consensus in KDE SIG that such policies are neither necessary for nor of any benefit to KDE. FESCo just asked us to come up with a list of critical KDE packages and shut up. So we did. (My proposal to submit an empty list was voted down in KDE SIG on the grounds of being against the spirit of what FESCo asked of us, even though it did get some support due to our objections to the critical path process as a whole.) We (KDE SIG) have been more or less forced to participate in a process most of us (and me in particular) do not agree with and consider outright harmful. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
I wrote: > But FWIW, when it comes to KDE in particular, the whole thing is moot or > soon to be moot anyway because parts of KDE are now being redefined as > "critical path", resulting in even more annoying update policies, even > though there was clear consensus in KDE SIG that such policies are neither > necessary for nor of any benefit to KDE. FESCo just asked us to come up > with a list of critical KDE packages and shut up. So we did. (My proposal > to submit an empty list was voted down in KDE SIG on the grounds of being > against the spirit of what FESCo asked of us, even though it did get some > support due to our objections to the critical path process as a whole.) We > (KDE SIG) have been more or less forced to participate in a process most > of us (and me in particular) do not agree with and consider outright > harmful. PS: 1. The critical path update rules (and thus also the clause in the general update rules which references them) were initially defined as requiring only 1 proventester to approve. (This was left somewhat vague in the actual policy, but 1 proventester was what was mentioned in all the discussion inside FESCo.) This was modified to 1 proventester + 1 other tester to match existing practice for freezes (the Critical Path Policy implemented as part of No Frozen Rawhide). FESCo never actually voted to approve that change, it was single-handedly made in the wiki by one person. This makes this policy much more of a PITA than it could have been. It also shows that we aren't even trusting PROVEN testers to reliably test a package! This is really ridiculous! 2. FESCo also rejected an amendment I suggested to make sure that the proventesters group should include at least one member of each of the main 4 desktops' SIGs. And in fact, no KDE SIG member was included in the initial proventesters seed, despite Rex Dieter: (i) having applied WEEKS before the proventesters group was seeded and (ii) having YEARS of experience with approving freeze overrides, as he had been processing freeze override requests all over the years in the old rel- eng-Trac-ticket-based process. This really hurts the abilities of SIGs to self-organize, instead promoting a kind of centralized power distribution which just does not scale to our evergrowing distribution. If you want KDE to be considered critical path, you also have to allow KDE people to approve critical path packages. (In fact, I think we actually need much more than one KDE proventester in the long run.) And likewise for XFCE and LXDE. IMHO, FESCo should be abolished, Fedora needs to be ruled by the SIGs! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!
Bruno Wolff III wrote: > We'll until Lougher writes something that Linus will accept, we need to > wait. But WHY? IMHO, an upstream tarball is just a base to apply our patches onto. We shouldn't be prisoners of upstream, especially when upstream processes are just too slow to fit our needs. Backporting, sometimes from more or less unofficial development branches, is a required part of being on the leading edge. We cannot be "First" with a religious adhesion to upstream. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Chris Adams wrote: > Why are you here? All you do is shout about how everything that is done > is done wrong, and how you wanted to do it different but were out-voted. > Why don't you go start your own distribution? If you are right, then > you should have no trouble getting a large group of developers, > producing an awesome OS, and then you can prove FESCo wrong. Are you providing the infrastructure? A distribution needs a lot of infrastructure, not just manpower. (And getting existing contributors to move to a new distribution is also not going to happen overnight, even if it's clearly better. But that's moot in the absence of infrastructure anyway.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!
Chris Ball wrote: > This should be unsurprising, because the stated objectives of the > Fedora project as a whole don't agree with you either: > > http://fedoraproject.org/wiki/Objectives > http://fedoraproject.org/wiki/Staying_close_to_upstream_projects Those same objectives say that Fedora should "be on the leading edge of free and open source technology". To me, this includes shipping a great new technology such as LZMA SquashFS, without waiting for the upstream kernel. "Staying close to upstream projects" isn't without exceptions either. In addition, another objective of Fedora is to "include a wide range of packages", so we should support technologies which allow us to ship more packages on our live images. Basically, we're missing out on an important new feature and shipping less featureful live images than we could for purely political reasons. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!
Jesse Keating wrote: > Do you have any sort of proof that it's a "political" reason? It would > seem to me that our kernel maintainers do not wish to include code that > hasn't been blessed by Linus in our packages. That's political. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Staying close to upstream"
Jesse Keating wrote: > You're making an assumption here that it's the trademarks that prevent > any deviation from upstream, when in fact the maintainer has stated many > times that regardless of trademarks, he would not deviate from upstream > given the sensitivity of a software suite that has to connect to the > wild wild web. The maintenance burden of upstream deviation is greater > than the maintainer would like to undertake, as is the risk of security > issues and stability. But the end effect is: * Firefox, Thunderbird and xulrunner are the ONLY packages in the whole Fedora which are NOT open to provenpackager! (The reason given: trademarks.) IMHO this shows that the exception process which allows closing packages to provenpackager is useless and needs to be abolished, the problem is with those particular packages. * This policy of sticking religiously to upstream means we are not shipping KDE integration for Firefox, despite patches from openSUSE existing. This makes Firefox suck under KDE. Our Firefox maintainers refuse to do anything about it. In addition, trademarks are often given as one of the reasons they stick so closely to upstream when we complain about that, by the very same maintainers who then claim it's not about trademarks when we want to get the trademarks removed. Their position is not consistent: if we ask for non- upstream changes, they say the trademarks forbid them so they can't do anything, if we ask for getting the trademarks removed, they say that it wouldn't change anything anyway. Either they're just using the trademarks as an excuse for their laziness, or the trademarks are the problem and need to be removed, it's one or the other. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!
Chris Adams wrote:
> Why don't you give the kernel maintainers the same courtesy?
Because LZMA SquashFS is a feature which affects the live images, and almost
exclusively the live images, and as such the SIGs controlling the live
images should be the ones making the decision. This means the 4 desktop
SIGs. (And FWIW, GNOME really needs a community-oriented SIG instead of the
current "RH Desktop Team == Fedora GNOME maintainers" practice.)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The slip down memory lane
Mike McGrath wrote: > I'll admit, this is a convenient view to have. The problem is we're not > in high school anymore. We're professionals. We're expected to set and > keep schedules because people besides ourselves rely on those schedules. > There are other distros that set and keep schedules better then we do.. > probably all of them. I'm just saying with proper planning it's possible. Huh? Name a distro which never has 1-2 week slips. Even Ubuntu with all its "reliable schedules" talk sometimes slips. The reason you don't notice is that they schedule for early in the month, so when they slip, it's still the same month and their y.mm versioning scheme still works. But one LTS release (Dapper Drake in 2006) has been made a .06 release rather than .04, that's 2 months added to a 6 months schedule, and that was not the original schedule! So in some sense it was a 2-month slip! And Debian even routinely slips for months. As for RHEL, RH keeps its schedules secret until the very last moment, and rumors are the original schedule for RHEL 6 was already not met and it's still not out (but since I don't work for RH, I can't attest to the truthfulness of those rumors, and I guess those who theoretically could aren't allowed to comment on it). You have to choose between timeliness or quality. I'll take quality any day (as long as it doesn't get ridiculous like Debian's ages-long slips), thank you very much! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Jaroslav Reznik wrote: > Then we have to push broken updates, policy says so and it's ok, so let's > do it > :( A policy requiring us to push something broken is broken. I'm not going to push broken shit. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What does the DVD media check if installing a new Fedora version? / Proposal
Joachim Backes wrote:
> having the following question: What does the DVD/CD media check exactly
> if booting a Fedora DVD/CD? Is it the sha256sum? If yes, why this media
> check, because it could be done after having burned the DVD?
You can already do this in K3b, there's a box you can check to verify the
burned stuff. (If I'm not mistaken, it actually does a bytewise compare
these days, not a checksum.)
You can also run sha256sum /dev/cdrom and compare the result with the
published checksums.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Staying close to upstream"
Rahul Sundaram wrote: > You seem to refuse to accept that Firefox maintainers in Fedora don't want > the KDE patches without it getting upstream. Firefox is one of the > frequently updated software and non-upstream patches create a burden. Why > aren't the patches upstream? You are fighting in the wrong place. The > maintainers decision in this matter is final. Please accept the > difference of opinion and move on. Repeating your opinions over and over > again changes nothing. But applying KDE integration patches should be a KDE SIG matter, the individual package maintainers should have to comply with KDE SIG decisions on the matter. How can we offer an integrated desktop experience when individual maintainers refuse to work with us, and FESCo only makes our work harder with useless bureaucratic policies instead of helping us achieve our goals in a way coordinated throughout the distribution? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Ralf Corsepius wrote: >>> I think, for packages that are modified during the testing period, >>> this N should be calculated from the day the last push was made to >>> testing. > > This would very unhelpful. > >> Yes, this was my initial intention. However, looking at the code a bit >> closer, your scenario would currently be allowed, as it currently only >> calculates the time-in-testing based on the first push to testing. > This behavior is helpful, because otherwise updates would "starve". +1 Once again, we're in violent agreement! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Rahul Sundaram wrote:
> I expect more fine tuning will be needed for these changes but thanks for
> all your work on this.
No thanks from me. By implementing FESCo's diktats defying common sense, you
broken updates for everyone.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Jaroslav Reznik wrote: > It would hurt all sides - it would hurt Fedora, the new distribution, our > work in Red Hat, users and so on. And I don't understand why we can't work > under one roof - to make Fedora the best OS. Maybe more autonomy for SIGs > could help as Kevin proposed? Yeah, the SIGs are the ones who do the actual work, FESCo and the Board are just political bureaucrats. Proper meritocracy means the SIGs get to decide. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 14 Alpha RC3 Available Now!
Rahul Sundaram wrote: > Sorry but no. There is only one kernel for the entire distribution and I > rather rely on kernel maintainers expertise on their packages rather than > SIG's trying to dictate what patches the kernel should carry. The SIG > participants are not kernel developers. But sometimes the maintainers of individual package maintainers have to cave in to allow for a coordinated distribution experience. That's why we are a distribution and not a bunch of packages thrown together. > If non upstream patches is needed, it requires someone to take ownership > of keeping the patches updated for the kernel updates. If you are > volunteering to do that work, please talk to the kernel developers. I would, but my experience is that they'll probably say "no" anyway. I know it has been offered in the past, for various out-of-tree patches and kernel modules, they only accepted it in very few cases (e.g. for Hans de Goede's webcam driver stuff because he also worked on getting the stuff merged upstream, not just into Fedora; but it's far from easy for somebody who's not already an experienced upstream kernel developer to manage that, LKML is a tough place: there's politics making it hard for new contributors to get their stuff in, there are many rules (technical, cosmetic (i.e. code formatting rules), and social) you have to learn over the time, and the kernel is also a hard codebase to work with in the first place; it's a lot easier to regularly rebase a patch than to make it palatable to upstream, that's why there are so many out-of-tree patchsets). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Staying close to upstream"
Chris Tyler wrote: > If you (or whoever is interested) can't get those patches through the > upstream review process for technical reasons, then perhaps they're ugly > patches. If you can't get them through because of lack of > time/energy/motivation, then the future maintenance of those patches is > in question. Either way, it strengthens our Firefox maintainers' > position that those patches shouldn't be accepted. You forget the sociopolitical aspect: in many upstreams (and AFAICS Mozilla is one of those), you can only get your stuff merged if you know the right people. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
