Re: F29 System Wide Change: i686 Is For x86-64
On Monday, June 4, 2018, 4:35:34 AM, Jan Kurik wrote: > = Proposed System Wide Change: i686 Is For x86-64 = > https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64 > Owner(s): > * Florian Weimer > Fedora builds its i686 packages for use on x86-64 systems as multi-lib RPMs. > == Detailed description == > Currently, the i686 RPM packages are built in such a way that they are > compatible with very old i686 systems, such as the Pentium III. The > only addition over the i686/Pentium Pro baseline is a requirement to > support long NOPs, for Intel CET. However, the majority of > installations of i686 packages is for use on x86_64 systems, as > multi-lib RPMs. Furthermore, there are reports that the i686 kernel > does not run stable on old hardware which is not x86-64-capable ( > https://lists.fedoraproject.org/archives/list/x...@lists.fedoraproject.org/thread/ZHV6I4IEO7GRYAZ4TUMO5VH2ZHLCNJZQ/ > ). > This proposal suggests to accept this reality and build the i686 > packages in such a way that they require the ISA level of (early) > x86-64 CPUs. > == Scope == > * Proposal owners: > Adjust the redhat-rpm-config, gcc, and glibc packages to switch to the > new compiler flags. Except for mstackrealign, there is substantial > experience with this configuration downstream. > * Other developers: > Other developers can enable SSE2 optimization in their packages if > they want, where this has been a compile-time option only. > * Release engineering: > https://pagure.io/releng/issues/7543 #7543 > ** List of deliverables: TBD > * Policies and guidelines: > i686 is no longer a primary architecture. The Packaging Guidelines do > not currently require support for non-SSE2 x86 systems, so no change > is required there. I think this change is fundamentally wrong. If you have the 64-bit capable hardware, should not the focus be on the X84-64 modules? The 32-bit modules are targeted to an entirely different audience, who have already decided to take a performance hit by running in 32-bit mode. Requiring 64-bit hardware to run the 32-bit modules does not simply impact the i686 secondary architecture - it fundamentally breaks it. I don't see this change as being reasonable unless the i686 secondary arch is going to get a full parallel build to support i686 hardware. I don't see that happening either. Al ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/X5MHFHEHQISB2YJBENM6JB3UUDPRJBSM/
Re: Fedora 19 End of Life
On Tuesday, January 6, 2015, 11:25:19 AM, Josh Boyer wrote: > On Tue, Jan 6, 2015 at 11:17 AM, Kevin Fenzi wrote: >> As of 6th of January 2014, Fedora 19 has reached its end of life for >> updates and support. > Yay! > Does this mean Schrödinger's cat is actually dead? > josh Wulf's looked better. (Obligatory Dilbert reference: http://holyjoe.org/poetry/adams.htm) PS: Does end-of-life really matter unless you open the box? http://i0.kym-cdn.com/photos/images/newsfeed/000/346/647/dfd.png -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Announcing the release of Fedora 21 Beta!
On Tuesday, November 4, 2014, 6:01:35 PM, Robert Mayz wrote: >2014-11-04 23:55 GMT+01:00 Al Dunsmuir : >On Tuesday, November 4, 2014, 10:01:02 AM, Dennis Gilmore wrote: >> The Fedora 21 beta release is here, and - as usual - is packed >> with amazing improvements to Fedora, as well as fantastic free >> and open source software, gently harvested for your enjoyment. No >> bits were harmed in the making of this beta. >> * * * >> Spins >> - - >> In addition to the new Fedora products, Fedora users also have >> the choice of Fedora Spins that highlight user favorites like KDE >> Plasma Workspaces, Xfce, LXDE, and Sugar on a Stick (SoaS). If >> you're interested in trying out one of the spins, head over to >> the prelease page for Fedora Spins and grab the spins you're >> interested in: >> http://fedoraproject.org/get-spin-prerelease >>The Mate_Compiz spin is on the mirrors. Is there a reason it was >>omitted from the spins shown on this web page? >I've re-added it right now, thank you for reporting that. It should >be on the spins page in about 30 minutes or so. Excellent - thanks for the timely response! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Announcing the release of Fedora 21 Beta!
. On Tuesday, November 4, 2014, 10:01:02 AM, Dennis Gilmore wrote: > The Fedora 21 beta release is here, and - as usual - is packed > with amazing improvements to Fedora, as well as fantastic free > and open source software, gently harvested for your enjoyment. No > bits were harmed in the making of this beta. * * * > Spins > - - > In addition to the new Fedora products, Fedora users also have > the choice of Fedora Spins that highlight user favorites like KDE > Plasma Workspaces, Xfce, LXDE, and Sugar on a Stick (SoaS). If > you're interested in trying out one of the spins, head over to > the prelease page for Fedora Spins and grab the spins you're > interested in: > http://fedoraproject.org/get-spin-prerelease The Mate_Compiz spin is on the mirrors. Is there a reason it was omitted from the spins shown on this web page? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Self Introduction: Al Dunsmuir
Greetings! I've been a Fedora user since Fedora Core 3, but now I'm starting the move to the next level - becoming a Fedora packager. I'm interested in vintage hardware, especially older ATI/Radeon video, and PPC (Macs & IBM). I'm hoping to contribute to Fedora development in a couple of areas: - Helping out in the PPC secondary architecture, including active development as I get up to speed. PPC64 started down the path to have grub2 as the bootloader in F18. As of F20, for Mac G5s grub2 is the stage 1 bootloader, and yaboot is still the stage 2 bootloader. The transition was incomplete, and the F20 GA isos do not boot on Macs. An alternate iso (mod'd F20 alpha by Eric Larsson) and some manual fixups are required. I've noted on irc that Paulo Flabiano Smorigo (pfsmorigo) is currently working on more grub2 boot updates for F21. Things get complicated: - The yaboot package is currently orphaned in rawhide/F21. - Both grub2 and yaboot only build 32-bit, even when booting ppc64. - The ppc32 architecture builds are no more in Rawhide/F21. The consensus is that a full ppc32 Fedora is not practical. To fill that gap, I plan to create a ppc32 remix of F21 (core packages) once I get up to speed - tentative name: PPChapeau (chapeau is French for Hat). I plan to support G4 Macs and 32-bit CHRP IBM Power - I have 2 7046-B50s that dual-boot AIX (5.1). The PS3 (ppc64) and all ppc32 currently depend on yaboot. With that and a possible continuing Mac G5 stage 2 dependency, I'm going to pick up ownership of yaboot as my first package. Jon Disnard (masta) is going to sponsor me as a packager. He just happens to be a PS3 (Linux) owner, and I will be his first sponsorship - please be kind to both of us! Fedora dropped ppc32 installs in F18, and has not had live CD/DVDs for either ppc architecture since F8. This makes doing development (especially testing and debugging) of boot, and graphics issues much more difficult. I plan to work on getting the live installs running again for ppc64 for Rawhide and the F21 release (as a private download). I would base it on the Mate spin, to accommodate the types of video that one would encounter on vintage ppc machines such as Macs. I would use that as a basis for my ppc32 remix. I'm a C/C++/shell programmer of many years. Earlier in my career I worked at IBM for 23 years (in hardware test, debuggers, and the mainframe C/C++ compiler. At one point, I was _very_ familiar with elf, dwarf and IEEE floating point (mainframe and AIX ppc). I now work at RBC (Royal Bank of Canada) on a secure data transport server on z/OS (C and assembler), and some AIX code. As a side work project, I'm doing updated ports of some OSS packages (including current rpm) to AIX. I'm also the InfoZIP Zip/Unzip port maintainer for z/OS and z/VM - RBC has kindly granted me use of systems plus relevant code I've developed for my main project (it's nice not to work for a software vendor, from that point of view). I but need to complete the Fedora Packager process. I'll be focusing on getting up to speed on Fedora packaging and how the whole boot process, kernel, X and Mesa work together plus other plumbing. Learning Python is on my to-do list. I'd like to gain enough knowledge to eventually contribute fixes and new code. - Testing X11 & Mesa support for these graphics cards (and other vintage type) on x686, X86_64, ppc64, and ppc32. I've got a lot of different generations of ATI video cards... and I'm not afraid to use them 8^). I've also got a few Matrox MGA cards (x86 and ppc), but I am a wee bit afraid of those - they will require developing a new KMS with at least a wee bit of acceleration, now that the User Mode drivers are no longer supported. Thank you for your patience with this rather long note... and also my thanks to all of the existing (and past) contributors to Fedora (and Linux in general)! Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Make buildSRPMFromSCM faster?
On Saturday, July 19, 2014, 8:20:30 PM, Eric Smith wrote: > On Sat, Jul 19, 2014 at 7:26 AM, Richard Shaw wrote: >> How about not rebuilding the chroot every time... It's not like you have to >> worry about leftover BR's from building another package. > That could lead to packages that happen to build some of the time due > to an undetected dependency on something that isn't in the BR but > happens to be in a cached buildroot. Then you would at least get failure or a working package. Just because a package builds without failure doesn't mean it is the intended build. A less desirable case would be a package with optional build dependencies, that gets built with different configurations based on the presence of extra packages that happen to be in that cached buildroot. Having the required packages for build and no more is important. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Fedora 22 Change proposal: systemd-sysusers
On Wednesday, July 9, 2014, 1:24:12 PM, Reindl Harald wrote: > Am 09.07.2014 19:18, schrieb Chris Adams: >> Once upon a time, Lennart Poettering said: >> Please, no! As soon as you use disparate systems in a network >> environment, having differing versions of UID_MIN (where recompilation >> is required to change) is just wrong. As the message above sys, "yes, >> that is actually used and needed". I see no valid justification for >> removing that functionality > +1 > UID_MIN 500 > UID_MAX 6 > GID_MIN 500 > GID_MAX 6 > still here in use and that won't change > if somebody enforces to change that at compile time he don't > care for any production setups not re-installed every year > and decides to break things just for fun The boundary between system and user IDs moved from 500 to 1000 relatively recently (F18). Aside from giving more room for system IDs, this had the side effect of hiding IDs from 500 to 999 that were created by older Fedora releases from the GDM logon panel. User IDs had to be moved above 999 to be visible again. It was a bit of a painful transition. Does this mean the system headers were not updated to match? Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Monday, June 9, 2014, 12:08:13 PM, Richard Jones wrote: > On Sun, Jun 08, 2014 at 09:18:12PM -0500, Dennis Gilmore wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On Mon, 9 Jun 2014 00:01:34 +0100 >> "Richard W.M. Jones" wrote: >> >> > On Mon, Jun 02, 2014 at 04:36:28PM -0400, Al Dunsmuir wrote: >> > > On Monday, June 2, 2014, 2:53:33 PM, Till Mass wrote: >> > > > On Mon, Jun 02, 2014 at 11:01:53AM +0200, Dan Horák wrote: >> > > >> On Sun, 1 Jun 2014 11:24:09 +0200 >> > > >> Till Maas wrote: >> > > >> > > >> > yaboot dwmw2, dwmw2, fkocina, >> > > >> >> > > >> this is a secondary arch only package since F-12, so it should be >> > > >> excluded from the FTBFS list in primary koji >> > > >> > > > Actually according to Dennis this is a ppc32 package that can be >> > > > retired, because ppc32 support is being dropped. >> > > >> > > Till, >> > > >> > > Please do not start deleting ppc32-only packages. >> > > >> > > A few of us would like to resurrect ppc32, likely initially >> > > as a Fedora Remix. Deleting ppc32-only packages just adds >> > > more work to that effort. >> > >> > Plus yaboot is still needed to boot ppc64 Macs, even on F20/F21. >> >> no it doesn't that part of why ppc is no longer built at all. f20 uses >> yaboot for dvd and grub2 for the installed system, f21 is using grub2 >> everywhere. > I have a Fedora 20 ppc64 Mac right next to my feet here that is > definitely booting using yaboot. > Rich. The intent appears to have been to eliminate yaboot for F20 ppc64, but the implementation did not go smoothly. There were residual references to yaboot in the configuration created by Anaconda, that can even leave the resulting system in limbo. See https://bugzilla.redhat.com/show_bug.cgi?id=876625 and https://bugzilla.redhat.com/show_bug.cgi?id=1020112 I've had no luck getting a PowerMac G5 (Radeon 9600) install to complete with either F20 ppc DVD or Netboot, or the RHEL7 ppc64 RC. This makes looking at problems like the FTBFS for hfsplus-tools a tad problematic. I'd really like to get a local working Rawhide Live-DVD build running, since there are no current ppc64 (or ppc) Live-DVD spins or updated F20 install media. Al > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-p2v converts physical machines to virtual machines. Boot with a > live CD or over the network (PXE) and turn machines into KVM guests. > http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Tuesday, June 3, 2014, 2:37:49 AM, Dan Horák wrote: > On Mon, 2 Jun 2014 23:54:10 +0200 > Till Maas wrote: >> On Mon, Jun 02, 2014 at 04:36:28PM -0400, Al Dunsmuir wrote: >> >> > Please do not start deleting ppc32-only packages. >> > >> > A few of us would like to resurrect ppc32, likely initially >> > as a Fedora Remix. Deleting ppc32-only packages just adds >> > more work to that effort. >> >> ok, but I guess there is no package left that is not properly >> configured in primary koji. If you continue with this effort, please >> re-open the rel-eng ticket in my other e-mail regarding yaboot. > In the past it wasn't possible to block secondary arch only package in > primary koji after it was introduced there, because during some releng > action (branching, mass rebuild?) it affected also the secondary koji. > Or pkgdb, maybe both. The result was that secondary arch only package > was not accessible for commits and blocked in secondary koji and we > had to resolve it manually with dgilmore. So please be careful. I think > the problem was that pkgdb had no information about arches, it worked > globally. Thanks for the heads-up! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Monday, June 2, 2014, 5:54:10 PM, Till Mass wrote: > On Mon, Jun 02, 2014 at 04:36:28PM -0400, Al Dunsmuir wrote: >> Please do not start deleting ppc32-only packages. >> >> A few of us would like to resurrect ppc32, likely initially as a >> Fedora Remix. Deleting ppc32-only packages just adds more work >> to that effort. > ok, but I guess there is no package left that is not properly configured > in primary koji. If you continue with this effort, please re-open the > rel-eng ticket in my other e-mail regarding yaboot. Thanks - will do. The intent is to switch ppc32 over to grub2 once basic install is operational. F20 ppc64 GA made the switch, but it was not without trials - see https://bugzilla.redhat.com/show_bug.cgi?id=1020112 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ACTION REQUIRED] Retiring packages for Fedora 21
On Monday, June 2, 2014, 5:15:18 PM, Adam Jackson wrote: > On Mon, 2014-06-02 at 16:52 -0400, Al Dunsmuir wrote: >> On Monday, June 2, 2014, 10:05:22 AM, Adam Jackson wrote: >> > On Sat, 2014-05-31 at 10:33 -0400, Al Dunsmuir wrote: >> >> Is the mga450 supported? Aside from formal graphics test days, I can >> >> run whatever tests required on x86 (both 32-bit and 64-bit). >> >> > Define "supported". I believe for PowerPC in RHEL we build the matroxfb >> > driver for this card, so that plus the fbdev driver for X is what you >> > get there. I'm not sure what would happen on Fedora for that, probably >> > aligning it with RHEL makes sense. On x86 you'd get vesa. >> >> Assuming there are no down-sides of aligning Fedora and RHEL in this >> area, it would be appreciated. Do you need a BZ to do this? > Appears to be thus already actually, so no bug needed. Excellent! Thanks for checking. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ACTION REQUIRED] Retiring packages for Fedora 21
On Monday, June 2, 2014, 10:05:22 AM, Adam Jackson wrote: > On Sat, 2014-05-31 at 10:33 -0400, Al Dunsmuir wrote: >> Is the mga450 supported? Aside from formal graphics test days, I can >> run whatever tests required on x86 (both 32-bit and 64-bit). > Define "supported". I believe for PowerPC in RHEL we build the matroxfb > driver for this card, so that plus the fbdev driver for X is what you > get there. I'm not sure what would happen on Fedora for that, probably > aligning it with RHEL makes sense. On x86 you'd get vesa. Assuming there are no down-sides of aligning Fedora and RHEL in this area, it would be appreciated. Do you need a BZ to do this? > But in any of those cases there's no acceleration code involved, so > "supported" could reaally only mean "lights up and sets modes". Light is good. For the lower-functionality desktops, it is enough. The IBM AIX GXT135 driver documents a switch to enable minimally acceleration, but does not describe any details. Even without that enabled, it is usable under CDE. >> I've also got a GXT120 (OEM'd MY220P) and the identical x86 card. I'm >> not sure if that would be covered by "mgag200", but again, I can >> provide validation. > The mgag200 driver is, at the moment, only a driver for server variants > of the G200 (G200SE, G200WB, etc). Actual G200, as well as G400 G450 > and G550, are not driven by the mgag200 driver at this time. Thanks for the info, and your efforts! I can give them a try around alpha-time, and see what transpires. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Monday, June 2, 2014, 2:53:33 PM, Till Mass wrote: > On Mon, Jun 02, 2014 at 11:01:53AM +0200, Dan Horák wrote: >> On Sun, 1 Jun 2014 11:24:09 +0200 >> Till Maas wrote: >> > yaboot dwmw2, dwmw2, fkocina, >> >> this is a secondary arch only package since F-12, so it should be >> excluded from the FTBFS list in primary koji > Actually according to Dennis this is a ppc32 package that can be > retired, because ppc32 support is being dropped. Till, Please do not start deleting ppc32-only packages. A few of us would like to resurrect ppc32, likely initially as a Fedora Remix. Deleting ppc32-only packages just adds more work to that effort. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [ACTION REQUIRED] Retiring packages for Fedora 21
On Friday, May 30, 2014, 12:22:18 PM, Adam Jackson wrote: > On Thu, 2014-05-29 at 18:24 +0100, Richard W.M. Jones wrote: >> On Thu, May 29, 2014 at 03:43:49PM +0200, Till Maas wrote: >> Isn't this driver therefore required by this emulated card? Or does >> another driver do the job? > No and yes, respectively: . . . > The xorg-x11-drv-modesetting driver handles X support for KMS drivers > without userspace acceleration, which at the moment means ast, bochs, > cirrus, gma500, mgag200, and udl. Ajax, The GXT135 is the most common video adapter for pSeries, and is an OEM'd mga450. I've got two (in ppc 32-bit machines, which is now more of a long term challenge). I also now have two x86 equivalents for testing (a PCI G450 identical to the GXT135, and another AGP version). Is the mga450 supported? Aside from formal graphics test days, I can run whatever tests required on x86 (both 32-bit and 64-bit). I've also got a GXT120 (OEM'd MY220P) and the identical x86 card. I'm not sure if that would be covered by "mgag200", but again, I can provide validation. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Problems with Fedora ppc mailing list
On Thursday, May 15, 2014, 8:28:33 PM, I wrote: > Has anyone else noticed problems with the Fedora mailing lists today? > As of last night, I am not getting copied on my posts, but can see > them at > https://lists.fedoraproject.org/pipermail/ppc/2014-May/date.html > I tried checking my mail options, at > https://admin.fedoraproject.org/mailman/options/ppc > but got the following strange error. I have my own DNS, and it had > no issues resolving the address. > Thanks! > Al > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > 502 Proxy Error > The proxy server received an invalid response from an upstream server. > The proxy server could not handle the request POST /mailman/options/ppc. > Reason: DNS lookup failure for: collab03.fedoraproject.org This morning around 05:00 I received all of the missing emails, including posts from May 14th. Looks like someone fixed the issue. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fwd: git commit Undelivered Mail Returned to Sender
On Thursday, May 15, 2014, 12:42:25 AM, Orion Poplawski wrote: > More fallout from pkgdb2? I just send an email to this list about weird problems I have been experiencing with the ppc mailing list. When I tried to log on to check my options, I got a 502 proxy error about a DNS lookup failure for "collab03.fedoraproject.org". Coincidence? > Original Message > Subject: Undelivered Mail Returned to Sender > Date: Thu, 15 May 2014 04:38:59 + (UTC) > From: mailer-dae...@fedoraproject.org (Mail Delivery System) > To: or...@fedoraproject.org > This is the mail system at host pkgs01.phx2.fedoraproject.org. > I'm sorry to have to inform you that your message could not > be delivered to one or more recipients. It's attached below. > For further assistance, please send mail to postmaster. > If you do so, please include this problem report. You can > delete your own text from the attached returned message. >The mail system > : host bastion[10.5.126.12] said: 550 > 5.1.1 > : Recipient address rejected: User > unknown in local recipient table (in reply to RCPT TO command) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Problems with Fedora ppc mailing list
Has anyone else noticed problems with the Fedora mailing lists today? As of last night, I am not getting copied on my posts, but can see them at https://lists.fedoraproject.org/pipermail/ppc/2014-May/date.html I tried checking my mail options, at https://admin.fedoraproject.org/mailman/options/ppc but got the following strange error. I have my own DNS, and it had no issues resolving the address. Thanks! Al - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 502 Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request POST /mailman/options/ppc. Reason: DNS lookup failure for: collab03.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
On Tuesday 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote: > = Proposed System Wide Change: Default Local DNS Resolver = > https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver > > Change owner(s): P J P , Pavel Šimerda > , Tomas Hozza > > To install a local DNS resolver trusted for the DNSSEC validation running on > 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. On my home LAN, I run my own DNSSEC-enabled server using F20 & bind 9. This local server also is my DHCP and Samba server. As usual, dynamic clients receive the LAN local domain ID and DNS server ID automatically. How does this proposed change affect my clients, or especially my server (which uses NetworkManager (not Network), and a static IP address? As nice as unbound may be, documentation and configuration files related to this change should not assume it is the only DNS server for Fedora. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: rawhide report: 20140404 changes
On Friday, April 4, 2014, 1:42:49 PM, Matthew Milleru wrote: > On Fri, Apr 04, 2014 at 11:32:57AM -0600, Michal Jaegermann wrote: >> As far as I am concerned they are very useful. In more detail I am >> looking mostly at "Broken deps" and "Summaries", with only an occasional >> peek at a changelog information, but on a number of occasions these >> messages were crucial for me in disentangling broken dependencies on >> my rawhide installation and/or filing some packaging bugs. Without that >> information I would have a much harder time and either would add some >> spurious junk to bugzilla or would not bother at all. >> > They seem mostly to just raise the noise. >> As opposed to what? > As opposed to meaningful discussion generated intentionally by human > collaborators. But it appears that quite a few people do find them > beneficial, and that's all I was asking. Very beneficial. Knowing the state of Rawhide (based on changes, and what is known to be broken) seems like critical information for someone using or testing on Rawhide. Unfortunately, not all changes that affect other packages are announced in the fedora-announce list. Seeing replies to the "rawhide report" is usually a heads up that someone broke something. Putting these and other script-generated reports elsewhere just makes it harder for folks to keep track on what is happening. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: lbzip2 as default bzip2 implementation
On Wednesday, April 2, 2014, 2:03:38 PM, Bill Nottingham wrote: > Jaroslav Reznik (jrez...@redhat.com) said: >> = Proposed System Wide Change: lbzip2 as default bzip2 implementation = >> https://fedoraproject.org/wiki/Changes/lbzip2 >> >> Change owner(s): Mikolaj Izdebski >> >> This change aims at making lbzip2 [1] default bzip2 implementation used in >> Fedora. >> >> == Detailed Description == >> lbzip2 is an independent implementation of bzip2 compression tool. It >> provides >> interface strictly compatible with bzip2, but also adds several new features >> and improvements, such as: >> >> * multi-threaded operation for both compression and decompression, with >> almost >> linear scalability, >> * improved performance, even on single-core systems, >> * improved extra utilities (bzdiff, bzless, bzip2recover, etc.), >> * improved compatibility with gzip. >> >> lbzip2 is a mature project and it has been used in production for years. It >> is >> already packaged for Fedora and it is also available in EPEL. > A quick check shows lbzip2 doesn't provide a library interface, much less > one compatible with libbz2. Is that ever intended? > If it's not, saying lbzip2 is the default bzip2 *implementation* may be a > bit of a stretch. Perhaps s/implementation/command/. Bill, This clarification is significant. The change proposal text needs to be updated to reflect this. As long as the encoding is guaranteed to be byte-for-byte identical to that produced by the original bzip2 (and libbz2) implementation, the risks are lowered. Scenarios affected by this substitution are those with direct invocation of the command (from the command prompt, a shell script, or system() type call). The lbzip2 utility sounds interesting, and I am now disappointed that there is no separate library interface with these characteristics that we can investigate using instead of libbz2. As later comments state, perhaps in the future. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: lbzip2 as default bzip2 implementation
Hello Al, On Wednesday, April 2, 2014, 5:14:53 PM, Al Dunsmuir wrote: > On Wednesday, April 2, 2014, 4:27:55 PM, Zbigniew Jędrzejewski-Szmek wrote: >>> ** possibly adjust spec files to require or build-require lbzip2 instead of >>> bzip2. >> Is this necessary? Wouldn't it be better to have lbzip2 Provide bzip2 >> or something so that updating all those packages is not necessary, >> and also that people who prefer normal bzip2 can still use it? It's been a long day. In my haste to reply, I wrote "libzip" where I meant to say "lbzip2". The rest of my point remains unchanged. By the way, part of the reason for my slip is that while I have heard of a "libzip" library, I have never heard of lbzip2 before. I've never seen it come up with web searches related to the InfoZIP work to support bzip2 encoding. I'm going to post the original post and my comments in the private InfoZIP development list, but I suspect I will get responses that I am not the only person becoming aware of this new tool. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: lbzip2 as default bzip2 implementation
On Wednesday, April 2, 2014, 4:27:55 PM, Zbigniew Jędrzejewski-Szmek wrote: >> ** possibly adjust spec files to require or build-require lbzip2 instead of >> bzip2. > Is this necessary? Wouldn't it be better to have lbzip2 Provide bzip2 > or something so that updating all those packages is not necessary, > and also that people who prefer normal bzip2 can still use it? This sounds like a very intrusive change that in the worst case could introduce errors and expose user data to permanent loss without any means to recover. Many tools read and write zip files. The actual ZIP standard format is controlled by (coordinated by) PKZIP via their application note. There is a lot of discussion about common extensions, but each tool can have their own private extensions that may be incompatible. The InfoZIP team that gives you the zip and unzip tools has added support for the bzip2 and lzma compression and decompression algorithms, as well as AES encryption/decryption in their upcoming beta release. I've been involved in reworking U*IX build support, and working towards better support on mainframe platforms (z/OS, z/VM) and AIX. I do all my primary development and testing on Fedora, but others have their own preferred platform. This implementation has been built and extensively tested using the current release of the real bzip2 library. Substituting a completely different library implementation without going through extensive and explicit validating and testing is risky and unreasonable. At best, it would complicate problem reporting, reproduction, analysis and correction. The libzip effort is not part of the InfoZIP project. They may have created a wonderful library, but it will not have identical interfaces and behaviours as the original bzip2 library. Let the upstream tools decide which bzip implementation(s) to support, and do the necessary validation to ensure that it all works correctly. It is the upstream tool's reputation that would be damaged if the Fedora library caused user data to be lost. Let them do their job correctly. Final gloomy thought of the day: Breaking zip files could you are breaking the actual tool used for backups. That makes data loss a very permanent problem. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: Simply the retirement procedure - trigger on dead.package
On Wednesday, November 27, 2013, 2:30:23 PM, Ralph Bean wrote: > On Wed, Nov 27, 2013 at 07:46:28PM +0100, Till Maas wrote: >> On Wed, Nov 27, 2013 at 12:35:13PM -0600, Bruno Wolff III wrote: >> > On Wed, Nov 27, 2013 at 19:21:53 +0100, >> > Till Maas wrote: >> > > >> > >What are your opinions about this? I already checked with Dennis >> > >Gilmore, he is ok with this. >> > >> > Is there a fail against doing this in released versions? (Unless >> > there is a legal reason to do the retirement, we wouldn't want to do >> > that for a package in a release.) >> >> It will be done only for Rawhide and Branched (until the Final Change >> Deadline) and maybe EPEL if desired. Wether or not to e.g. retire >> packages for other releases without blocking them in Koji needs to be >> decided. >> >> Regards >> Till > Sounds like a good idea to me. Also seems like it is important enough > to run inside the infrastructure environment so that it can be > monitored. > The #fedora-apps team has been working on pkgdb2 which the authors > hope to deploy shortly after the F20 release. Restricting retirement > rights to the automated process shouldn't be a problem. What about un-retirement? It is critical that administrators be able to handle this side of the packaging process, even after a release has been branched. Ideally, if that could be just as fast. I would suggest triggering this on the _removal_ of the dead.package file in git, which perhaps would require proven-packager authority vs simply package ownership. This would make it a lightweigth process to handle resurrection of oprhaned and retired package or in case an error occurs. This would be especially useful if a large number of packages were accidentally retired. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Graphics driver support in F21+
On Monday, October 28, 2013, 10:07:05 PM, I began... I left IBM in 2002. Since then, I have joined RBC, and spend my days developing a mainframe file/data server (written in C and assembler - about 250 KLOC) and a few bits and pieces on AIX. I'm still a quite active coder, just not so much hardware oriented. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Owner-change] Fedora packages ownership change
On Monday, October 28,2013, 6:00:07 AM, the owner-change drone spake: > Change in ownership over the last 168 hours > === > 23 packages were orphaned > - > . . . > xorg-x11-drv-r128 [devel] was orphaned by jwboyer > Xorg X11 r128 video driver > https://admin.fedoraproject.org/pkgdb/acls/name/xorg-x11-drv-r128 > . . . > xorg-x11-drv-mach64 [devel] was orphaned by jwboyer > Xorg X11 mach64 video driver > . . . > Sources: https://github.com/pypingou/fedora-owner-change Please see my reply to Ajax's "Re: Graphics driver support in F21+" post. I am starting the process of becoming a Fedora packager, with the intent of picking of ownership of these two packages (and helping out with R100, R200, R300 and early R600 Radeon. I am not currently a Fedora packager, so will I would need someone to volunteer to be my sponsor. Enough time spent on the sidelines... Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Graphics driver support in F21+
On Thursday, October 24, 2013, 4:41:09 PM, Adam Jackson wrote: > On Tue, 2013-08-27 at 10:46 -0400, Adam Jackson wrote: >> For F21, I plan to orphan the following X video drivers: >> ... >> xorg-x11-drv-mach64 >> xorg-x11-drv-r128 >> ... > These have now been orphaned. I would like to volunteer to pick up ownership of these two packages. I would also like to assist with the F21 Radeon graphics test day. I will need someone in turn to volunteer to be my sponsor since I am not (yet) a Fedora packager. Later this week, I will start the full "How to get sponsored into the packager group" process. I've been experiencing difficulties with a R300-family laptop since Fedora 17 (worked great with Gnome 3 at GA, then regressed, then back to working near F17 EOL). Fedora 18 and 19 did not work, and I've been forced to use Mate. It comes as no surprise that with limited resources (time, hardware, or interest) the current developers were not able to investigate my bugzilla entry. I had decided in early summer that I would be best served to investigate deeper myself. I figured that a good place to start would be verification. I've been gathering the necessary resources to test the older Radeon releases (originally R100, R200, R300, and early R600) and it grew into covering the original ATI Mach64 and R128 ranges too. Between discrete video cards, a few laptops, integrated GPUs and APUs I can now test approximately 30 different Radeon, R128 and Mach 64 video configurations. I am finishing setup of dedicated test hardware for AGP (1X,2X,4X,8X), PCI-E (and naturally PCI). To cover non-x86/x64, I've also got an Apple G5 with AGP 8X Radeon 9650. For display, aside from the usual full and wide screen LCDs, I picked up a Samsung CRT to ensure that side is covered. This is while also covering the usual real life (work, plus I've been busy all summer doing renovations to my mother-in-law's townhouse (drywall, and some significant rewiring). I can see the light at the end of that tunnel now, and look forward to some time of my own to learn and play. 8^) While my original intent was to contribute primarily as a tester, I do have a hardware and software background that I hope I can grow to active support and development. Given time I would like to migrate these over to using KMS. Provided that goes well, the next goal would be to learn OpenGL basics and get up to speed by fixing some mesa issues I have with R300, R200, and R100. Beyond that, the goal would proper mach64 and R128 mesa drivers that would be suitable for reintegration (vs. the obsolete drivers that were removed in Dec 2012). Al PS: My EE bachelor's final project (in 1979... sigh) was a S-100 bus video card with text and overlaid grayscale bit graphics. I initially worked at IBM on hardware testing of memory, PC and integrated displays before moving on to mainframe debuggers and the C/C++ compiler group. It's been a while, but I'm hoping that some of that will still prove relevant and useful. 8^) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: intel ipw2100/ipw2200 firmware must be removed
On Saturday, July 14, 2012, 7:25:15 PM, Eric Smith wrote: > Kevin Fenzi wrote: >> See: >> http://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Binary_Firmware > Ralf Ertzinger wrote: >> Question about that: The first requirement is that the file is >> non-executable. Does that mean that Fedora cannot ship firmware for >> hardware that has a CPU compatible with the host CPU? > If it does mean that, it will be a problem for the ARM architecture, as > many hardware devices using downloaded firmware use ARM cores. > The specific statement is: > "The files are non-executable (note: this means that the files > cannot run on their own, not that they are just chmod -x)" > I'm not sure what it means for files to "run on their own". I don't > think I have a single file on any of my computers that can run on its > own. As far as I can see, even the Linux kernel cannot run on its own. > Perhaps it means that the file can't be in a supported executable format > such as ELF? Downloaded firmware often is in raw binary format, but > it's certainly conceivable that some might be in ELF format. This topic has come up at regular intervals in the past, especially when the kernel interfaces for downloading firmware were being developed. The packaging statement is meant to clarify, and to be read literally. It means that the program is not a stand-alone program for use by the host computer. It requires additional hardware to operate. It is marked non-executable "-x" to prevent attempts to execute by the host computer (or for the security conscious, attempts to disguise malware as firmware). Normally firmware is a binary blob that is downloaded by the kernel to that hardware, and used in some manner by that hardware, It may be a program (code/data) executed by a CPU (or equivalent such as an ASIC) or some form of data required for execution of that hardware. It may be multiple of each, in a fancy wrapper scheme with CRCs. Delivering firmware via a standard kernel API was a big change a few years ago. It allowed standard packaging of firmware, and eliminated the need for users to do nasty things like use programs the cut the firmware images out of Windows PE executables downloaded from chip/card vendor websites. The encoding doesn't matter - what matters is that the content is automatically delivered to the hardware so that hardware can operate. What also matters is that the licence allow Fedora to freely distribute the firmware file, without silly restrictions such as "non-commercial use only". Some folks object to Fedora shipping binary blobs, and insist that the only true way is to ship everything with source and build tools. That has been debated fiercely in the past... and the current rules were the IMO reasonable compromise that resulted. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17, firewalld, avahi
On Tuesday, April 17, 2012, 4:15:53 PM, Chris Murphy wrote: > On Apr 17, 2012, at 1:49 PM, Andreas Tunek wrote: >> I do not see anything in the f17 feature page describing any graphical >> configuration tool. But I also agree that gui configuratio is needed, >> otherwise it will probably be really difficult to do things like connect >> via ssh or share via rygel or other dlna server. > http://fedoraproject.org/wiki/FirewallD#Graphical_Configuration_Tool > "firewall-config is the main configuration tool" It also says "is"... but in spite of the use of the present tense, that tool is not available on the Fedora 17 Beta.? This begs the questions: - Is it currently available for installation and testing with the beta? - Will it be available for the Fedora 17 GA? - Will firewall-config be reasonably well tested by GA? - What confidence does Fesco have in the resulting GA under these circumstances? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Primary Architectures: Another Proposal (RFC)
On Tuesday, April 10, 2012, 11:27:59 AM, Kevin Kofler wrote: > Horst H. von Brand wrote: >> That is just irresponsible. BTW, there are too few rawhide consumers as >> things stand; this would make rawhide be russian roulette, but with 5 >> bullets instead of 1. > Rawhide IS already Russian roulette. ;-) Perhaps the complaint is that you may be loading all cylinders in the gun with live rounds? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Primary architecture promotion requirements
On Tuesday, March 20, 2012, 7:21:25 PM, Ralf Corsepius wrote: > On 03/20/2012 05:46 PM, Richard W.M. Jones wrote: >> On Tue, Mar 20, 2012 at 05:37:10PM +0100, drago01 wrote: >>> On Tue, Mar 20, 2012 at 5:34 PM, Brendan Conoboy wrote: On 03/20/2012 09:21 AM, Ralf Corsepius wrote: > > That said, I considera cross-building environment for secondary arch to > be inevitable, which would at least help for the class of issues, I am > referring to above. I'm a big fan of cross compilation, but introducing it into Fedora in order to support ARM seems unlikely to succeed for too many reasons to go into. >>> >>> The reasons are? >> >> We use cross-compilation right now for mingw-* packages (for Windows). >> However you cannot use cross-compilation to create a foo-*.armv7hl.rpm >> package. That's because our entire toolchain, from RPM through Koji, >> simply does not understand cross-compilation properly. > Well, the mock/rpm part is the smaller part of the issues (I use > customized mock setups on Fedora to build mingw-* and cygwin-* packages). >> Solvable, but undoubtedly a ton of work for everyone. > The real issue would be to re-utilize "foreign native rpms" (here > *.arm.rpms) to install them in sys-roots on x86. > (Fedora's mingw*-toolchains are explictly packaged to fit into x86) > Ralf On July 7th, 2009, Mark Salter made a post "crossbuilding rpms with koji" on the fedora-buildsys-list" where he described a project to add cross-building support to koji/moc/rpm/etc. The post in archived post is at http://www.redhat.com/archives/fedora-buildsys-list/2009-July/msg0.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On Friday, March 2, 2012, 4:21:13 PM, Jóhann wrote: > Some people seem to be confusing this like this would instantly take > effect which is not the case here. > We are just talking about automating the "NonResponsiveMaintainers > policy" as is so instead of an reporter to manually perform these steps > ( which they can perform at any time now btw ) those steps would be > automated... It really _is_ quite different. The trigger for NonResponsiveMaintainers now is an actual person with a real problem that they need solving. People understand this trigger. An automated trigger has to be something substantial, a tuned heuristic based on actual outstanding bugs in specific states. Triggering too often, or without clear justification will result in the automated emails being ignored as spam. Triggering the process purely based on lack of activity is one of the cases that isn't reasonable. The maintainer's packages could all be very mature, and need no rebuilding and infrequent updates (because upstream only releases every couple of years). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Automating the NonResponsiveMaintainers policy
On Friday, March 2, 2012, 12:23:51 PM, Jóhann wrote: > On 03/02/2012 05:10 PM, Rahul Sundaram wrote: >> Again, what access do you need and who have you asked for it? > It's pretty obvious that this is a proposal I made today thus I have > asked no one for it nor can I since infrastructure has made it clear to > me when I asked them to fix my user accounting mess that I found myself > into that they do not handle bugzilla that is Red Hat only territory. > Secondly first we need to reach conscious about the proposal in general > then if reached settle on a time frame for the automatic process to > start taking place as Aleksandar and other have pointed out. > I'm not sure how you do things in your part of the world but usually > here on top of the world we dont start building houses without knowing > first how they should look like... Perhaps one factor is that what you are trying to build may not be right for the problem at hand, and a new solution is required for a different sort of problem? Or perhaps the issue is that we only have one sort of tool/process, and you are attempting to solve your problem with that tool when a better solution would be to propose a new tool. The NonResponsiveMaintainer process is designed to remove all packages from a maintainer who has gone missing, and is no longer able to take care of their duties as a Fedora package owner. It seems to me that many who object to using this large hammer to solve what some view (correctly or incorrectly) as one minor packaging issue of many. Perhaps it would be better to view this as something more akin to the FTBFS (fails to build from source) process, where regular attempts are made to build packages from source, and those failures tracked. That and the follow-up process are more of an "action required by maintainer" type of process than a "fix it now or else" process. I would suggest that you might be better to propose a generalized "FTFPG" (fails to follow packaging guidelines) process, of which one of the first regular automated checks would be to discover and track packages that are not enabled for systemd. This would expand over time to check for other packages which violate other guidelines for which automated checks can be created. Automation would include creating bugs, tracking reports, and should have exception lists to support known/approved exceptions. By the way, that automation would need to be in a package... which might well be suitable to be your one/only Fedora package. 8^) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service iptables save, systemctl, and unhelpful error messages
On Wednesday, February 15, 2012, 7:15:13 PM, Reindl wrote: > Am 16.02.2012 00:48, schrieb Al Dunsmuir: >> On Wednesday, February 15, 2012, 6:12:44 PM, Reindl wrote: >>> this will not work since if a systemd-unit is present >>> systemd no longer is interested in anything from >>> /etc/init.d/ >> >>> so there is no solution except patch systemd if iptables.service is >>> called which will not happen because it would be unmaintainable >>> ober the long and doing it for iptables would bring a lot of >>> of other people complaining "but why not XXX whateverservice" too >> >> Johann has spent some significant time contributing to the last two >> Fedora releases, specifically a great deal of the actual conversion to >> systemd init. >> >> I'm sure that he and others can get something functioning rather >> quickly by working _with_ the systemd developers. Even better, my >> experience is that both Johann and Lennart are fully capable of coming >> up these answers without filling everyone's days with bile and crass >> negativity. >> >> Why not let them have a chance, instead of insisting on using every >> opportunity to attempt to advance your own twisted viewpoint? > what is your exactly problem here? > well, wait their replies that they will not include all > sorts of exceptions for random services in systemd because > their target is holding systemd clean and compact to prvent > the need of the next init-system switch in few years Q.E.D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: service iptables save, systemctl, and unhelpful error messages
On Wednesday, February 15, 2012, 6:12:44 PM, Reindl wrote: > this will not work since if a systemd-unit is present > systemd no longer is interested in anything from > /etc/init.d/ > so there is no solution except patch systemd if iptables.service is > called which will not happen because it would be unmaintainable > ober the long and doing it for iptables would bring a lot of > of other people complaining "but why not XXX whateverservice" too Johann has spent some significant time contributing to the last two Fedora releases, specifically a great deal of the actual conversion to systemd init. I'm sure that he and others can get something functioning rather quickly by working _with_ the systemd developers. Even better, my experience is that both Johann and Lennart are fully capable of coming up these answers without filling everyone's days with bile and crass negativity. Why not let them have a chance, instead of insisting on using every opportunity to attempt to advance your own twisted viewpoint? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi bugfix release in production
On Tuesday, October 25, 2011, 6:32:26 PM, Michael wrote: > Luke Macken wrote: >>> In case you hadn't noticed, response to this has so far been pretty >>> > negative. It seems people liked being able to tell from the URL what the >>> > update actually*was*. I must admit I do to. I've resorted to creating >>> > the 'old-style' URLs manually when I do lists of updates on test@ or in >>> > trac, now. >> I'd be happy to revert this if the majority of people prefer the other >> format. Bodhi will still use the n-v-r style URLs for the >> updates-testing digests, but will default to the static IDs otherwise. >> The biggest problem with using the builds in the URL is that the URLs break >> if they >> are edited to add/remove/update them. I guess we could add some >> additional logic to try and be clever and find the update even if one of >> the builds is missing or modified. > Think about how bugzilla bugs are handled in IRC. Bugs all have ID > numbers. Why should updates be different? I vote for static IDs because > I have run into the case of modified updates and broken URLs. > Adam, can you not pursue an enhancement to the IRC bot that translates > bug URLs into descriptions to also handle bodhi IDs? This is surreal. Are you trying to single handely kill what little real user testing is being done on the various Fedora releases? Now you want to make users bring up yet another tool - an IRC client? Why not just be done with it, and bury the reports in a locked filing cabinet in a barred sub-basement room labeled "Ignore me - do not open"? Perhaps there are simpler alternatives. The whole point of the updates testing reports is to provide information that _quickly_ makes folks aware of what new packages are available in updates-testing for a given release. Real users know the names of the packages that they use. That information is now gone - hidden behind a VERY SLOW process of is following links. I tried the first day the report changed. I gave up, as it was taking a significant time to bring up each link. The first reaction in the proven testers meeting was that the new reports were not at all useful, and should be immediately reverted. It has been a number of weeks since then, but it appears we now have something else instead. The report generated by the latest iteration is broken. This has already been noted by others, and they have made suggestions as to how to fix this (listing the package names below the URL). I had an idea a number of weeks ago to increase the visibility of those packages sitting for long periods of time in updates-testing, in faint hope that someone would care enough to test and give karma. Kevin Fenzi encouraged me to open a TRAC request. It was to simply show the number of days that each package has been in updates-testing in the report, something that bodhi should have readily at hand. Having URLs that are not brokwn is important. Showing the package name and the number of days it has been in updates testing (to the left of the name) is equally important. Please consider doing all of these in your next revision. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: http://fedoraproject.org/wiki/Features/SysVtoSystemd
On Tuesday, September 6, 2011, 5:28:34 PM, Kevin Kofler wrote: > Jóhann B. Guðmundsson wrote: >> There is one thing I have learned ( so far in the conversion process ) >> and that is that the current model surrounding maintainers and >> maintainership followed by various policies surrounding that model which >> we use here in Fedora as in maintainers "Own" their components ( >> ownership model ) cannot deal with large scale changes like systemd >> introduces amongst other things and I will go so far to say that module >> effectively became outdated when Fedora stopped being hobby distro ( >> which happened the instance people/corporates started depending on >> fedora and the components it ships which kinda says it never was ) made >> up of relatively few components with relatively few maintainers and an >> hand full of users but that discussion belongs in another thread. > That's exactly why I'm saying that global changes should be done globally, > not by each package's maintainer. I agree, provided you mean "not necessarily by each package's maintainer". In some cases, folks working on the common goal do need the assistance of the package maintainer. Alternatively, the package maintainer may be able to make the required changes in a timely manner on their own. Package maintainers must not be allowed to emulate King Canute and attempt to hold back the tide of change. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Monday, August 29, 2011, 7:54:10 AM, Karel Zak wrote: > I'd like to remove: > ddate - converts Gregorian dates to Discordian dates > command from rawhide (F17). IMHO this crazy command is used by very > very small minority of Fedora users. > Comments? Why does it matter to you? Why make this change, which will at best inconvenience that very small minority of Feedora users.? If it is maintained, and works then it should stay. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
On Friday, August 26, 2011, 3:35:52 PM, Andrew McNabb wrote: > On Fri, Aug 26, 2011 at 04:29:55PM +0200, Karel Zak wrote: >> >> Windows and GPT FAQ: >> >> Q. Can Windows 7, Windows Vista, and Windows Server 2008 read, write, >> and boot from GPT disks? >> >> A. Yes, all versions can use GPT partitioned disks for data. >>Booting is only supported for 64-bit editions on UEFI-based >>systems. >> >> http://msdn.microsoft.com/en-us/windows/hardware/gg463525.aspx > I don't know for sure, but this may be a case where progress is more > important than compatibility. In any case, it would be comforting to > have this issue documented in the Fedora 16 Release Notes. I disagree. This is a bogus argument, similar to those which have repeatedly stripped away Fedora's ability to support older hardware (especially video) in the past few releases. Hopefully Ajax's recent work on software 3D should restore that a bit so those of us with older but still useful systems can run Gnome 3's full Shell. The magnitude of impact depends on whether the typical Linux user who also runs some variant of Windows is at those levels. In my experience personally and in a corporate environment, that would typically be 32-bit XP. Those folks who pay the Danegeld to upgrade to the later Windows releases on a given system are less likely to also be Linux users. On systems where 32-bit is XP is running, one by definition is running with a disk of 2 TB or less. Fedora installation must by default do the right thing. We need to agree on what that happens to be. On a related topic, why in heaven's name is Fedora not including the simple grub setup commands that are familiar to Ubuntu users? Making folks remember a long form instead of providing a few helper scripts seems short-sighted at best, and arrogant/NIH at worst. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
On Tuesday, April 12, 2011, 3:04:36 PM, I wrote: > For the Intel arches, it may make sense to have all kinds of X drivers > available by default. For the secondary arches, the user requirements > and physical environment. Brain fart - I meant to say "and physical environment differ". Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rfc/headsup: graphics driver packaging in F16+
Hello Nathaniel, On Tuesday, April 12, 2011, 2:01:26 PM, Nathaniel McCallum wrote: > On Tue, 2011-04-12 at 13:57 -0400, Casey Dahlin wrote: >> On Tue, Apr 12, 2011 at 01:48:19PM -0400, Nathaniel McCallum wrote: >> > >> > With this approach, you have lost a critical feature: the ability for >> > you to change your hardware (or move the software bits to a different >> > computer) and have everything automatically work. >> > >> > Nathaniel >> >> You lose it for a couple of strange usecases though: >> >> 1) Moving from a card that is up to date in what it supports to an older >> card that isn't (rare). >> >> 2) Moving from one crappy ancient card to another (plausible, but still >> rare). >> >> The vesa driver should mean some workable video support in either case, >> and from there, if we were really, truly concerned, we could detect the >> need for the driver and prompt to install it. That's starting to sound >> like the bad old days of kudzu though, and I'd be surprised if anyone >> really felt this was worth that effort. > I think losing it in those cases is probably acceptable. My thought is > that the disk space for drivers is minimal, lets just support everything > (or at least the current stuff) in a single install. My concern isn't > moving to and/or between rare old cards. My concern is moving from > nouveau to intel or radeon... The "big" drivers should definitely be > installed on every system, regardless of its hardware. > Nathaniel For the Intel arches, it may make sense to have all kinds of X drivers available by default. For the secondary arches, the user requirements and physical environment. On zSeries, there is no relevant graphics hardware. When one runs X, it is the application side only via a remove X display server on another system. For ARM, the root filesystem is set up with an appropriate kernel (likely customized) and a single X display driver. On ARM, system space is typically quite tight. Heck, even Intel-based netbooks and tablets don't have all _that_ much storage. Whatever decisions are made should take these differences between arches into account and allow appropriate default and custom setups. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Thursday, November 18, 2010, 2:06:38 PM, Peter Jones wrote: > On 11/17/2010 10:59 PM, Matthew Garrett wrote: >> On Thu, Nov 18, 2010 at 12:42:56AM +0100, Kevin Kofler wrote: >> >>> Because it's NOT a bug in glibc, because what glibc does is CORRECT, >>> because >>> it actually POINTS OUT bugs in applications which are portability issues >>> and >>> can hurt future optimization opportunities (regardless of whether the >>> current implementation really is faster than before or not) and, most >>> importantly, because it is NOT our job to work around bugs in proprietary >>> software! I'm in 100% agreement with Kevin's position on this matter. I also avoid Flash on Linux (and run with NoScript to keep a lot of other crap at bay). I have a couple of XP machines that I can use if I really need Flash. The glibc certainly conforms to the memcpy standard definition, and did not break the ABI. Apps that are not coded to use memmove when required are broken-by-design. QED. >> Pretty sure it doesn't point them out. It just breaks them. Could you >> shout a little less? I'm already hungover and I haven't even been to bed >> yet. This is a very low level and standard function, with absolutely no way to issue messages. On some CISC platforms (like zSeries mainframe), memcpy results in the compiler emitting a single instruction in the right conditions (move length is a constant). > Obviously we should make glibc check the ranges and abort() with a snarky > note. > Peter Not interested in that either. Those checks would significantly slow down all code. Not by a little, but by an enormous amount. Anything change at this point would be wasted effort - all to handle a few programs written by folks who _obviously_ never bothered to learn C programming correctly in the first place. C has come a long way since K&R, but this restriction has been in place since day-1. Fedora's limited resources are much better directed towards finding ways to make bad programs fail louder and earlier in the development cycle. Oh yeah... Adobe isn't part of Fedora, and doesn't concern themselves with our schedules. Based on their response, they don't really seem all that concerned with their own schedule regarding this issue. C'est la vie. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Wednesday, October 13, 2010, 6:56:18 PM, Gregory wrote: > On Wed, Oct 13, 2010 at 6:46 PM, Adam Williamson wrote: >> On Thu, 2010-10-14 at 00:36 +0200, Kevin Kofler wrote: >>> Thorsten Leemhuis wrote: >>> > * Why haven't those that want iceweasel and icedove in Fedora not >>> > simply invested some time and got them integrated into the repository?(¹) > Iceweasel as it currently exists in debian currently bundles exactly > the same media libraries. > (http://packages.debian.org/source/experimental/iceweasel — notice the > lack of dependency on libvorbis,libtheora,libvpx,libogg,etc) > It's facts like these that put the lie to the ridiculous claim that > the media library bundling has much of anything to do with trademarks. Gregory, Ah say suh... how dare you bring facts to the table! That equine was only a few weeks dead, and I am certain - I said certain - that it would eventually notice the floggin'! Just think of all those wasted weeks of ranting where no one else bothered to check the _assumptions_ made by the "it must be the trademarks causing the problem" folks. I think the appropriate term is "Game, Set and Match". Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
Hello Kevin, On Wednesday, October 13, 2010, 5:30:52 PM, you wrote: > Well, normally it's the s390 arch team's job to fix the build on s390, and > they should have commit access to all packages, even Firefox. If that's not > the case, talk to the infrastructure team to get the required access. > But I agree that closing it as fixed in a more recent Fedora release is > completely unacceptable for a build fix which prevents shipping the package > at all on that architecture. This MUST be fixed in the F12 branch. > Kevin Kofler Kevin, Reality checks: 1) Do you _really_ think that there is much use of desktops (let alone desktop applications such as Firefox) on zSeries? Most folks doing it are likely using emulation (Hercules), for the usual educational and developmental purposes. These folks will use the native browser, not the slower emulated system one. Unless you have a dedicated LPAR or VM, running desktop apps is quite rare on real zSeries hardware. It is mostly for bragging rights. Every now and then folks with z10 or later hardware (which finally is leading edge CPU performance) will experiment with bringing up a desktop environment like Gnome. Older hardware requires significant patience. It isn't something that one would do on a production server, where you pay for CPU consumed. In reality those servers would be almost exclusively RHEL. 2) For several releases, s390x secondary architecture was not very active. That has changed with F14, which is causing significant excitement on mailing lists such as linux-...@vm.marist.edu. The s390x team decides where they invest their limited resources. F14 is where they made the wise decision to focus - that equine is not deceased, but chomping at the bit. F14 on zSeries is a very viable release for application porting and development, whether on real hardware or emulation. Mostly using non-GUI means. I would expect nearly all downstream production systems would be RHEL systems. 3) If there is anything that fits in the "do not touch" category, it would be a core package on a secondary architecture on a release no one is using that is nearing EOL. It might be best to find a better target to rant and rave on both Firefox and the stable release vision. Or just let it go. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bodhi v0.7.9 deployed
On Wednesday, September 29, 2010, 4:15:28 PM, Kevin Kofler wrote: > Today it's this package. Tomorrow it'll be another one. Sure we can solve > this particular problem (but it's taking WEEKS!), but why would that be the > only one? See http://www.youtube.com/watch?v=Bmxyj6iInMc Now that the problem and solution have been identified in this case, it seems to me that a similar approach would also work in the future. It would be helpful if there was an automatic report send to the developer mailing list identifying packages that have not been promoted within a certain number of days. That would serve to keep things from slipping through the cracks. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)
On Wednesday, September 22, 2010, 6:19:28 PM, Jesse wrote: > On 09/22/2010 04:07 AM, Adam Williamson wrote: >> On Wed, 2010-09-22 at 10:24 +0100, Richard W.M. Jones wrote: >> >>> This is reasonably easy to fix: we should do some testing and withhold >>> packages from Rawhide if they don't pass some basic sanity checks >>> (eg. does it boot, can an X server be started). >> >> That's basically the proven testers process, which at present is running >> around capacity trying to cover three releases (two current stable, plus >> Branched). I'm really not sure we could manage another release, >> especially one like Rawhide where people have a right to expect updates >> to land quickly. > I think the idea is to apply an AutoQA filter between the builds and > showing up in rawhide, not applying a bunch of human tester filters and > bodhi. Add a separate rawhide-testing repo as a staging area for changes (equivalent to updates-testing in a branched release). - Use autoqu to run basic tests and dependency checks. - Use a subset of the controls for branched releases. The focus should be that once dependencies and any package-provide tests are good things can quickly and automatically move into rawhide. Suggestions re controls: Make the delay for automatic promotion short (say 2 days delay instead of a week). Let bad karma hold back bad updates, but make promotion easier than for a branched release. Don't tie up proventester resources. Allow developers to push directly to rawhide if the autoqa tests pass - require FES override otherwise. In other words, create a sane system that parallels that used by branched releases. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)
On Wednesday, September 22, 2010, 8:06:12 AM, drag01 wrote: > On Wed, Sep 22, 2010 at 11:24 AM, Richard W.M. Jones > wrote: >> On Mon, Sep 20, 2010 at 09:58:53PM -0400, Arthur Pemberton wrote: >>> 2010/9/20 Michał Piotrowski : >>> > 2010/9/21 Toshio Kuratomi : >>> >> As the concept of using third party repositories (both as packagers and >>> >> as >>> >> users) grows, this interdependence will grow. >>> > >>> > Ok, so maybe it's time to setup Fedora "backports" repo for these that >>> > wants new and shiny Firefox 4, PostgreSQL 9 or whatever with big >>> > number. >>> >>> >>> What exactly is the fear here with these updates? Are there many >>> desktop users who do NOT want the latest released Firefox? Are there >>> many people using Fedora as their OS for their database server? >> >> Maybe we should turn this around and ask why more people don't >> use Rawhide. > Well "use rawhide" for anything else than testing and/or developing > the new release just do not fly. > Some of the reasons I can think of: > 1) To high rate of changes / breakage These are two separate issues. Change: Without change in Fedora, we might as well turn off the lights. Keeping the change rate high in Rawhide is the whole point. After all, we are trying to keep the other releases more stable by minimizing unnecessary or incompatible changes there - E.G. the branched release that is being packaged, stabilized and validated for formal release, and especially the stable releases that folks need for normal day-to-day usage. Breakage: The problem you are describing in rawhide is partly due to your other points. "Np Frozen Rawhide" was introduced to try to make it so that given a functional Rawhide, the branching off of a new periodic release would become easier. One issue is that while the other releases have a base, updates and updates testing repository that is supposed to allow change to be introduced in a controlled manner, rawhide is basically the other side of the wall (as in, "throw the update over the wall" after it builds). This means rawhide tends to be broken because of incomplete or untested changes, rather than change in general. If a second rawhide-specific staging repository (equivalent to updates-testing, so call it rawhide-testing) was added with some autoqa automation to prevent gratuitous problems (such as broken dependencies in core components), I suspect the situation would improve. Migration of updated packages from rawhide-testing to rawhide would be controlled by the same koji mechanisms that control updating of the other fedora release, but with less restrictions (some wait by default, but not a week), support for karma (negative karma to require override to migrate). I suspect that proventester approval would not be required (aside from there not being enough proventesters to also handle rawhide). > 2) No signed packages There has been discussion of the signing to be there, marking the package as being built by the Fedora buildsystem. > 3) Slower kernel On purpose - first you get things right, then you get them fast. Those additional checks are important so that any issues are identified as soon as possible. You want to benchmark something? Build a no-debug kernel. > 4) To much of "manual fixing" required Maybe reduced with a bit of focus, but likely also part of the nature of the beast. > 5) To many broken deps, which might prevent applying updates and security > fixes This one autoqa should be able to solve. Reduces breakage in general, and helps ensure that breakage in branched releases is identified sooner. > 6) Some others that I can't think of right now might be a consequence > of the above or something else Stuff happens, but Rawhide is the place for it to happen. But not gratuitously - that's not being nice to your fellow Fedora team members. > So please stop proposing rawhide for productive systems (or even > database servers *shrug*). I think that Rawhide is being proposed for testing those types of systems, so that folks help ensure new features reach branched releases ASAP... and in some cases, that might mean an exception granted to update a stable release. Anyone using Rawhide for actual production either knows exactly what they are doing, and is cherry-picking updates once they are done initial setup... or is irretrievably insane (in which case, they won't listen to any advise other than the voices in their heads). Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FF 3.6.9 update for F-13
On Tuesday, September 21, 2010, 2:54:31 AM, Martin Stransky wrote: > On 09/21/2010 01:45 AM, Bojan Smojver wrote: >> On Sun, 2010-09-12 at 17:50 +1000, Bojan Smojver wrote: >>> Isn't that a security related >>> update? >> Ping... > I'm working on it, recently it's delayed in rel-eng: > https://fedorahosted.org/rel-eng/ticket/4125 The current FireFox 3 release being distributed from www.mozilla.com is 3.6.10 - 3.6.9 plus a stability fix. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On Tuesday, September 7, 2010, 10:42:54 AM, Richard wrote: > On 7 September 2010 15:23, James Antill wrote: > This isn't repodata, it's a separate data package. You /could/ push > the icons.tar.gz and desktop sqlite database as repodata, although > it's not going to change for the duration of each release[1] so seems > like a waste of resources. From an rpm point of view, it's easier to > deal with the install and removal of data as rpm scriptlets > system-wide than by pushing this into yum itself (and other distros > could not use this code). We also want this data installed by default, > and not fetched / updated when the user tries to install something for > the first time. That would ruin the user experience. > Richard. > [1] The data only needs to be refreshed if popular packages get split, > or many translations get added. Richard, To minimize the installed footprint on minimal systems such as ARM, would it not make sense to separate the information by translation, so that only the installed translations occupy space on disk and in the sqlite database? Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Putting cross compilers into Fedora
On Wednesday, September 1, 2010, 9:35:16 AM, I wrote: > On July 7th, 2009, Mark Salter made a post "crossbuilding rpms with > koji" on the fedora-buildsys-list". > http://www.mail-archive.com/fedora-buildsys-l...@redhat.com/msg02148.html And for folks who prefer the official archive, http://www.redhat.com/archives/fedora-buildsys-list/2009-July/msg0.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Putting cross compilers into Fedora
On Wednesday, September 1, 2010, 6:41:34 AM, David Howells wrote: > Would it be worth our while putting into Fedora basic gcc and binutils rpms > for cross compilers for all the Linux arches? I keep finding the need to > compile kernels for arches other than the x86_64 boxes I normally use, and I > keep borrowing prebuilt compilers off others (usually Al Viro - thanks Al!) to > do this. > However, as the kernel advances, older compilers cease being able to compile > it, so I have to go finding new compilers again. > It would be much easier if I could just yum install them. > Any thoughts on whether it would be worthwhile? > David I'd like to see an ARMV5 cross-compiler package in Fedora to support the ARM secondary architecture. This seems to be one of the factors that is slowing down that effort. Some folks like crosstool and variats. Aside from the compiler, I'd like to see the other main Fedora build tools enabled for cross-compilation. On July 7th, 2009, Mark Salter made a post "crossbuilding rpms with koji" on the fedora-buildsys-list". http://www.mail-archive.com/fedora-buildsys-l...@redhat.com/msg02148.html I didn't see a lot of follow up, but that seemed an excellent basis for doing cross-compilation in a controlled manner. I'd love to see this be integrated so I could build ARM on my AMD 64x4. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proprietary search engines
On Tuesday, August 31, 2010, 4:59:27 PM, Matt wrote: > On Tue, 2010-08-31 at 08:27 -0700, Adam Williamson wrote: >> It doesn't seem to be an unavoidable requirement, it says: >> >> "If you proposed Start/Home Page is not similar to the existing Firefox >> Start Page, please be prepared to provide a rationale for the change, >> and how it would benefit the end-user. " >> >> I think we could manage such a rationale. > We can definitely make a rationale for having a bunch of Fedora > resources on the start page, but our rationale for omitting a Google > search box, "it's redundant and promotes a proprietary service", is not > a line of reasoning I would expect Mozilla to accept. Then again, they > may calculate that they are better off compromising on this issue in > order to keep Fedora using their trademarks. > -- > Matt Personally, I _DO_ want to have something close to the standard Google search pages as my home page. On my XP systems, I use the standard Mozilla start page. Put too much crap on there (and yes, if I do not want to look for a Fedora resource, too much additional information WILL fit that classification), and I will change the Fedora start page to either the standard Mozilla page or just www.google.ca with just a few keystrokes. At that point, you have lost me as an audience, unless I specifically decide to use the handy Fedora bookmarks provided. Shocking? No. I want to use my computer, and most of the time I bring up a browser session to do searches, or use a bookmark on my toolbar. Stupid UI "innovations" like hiding my toolbar in the FF 4 beta are quickly reverted to the way _I_ want my browser. Please do not ignore that the browser is there for the user to use, not for Fedora to stream information in spite of the user's wishes. This is Linux, not some Microsoft (or Apple) "we know what is best for you" system. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and changes
On Thursday, August 26, 2010, 3:17:52 PM, Jeff wrote: > On Thu, Aug 26, 2010 at 10:29 AM, Jon Masters wrote: >> Great. It works fine on a laptop, in general. But on a >> desktop/server/workstation that is connected for weeks at a time (like >> mine), I don't want to have to do clicky buttony stuff just to make my >> network work. Nothing has yet proved as simple as the "network" scripts, >> though I'm sure we could shove in a few layers of >> g-whatever-it's-called-now-conf for good measure. > Just to be clear.. its the clickity nature of the initial system wide > configuration that is the barrier for you? if you had a reasonable > non-clickity way to add a system wide on-boot activated network > controlled networkmanager via cli would that suffice? > -jef Let's not forget that NM is not suitable for someone running a local DNS server (bind with DNSSEC enabled). It also does not work at all when used on a laptop as a caching DNS. There is a F14^H^H^HF15 feature to make NM work with bind and DSNSEC. I look forward to it - my girlfriend's ISP's DNS servers can take up to 10 seconds to resolve an address, and occasionally simply do not resolve legit URLs. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Staying close to upstream"
On Friday, August 13, 2010, 1:26:34 PM, Jon wrote: > Hey, no fair stating the same point as I did, at the same time, but > better, and without ranting. That's cheating! > :) > -J Sorry... Must be feeling mellow - it's Friday afternoon, and I'm taking next week off. I'll make sure I flick open the napalm dispenser next time. 8^) Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
On Friday, August 13, 2010, 1:11:49 PM, Kevin wrote: > Jesse Keating wrote: >> This is where Kevin blames the scenario on not having the same sqlite on >> all of the Fedora releases, which is another evil plot hatched by the >> devils of FESCo > Right. If F12 has a buggy SQLite, then that SQLite should be fixed! > Kevin Kofler If the SQLite bug can be fixed, then it should be done and the package that found the bug should be updated to list that version as a minimum requirement. That dependency change requires at least an install test. If the bug can not be fixed in F12 in a compatible way, then the package that found the bug may need to take a different approach and find a new way of doing things that works in all supported SQLite releases. In either case, releasing things to stable before the regression is eliminated should not be an option. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Staying close to upstream"
On Friday, August 13, 2010, 1:05:16 PM, Kevin wrote: > Jon Ciesla wrote: >> My understanding of the SIG concept was that they were groups of people >> who were self-organizing around a particular theme to further that theme >> in Fedora, i.e. Games, Live Upgrade, KDE, etc. > Right, but that makes them naturally the best bodies to make decisions > related to those respective themes. > Kevin Kofler It seems to me that "best" depends on the point of view of the person in question, and the outcome of a given decision. The FireFox maintainer might well be viewed as best qualified to determine which (if any) distribution-specific patches they want to support over the life of the package. If you say no, then put that maintainer in a "FireFox SIG" and repeat the question. FESCo might well be viewed as best to deal with policies related to updates across _all_ Fedora SIGs and releases, since that one of the tasks they were _ELECTED_ to perform. Seems you think best is one way in one case, and the other way in the other case. It is this inconsistency that folks are trying to bring to your attention. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The slip down memory lane
On Friday, August 13, 2010, 11:52:33 AM, Kevin wrote: > Mike McGrath wrote: >> :( I'm saddened you think so little of us Kevin. I'd have thought we >> could do both. > And you think Santa Claus exists, too? ;-) > Kevin Kofler http://www.snopes.com/holidays/christmas/photos/badsanta.asp -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi release in production
Hello Kevin, On Thursday, August 12, 2010, 8:04:12 PM, Kevin Kofler wrote: > 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 You are assuming that it is somehow a good idea to push release Fn, in spite of no (or negative) testing. My understanding is that _that_ is what FESCo refused to consider. A saner approach would be that for related changes, release Fn-1 should not be pushed to stable until release Fn is _also_ ready to go. This prevents the EVR problem, and ensures that regressions caught on release Fn that are also applicable to release Fn-1 will not escape. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
Hello Chen, Thursday, July 8, 2010, 12:05:43 PM, Jakub Jelinek wrote: > 2010/7/8 Jakub Jelinek : >> Generally, much better speedup can be achieved by using PGO >> (-fprofile-generate, run on some testsuite, -fprofile-use). >> GCC itself is built that way for several years, but it would be useful if >> other performance sensitive packages were built that way too, assuming they >> have some testsuite which resembles common use. >> >> E.g. bash can be easily trained on some configure or some other >> large shell scripts, similarly for python, perl, ... >> The speedups from this can go up to say 30% or so. >> >> Jakub I would suggest doing PGO for the following: - Compression-type utilities (gz, zip, unzip, 7zip, etc), especially those libraries used by RPM to generate/process deltas. - Helper routines used by yum to extract dependencies - X-Windows server and libraries used for 2D and 3D display such as opengl, compiz, etc. - All programs measured under the Phoronix benchmarks. If we don't, all we do is guarantee easy ways for other distributions to beat us. I know doing it for all critical-path components is not easy (or practical) for the F14 timeframe. Those component lists would however be a good place to look for low-hanging fruit - those programs whose performance affects the system as a whole. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
Hello Chen, Thursday, July 8, 2010, 12:05:43 PM, Chen Lei wrote: > 2010/7/8 Jakub Jelinek : >> Generally, much better speedup can be achieved by using PGO >> (-fprofile-generate, run on some testsuite, -fprofile-use). >> GCC itself is built that way for several years, but it would be useful if >> other performance sensitive packages were built that way too, assuming they >> have some testsuite which resembles common use. >> >> E.g. bash can be easily trained on some configure or some other >> large shell scripts, similarly for python, perl, ... >> The speedups from this can go up to say 30% or so. >> >> Jakub >> -- > It seems MeeGo builds core packages by using PGO already. Is there > anyone who would like to volunteer to write a packaging guideline > about using PGO? > Regards, > Chen Lei FireFox and Thunderbird are already set up with their own PGO build support. One of the complaints for the last year has been that this is used for Windows build, but not for the Linux platform. Sounds like F14 would eliminate that particular wart. See: https://developer.mozilla.org/en/building_with_profile-guided_optimization Hope this helps, Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 Release Candidate Phase
On Monday, May 17, 2010, 7:24:14 AM, Richard Hughes wrote: > On 14 May 2010 14:22, drago01 wrote: >> 4) People adding negative karma because "unrelated bug that has been >> present in the older version is still not fixed" > I get this all the time. It would be nice to be able to have a > "discount this karma" button for maintainers, rather than having to > add an additional +1 just to cancel the misguided -1. > Richard. Sounds good as long as the maintainer is required to append a reason. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Friday, March 12, 2010, 7:09:02 PM, Kevin wrote: > Jesse Keating wrote: >> Then in my opinion those users, and those maintainers who wish to cater >> to those users, can go start their own project. > Even if those users are 70+% of the current Fedora users? That's quite > plausible given the results of Adam Williamson's poll, at least you can't > prove that this is not the case. And Fedora is currently quite close to what > those users want. Your attitude may lead to us losing over two thirds of our > users! And once that's done, it may be too late to win them back. > Kevin Kofler Kevin, Why are you acting as if you wrote the question, and that everyone who took a given position is agreeing without reservation with your position? Very few politicians would be that bold. You are really going overboard, acting as if suddenly you have been vindicated. It ain't that simple. It ain't necessarily so. You are running the real risk of convincing folks with that they had voted the other way, simply to avoid the poll being reanimated like Frankenstein's monster. Time will tell. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal
Friday, March 12, 2010, 7:02:54 PM, Kevin wrote: > Al Dunsmuir wrote: >> Maybe part of the answer is that some resources (especially >> automation) need to be dedicated to keep the core critical components >> of rawhide from being gratuitously broken and staying that way? > An answer to what question? Certainly not to the points I made! > The problem is not with gratuitous breakage, but with breakage inherent to a > rolling branch such as Rawhide. > Kevin Kofler And turning all releases into rolling branches helps keep things sane? Please call a spade a spade. Without a reduction in churn in the stable releases that is what they become and remain until EOL - a rolling branch. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Hello Kevin, Friday, March 12, 2010, 6:52:32 PM, you wrote: > Jesse Keating wrote: >> Fundamental point of view difference. You take the point of view of >> push everything all the time /unless/ there is a good enough reason not >> to. >> >> Others take the point of view of not updating anything unless there is a >> good enough reason /to/. > Right. "Fundamental point of view difference" indeed. But the former is the > point of view many of our users defend, too. :-) See e.g. the results of > Adam Williamson's poll. > Kevin Kofler I think you are reading too much into a quick poll with a binary result. Do not assume that adventurous does not necessarily mean death-wish leaning towards suicidal. It does not necessarily mean the same thing for each release (by which I mean 13, 12, or 11). Similarly, do not assume that conservative means Ubuntu's "no change except for security fixes" policy. In reality, there is a spectrum of risks. The survey represents two points with no qualification (IE margin of error, explanations, cross-correlation questions). It is better than a dart board, and provides a flavour of how that group of folks responded to that question. Without depth it can't legitimately be used to support anyone's favourite position. Remember Mark Twain. We no more want to waste time with regressions than we want to practice free-fall skydiving into swampland without a parachute. You totally reject *reducing* the number of updates to older supported releases, but in worst cases those release *are* our parachutes. The good news, is this has got a number of us end-users off our comfy chairs and involved. We have a stake in the outcome. The bad news, is we have opinions and even a few skills too. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Hello Jesse, Friday, March 12, 2010, 6:20:13 PM, you wrote: > Keeping that cutting-edge release practice, but adding to that stability > once released would indeed be a very unique and desirable niche for > Fedora to fill. Indeed. It means the Fedora community will have grown up enough to understand and even embrace both Fedora's strengths and its weaknesses. The ongoing struggle is to take advantage of the former while working to minimize the effects of the latter. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal
Hello Kevin, Friday, March 12, 2010, 5:39:33 PM, you wrote: >> On Fri, 12 Mar 2010 21:18:11 +0100 Simo Sorce wrote: >> rawhide? F-13 ? > No. > This has already been explained several times! > Rawhide is not the answer. It comes with disruptive changes (and there's no > real way to avoid this problem, see e.g. my replies to Doug Ledford's "To > semi-rolling or not to semi-rolling, that is the question..." thread for > details, but it has also been brought up in other threads), prereleases of > software which is only expected to be stable at release time, no testing > repository (so all the breakage gets dumped directly on the Rawhide user) > etc. > The upcoming release branch is also not the answer. It is not available at > all half of the time, and it is feature-frozen, so it doesn't actually get > the expected feature upgrades (and with a policy like the one you appear to > defend, it won't get them at all, not even after the release). > Kevin Kofler Maybe part of the answer is that some resources (especially automation) need to be dedicated to keep the core critical components of rawhide from being gratuitously broken and staying that way? If these core components were on average in better shape, that should mean that the other packages would tend to also be in better shape. That way, instead of a massive "get rawhide branch working" effort spike, some of that effort could be used on an ongoing basis to keep the spike smaller - perhaps even containable, so there is a better chance that the branch works and the alpha doesn't slip so often or by so much. Al -- Best regards, Almailto:al.dunsm...@sympatico.ca -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal
Hello Kevin, Friday, March 12, 2010, 5:33:15 PM, you wrote: > Al Dunsmuir wrote: >>> On Fri, 12 Mar 2010 21:21:41 +0100 >>> Kevin Kofler wrote: >> >>>> The problem with all the proposals centered on the idea of N-1 as >>>> conservative, N as less conservative, including yours above and >>>> jreznik's, is that it forces all the people who expect a constant >>>> type of updates to upgrade twice as often, i.e. twice a year. >>>> Especially for the conservative folks, this will be a big annoyance. >>>> With low bandwidths, you have to get a CD/DVD shipped each time! In >>>> addition, I think the inconsistency will confuse our users a lot. >> >> Fedora has traditionally supported upgrading from not just N-1, but >> also N-2. Folks often skip releases, especially if they are aware of >> problems (such as the pulseaudio and X issues) with a new release. > That's the whole point! People do this now, but having the two current > releases be supported in a radically different way (with radically different > update strategies) would make this no longer a viable option for many > people. > Kevin Kofler One could argue that one a bit differently. Assuming the following releases: * N (upgrade target) current * N-1 less current than N by factor X * N-2 less current than N-1 by factor Y less current than N-2 by factor Z Say Y is 3 times larger than X (1/3 of the equivalent updates). You are going to point out that the user will see a very large change (Z) as they upgrade from N-2 to N. This may be a large transition, with significant learning and configuration involved. Keeping N-1 and N-2 close to N reduces that. No argument for that point. What some of us are arguing is that the risk and cost (to the users in time, effort) for our user base increases as the release ages. Slowing down the stream of updates that are for low priority bug fixes and new feature increases Y over X. It helps to keep the release more stable (same bugs/behaviour) for users at that release. Less updates on average means less chance of a regression. It also means those updates that do go out are likely better reviewed and tested. One of the common problems with updates is where release N-1 or N-2 have a package at a newer level than the equivalent package on release N. This can easily happen due to differences in the propagation of updates to the various mirror, or if the release N package spends just a bit more time in updates-testing than the others, and misses a window to go to stable. The risk that this happening increases if one does final builds for a given fix simultaneously in multiple releases. Staggering the builds and doing N, then N-1, then N-2 with time to have users validate each minimizes that risk. Different users are willing to accept different risks, but I would submit that a user running release N has demonstrated their willingness to risk the update. Users in release N-1 and N-2 have also demonstrated either their inability to update (bugs) or unwillingness to update. What some of us are proposing is that the updates for each release should reflect those demographics. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
| Accidently sent off-list. Resent. On Friday, March 12, 2010, 3:05:18 PM, Tuju wrote: > On Fri, 12 Mar 2010, Matthew Garrett wrote: >>> RHEL has the resources to backport. Centos uses those backpotrs for >>> free, but does not generate them (unless again the party supporting a >>> component for Centos happens to be upstream in RHEL). >> >> Debian has historically managed this. I really don't buy the argument >> that security or other critical fixes are generally difficult to >> backport. > I thought that this is was reason why there is a package maintainer > exists in the first place, to maintain the package (not the > content): In the likely event that package maintainer is a volunteer, again there may be limited (or no resources/time to backport). It may have to wait a few weeks due to real life issues (kids, spouse, pets, day job). > So in case fedora's users suffer from a security bug, the maintainer > collects the facts (what version, how many users are affected, > important details from bug reports and debugging information, etc), > talks to upstream and if the security bug is not backported, (s)he > asks upstream to do so. They probably has the best skills to do so. In the likely event that upstream is also a volunteer (and perhaps one and the same person as the package maintainer), the same issues will arise. > I don't see how this wouldn't be everyone's interest, even from the > upstream point of view. They most likely don't want such reputation > that their software is dangerous to use. These folks are not running a 24/7 business staffed with trained resources sitting idle (paid for by licence fees) waiting for your problem reports. I was with IBM for 23 years (shop floor control, debuggers, compilers) and most non-OS software problems were addressed by the developers during regular office hours and perhaps weekends. Anyone who thinks that free software should have an instantaneous turnaround for free support isn't being realistic. The developers may even want to provide that... but that is not reality. > Unless the maintainer has issues with communication and social > skills, this could very well be a problem and not that far fetched. > I wonder, how many maintainers have even sent a short email to > upstream and said: > "hello, thank you for coding this cool software with opensource > license. I'm packaging it now to Fedora, please send me > announcements etc and please don't hesitate to contact me if you > have something in mind, I'm your contact at this end". > Frankly, if you ask me, I rather take all backporting done by > someone who actually knows what he's doing. And same goes with > packaging. I think we're in "I want a pony" territory. > What comes to KDE's "there won't be anymore bugfix releases after > new feature release" - so what? How many real security issues has > there been in history? Five? Ten? I bet those all would be > backported by upstream if community size of Fedora would really need > them. Everyone who cannot wait those couple months, can do checkout > and compile themselves. > Tuju When was the last time you tried to build all of KDE? As much as I may disagree with Kevin on some points, what he does is nontrivial. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal
Hello Simo, Friday, March 12, 2010, 3:42:41 PM, you wrote: > On Fri, 12 Mar 2010 21:21:41 +0100 > Kevin Kofler wrote: >> The problem with all the proposals centered on the idea of N-1 as >> conservative, N as less conservative, including yours above and >> jreznik's, is that it forces all the people who expect a constant >> type of updates to upgrade twice as often, i.e. twice a year. >> Especially for the conservative folks, this will be a big annoyance. >> With low bandwidths, you have to get a CD/DVD shipped each time! In >> addition, I think the inconsistency will confuse our users a lot. Fedora has traditionally supported upgrading from not just N-1, but also N-2. Folks often skip releases, especially if they are aware of problems (such as the pulseaudio and X issues) with a new release. > I think you have to decide if you are siding for people with low > bandwidth or cutting them out. > You just said we cannot cater to people with low bandwidth. > Well stick with your point and don't swindle as soon as it doesn't help > you win an argument for argument sake ... > Users are confused and annoyed by too frequent upgrades. Those people > are fine sticking with N and then N-1 until security updates are no > more, and only jumping from N-1 to N+1 once a year. This includes many > developers I can assure you. > Simo. I've also run into cases where I tried to upgrade, but it failed to install. I restored from backups, and kept using the older release until I had time to do a fresh install. I do not believe my experience is unique. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Hello Matthew, Friday, March 12, 2010, 1:47:18 PM, you wrote: > On Fri, Mar 12, 2010 at 01:19:07PM -0500, Toshio Kuratomi wrote: >> A) Fedora requires backports for problems that break ABI. Note that this >> also means that Fedora may need to have people who create non-upstreamable >> patches to software since some upstream fixes may require ABI changes and >> we'd need to fix those a different way. > Other distributions manage this without too much trouble, so I don't see > it being a problem to adopt this policy. > -- > Matthew Garrett | mj...@srcf.ucam.org 1 word: Resources - person power, time, funding, equipment, etc. Fedora is a free software distribution "staffed" informally by volunteers (except for that minority of folks who may be paid to work on Fedora as their day job). RHEL has the resources to backport. Centos uses those backpotrs for free, but does not generate them (unless again the party supporting a component for Centos happens to be upstream in RHEL). At times Fedora barely has the resources to stumble forward from release to release. Adding more mandatory costs for older releases is simply not practical or possible. Then there is the whole "voluntary" part of volunteer. Backporting can be difficult, time consuming, frustrating, or simply impossible. The incentive of $$ from paying customers simply is not there. -- Best regards, Almailto:al.dunsm...@sympatico.ca -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Friday, March 12, 2010, 10:52:35 AM, spot you wrote: > On 03/12/2010 10:47 AM, Eric Sandeen wrote: >> I really think this is not the approach, unless Fedora is just for rich >> people >> in (theoretically) rich countries. I doubt that's what we want. > Or we could just make Fedora print money. ;) > ~spot > P.S. Please don't try this. Could you please add RFEs for World Peace, Curing the common cold, Turning back the ravages of time, and "Should have run when I met my ex" to that? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Hello Kevin, On Friday, March 12, 2010, 10:41:53 AM, Kevin Kofler wrote: > Andrew Haley wrote: >> Because we don't despise our users. I don't, anyway. > If we don't despise our users, we shouldn't let them use crap like third- > party connectivity software which isn't even packaged properly. :-) Kevin, Put bluntly, it is not your system. You didn't pay for it, and you are not responsible for providing the time and effort to maintain it. You are supplying software, for free, that they may choose to use. You don't have the right to prevent anyone from using anything they damn well please... even KDE. If they have a need to run third-party software it is outside of your area of control. Deal with it. Once of the reasons it is called free software is that folks are free (as in freedom) to do what they want with it. That includes making mistakes because they do something wrong or ill advised. Similarly, they don't have the right to demand that you drop everything and fix a problem of their own making. They can request that you fix legitimate problems within your packages, but are subject to your ability and choice to do so. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: QA's Package update policy proposal
Hello Kevin, Thursday, March 11, 2010, 8:09:02 AM, you wrote: > Al Dunsmuir wrote: >> For older releases, the presumption/requirement for stability is >> higher. > Nonsense. The previous and current stable releases are both equally > supported, there isn't one which is "more stable" than the other. Often the reason that folks are using an older stable release because they *can not* update to the new stable release because it doesn't work for them, or they *choose* to wait until the new release is *proven* stable. If you ignore that and assume you are free to do as you will to any active release, I would submit you are putting your own wants ahead of your users. Everyone loses in that case, and it is quite natural that conflict arises. Simultaneously updating all active releases is like climbing a mountain without safety ropes. It works fine while everything goes well, but the first slip means you are in for a big fall. Maintaining the older releases with a heightened emphasis on stability is Fedora's safety rope. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: QA's Package update policy proposal
On Wednesday, March 10, 2010, 7:11:31 PM, Kevin Kofler wrote: > Al Dunsmuir wrote: >> The update to an older stable release should be made widely available >> in that release's updates-testing after the equivalent (not >> necessarily identical) fix has been widely tested in the latest stable >> release. > Uh, no, just no. > They should go to updates-testing for both releases at the same time. > Anything else: > 1. makes things harder for the maintainer, as he/she has to go through all > the Bodhi procedures twice, > 2. just delays the fix for users for no good reason. > I can somewhat understand the argument that they should get separate testing > (even though I disagree with it), or even that the stable pushes should be > staged (even though I also disagree with that), but I really don't see what > it hurts to have the update available in updates-testing right away. Testing > is what updates-testing is for. A lot of the conflict that I am seeing is based on two different basic assumptions: 1) the update will be good and 2) the update will fail. It is OK after sufficient unit testing to go with approach #1 on the latest release. If it turns out there are problems, they can be fixed in one or more additional iterations. For older releases, the presumption/requirement for stability is higher. To meet that, I believe more people would prefer going with approach #2 for these releases. Once the update works out OK with no regressions in the latest release, you have a much higher probability that your the equivalent update to the older release will also be stable and meet that release's stability requirement. Throwing both into their respective updates-testing simultaneously does allow for wider user testing... but is limited by the actual amount of testing. Allowing both releases to be promoted to stable at the same time is the real problem. If you do not (or can not) hold back the older (and in user expectations, more stable) release update than any problem will have a much higher perceived and actual impact. If you don't have the resources to ensure that older releases remain more stable than newer releases, perhaps you do need to revisit whether updates to both releases are a good idea. >> This minimizes the risk that due to a different execution environment, >> build environment, configuration or whatever the seemingly equivalent >> fix does not work but causes a regression. You may start at the same >> place in the older stable release, but may end up down and entirely >> different rabbit hole. > Is this really such a common issue that it makes it worth delaying all > updates, including bugfixes, while waiting for testing that may never arrive > (because those folks who like testing things tend to run the current stuff)? > Kevin Kofler Problems will happen, likely in the worst possible way at the worst possible time for your users. If you work on that assumption, it just makes sense to take more care and time to roll out your fixes the more stable the release is expected to be. If you and the users have a mismatch regarding expectations of stability, it doesn't matter whether your changes are fixes or retrofitted enhancement - there will be highly visible problem if you try to cut corners in either time or effort. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed udpates policy change
On Wednesday, March 10, 2010, 5:59:20 PM, Adam Williamson wrote: >>On Wed, 2010-03-10 at 22:44 +, Ewan Mac Mahon wrote: >> The LHC is an interesting analogy; it certainly has problems that can be >> picked out with 20:20 hindsight, but there was no way anyone could have >> changed the processes in advance that would prevented them coming up in >> the first place. > This is certainly true. However, if they'd decided to build the whole > thing based on their first calculations, measuring once and cutting > once, and without doing any checking to make sure they were building > everything in a straight line, it probably would've gone even worse =) > you're right it was a bad example to pick, though, without further > explanation. > -- > Adam Williamson Um... Adam, on that straight line thing. Last time I checked, they were trying to make a very large perfect circle. **GRIN** Some days Murphy is the only winner, no matter what we do! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: QA's Package update policy proposal
On Tuesday, March 9, 2010, 8:09:40 PM, Kevin Kofler wrote: >> Jesse Keating wrote: >> On Tue, 2010-03-09 at 16:08 -0800, Josh Stone wrote: >>> It seems to cast doubt on the value of karma -- just because something >>> gets lots of positive karma on N doesn't mean that N-1 is ok. Then >>> again, the same concern is present in any grouped update if the voters >>> haven't tried *all* of the packages mentioned. >> >> Even if you put an update for N and N-1 in the same form, once you >> submit the request it splits it into two requests, one per Fedora >> release. This means you'd have one set of karma per Fedora release. > Indeed, and I'd argue that this is a problem, not a feature. If an update is > confirmed to fix an issue in the current stable release and the previous > stable release is affected by the exact same issue, I don't see a good > reason not to push the update with identical changes to the previous stable > release as well. Not doing it would result in the previous stable release > not getting bugfixes in a timely manner, if at all, anymore, as it has a lot > fewer testers. > Kevin Kofler Just to be clear, I am in the "adventurous user" camp that would prefer to have the bug fix retrofitted to the older release. I would, however, qualify that as follows: The update to an older stable release should be made widely available in that release's updates-testing after the equivalent (not necessarily identical) fix has been widely tested in the latest stable release. To me, this means separately developer unit tested, tested by users in updates-testing and then for several weeks of real user use in stable. In parallel with that, separate developer unit testing of the older release should be done, with entry to the older release updates-testing only after the original fix has been proven in the latest stable release. This minimizes the risk that due to a different execution environment, build environment, configuration or whatever the seemingly equivalent fix does not work but causes a regression. You may start at the same place in the older stable release, but may end up down and entirely different rabbit hole. Firing off the "same" fix for multiple targets other than rawhide and the latest release makes me nervous. So to summarize, fixes in multiple releases yes, but with separate schedules for build and testing. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adventurous yet Safety-Minded
On Wednesday, March 10, 2010, 7:24:18 AM, Mathieu Bridon wrote: > On Wed, Mar 10, 2010 at 13:06, Steven I Usdansky > Your proposal especially doesn't address the third point. How do > effectively you rollback the package on the mirrors when you don't > control them? Assuming reversion to an older version of the package is not a frequent event, having only the main repository house the necessary delta files might work out well. The additional network load for reversions should be containable at the master. It has a number of advantages in that additional information about package reversions can be collected: - Basic statistics about the original and reverted package versions. - Require that the user be prompted for a reason for the reversion, and even more valuable information is collected. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed udpates policy change
Hello Krzysztof, Tuesday, March 9, 2010, 3:36:43 PM, you wrote: > Matthew Garrett writes: >> 2) It is impossible to ensure that functionality will not be reduced >> without sufficient testing. > True. The whole point of an update may be the deliberate removal of features/functionality. This includes removal of elements whose upstream is dead, removal of conflicts between packages, conversion of static/copied libraries to the system provided library, removal of features which are irretrievably broken, and those elements which do not fit within Fedora's licence/mission (mp3 support, or patented material). >> 3) Sufficient testing of software inherently requires manual >> intervention by more than one individual. > Definitely. IOW, the testing is never sufficient. Any nontrivial piece of software contains bugs until it reaches end-of-life. This is a simple fact of life. You can't test quality into a product like Fedora. You can only attempt to assist developers in discovering issues that have escaped their unit tests, so that through iterations of design/code/test the package becomes stable and feature complete. It takes many iterations, across many releases for some packages. >> 1) Updates to stable that result in any reduction of functionality to >> the user are unacceptable. An absolute rule containing "any" ignores reality. > That means any and all updates are unacceptable. > -- > Krzysztof Halasa The opposite of change is death. No updates as a hard and fast rule would drive many users and packages away from Fedora. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed udpates policy change
On Tuesday, March 9, 2010, 3:20:25 PM, Adam Willamson wrote: > On Tue, 2010-03-09 at 15:13 -0500, Al Dunsmuir wrote: >> > 1) All updates (even security) must pass AutoQA tests. >> > Rationale: If a package breaks dependencies, does not install, or >> > fails other obvious tests, it should not be pushed. Period. Obviously, >> > this proposal would not be enacted until AutoQA is live. >> >> This is a sane approach. >> >> One problem with immediate implementation would be that all packages, >> no matter how insignificant would need to have tests that could be >> run. Some packages in categories such as firmware or cross-compilation >> tools would require specialized hardware to test fully as part of the >> build or subsequent AutoQA testing. > What Bill's talking about when he refers to 'autoqa tests' are generic > tests which are concerned with package quality, not really the software > in the package: stuff like do the dependencies work, are there any clear > errors in the file lists. They can be run on any RPM package, the > software in the package doesn't really matter. > -- > Adam Williamson That makes sense. How about things like rpmlint? Perhaps that would have caught the bind/dnssec problems where user configs were directly rewritten without backup to rpmnew files. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: QA's Package update policy proposal
Hello James, Tuesday, March 9, 2010, 2:53:22 PM, you wrote: > On Tue, 2010-03-09 at 13:41 -0500, Seth Vidal wrote: >> >> On Tue, 9 Mar 2010, Michael Schwendt wrote: >> >> > If you - and the QA team - want to expand your testing activities, focus >> > on the CRITPATH packages first. Do a good job there. Nobody from QA has >> > ever given feedback to any of my updates, and it won't happen in the >> > future either. >> >> >> I would not be opposed to the above. >> Make the system work on critpath then mandate it from everyone else. > That's a sensible approach, I don't see any harm in using critpath as > the proving ground. > Thanks, > James I think rather that if it is not important enough to start with critpath, one would wonder how critcal the packages in critpath really are to Fedora. The second thing that I noticed was that common servers and clients (such as mock, ssl, dns, ftp, samba, nfs, http were not considered critical. Why not? Perhaps Fedora needs more layers of critical-ness - critical, high impact, low impact? Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed udpates policy change
On Tuesday, March 9, 2010, 2:49:00 PM, Dan Horák wrote: > Thanks Bill, this proposal is very similar to my "dump of ideas" posted > earlier today. The only thing I would like to improve (probably in > PackageKit) is the presentation of the content in updates-testing to the > users, to make it more visible and to encourage the testing. Something > like subscription to selected subset of packages that I want to be > notified about. > Dan I liked the visual presentation of download stats that Adam reference. It may have been Ubuntu or Debian related. I would like a tool that would present the list of installed packages, and allow one to subscribe based on that. Also, bringing it up a level to comps might reduce the user time. Perhaps basing the testing of dependent package testing based on the owning packages would simplify things too. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed udpates policy change
On Tuesday, March 9, 2010, 2:10:04 PM, Bill Nottingham wrote: > However, I do wonder about some of the concerns about this being > a requirement for all packages. So, here's a counter-proposal/expansion. > If need be, each of these policies could be considered separately, although > they do stack on each other. > ... > Proposal > > > For a package to be pushed to the stable updates repository, it must > meet the following criteria. > > 1) All updates (even security) must pass AutoQA tests. > Rationale: If a package breaks dependencies, does not install, or > fails other obvious tests, it should not be pushed. Period. Obviously, > this proposal would not be enacted until AutoQA is live. This is a sane approach. One problem with immediate implementation would be that all packages, no matter how insignificant would need to have tests that could be run. Some packages in categories such as firmware or cross-compilation tools would require specialized hardware to test fully as part of the build or subsequent AutoQA testing. > 2) Updates that constitute a part of the 'important' package set (defined > below) must follow the rules as defined for critical path packages for > pending releases, meaning that they require positive karma from releng > and/or QA before they go stable. This also includes security updates for > these packages. > > The 'important' package set is defined as the following: > - The current critical path package set > - All major desktop environments' core functionality (GNOME, KDE, XFCE, > LXDE) > - Package updating frameworks (gnome-packagekit, kpackagekit) > - Major desktop productivity apps. An initial list would be firefox, > kdebase (konqueror), thunderbird, evolution, kdepim (kmail). > > Rationale: These are the sets of packages where regressions most affect > users, and would most prevent them from Getting Their Work Done. > Furthermore, while I can accept that there may be some packages in Fedora that > cannot find a significant enough testing base for all potential updates, I > reject the notion that any desktop widely used enough that we deploy a > image or spin for it would fit into that category. I accept that this places a > larger burden on QA, and would expect them to be able to contribute testing > to this initiative. Also sane. > 3) All other non-security updates must either: > > a) reach their specified bodhi karma threshold > b) spend some minimum amount of time in updates-testing, with a tracked > number of downloads. > > Proposed time would be one week, but is open to negotiation. > > Rationale: We do want additional eyes on updates wherever possible. We do >have one Fedora mirror that Fedora infrastructure controls; we should >be able to mine this server for data on updates-testing downloads. Again, sanity. > Any update that wants to bypass these procedures would need majority > approval from FESCo. > > > > Comments, questions, reasoned arguments? Part of me wonders if this should be > expanded with a sliding scale for update types (enhancements, for example, get > more stringent treatment than bugfix/security). I think you need to separate enhancements/etc to core components from those for lower risk packages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PROPOSAL: Fedora user survey
Hello Michael, Tuesday, March 9, 2010, 1:23:59 PM, you wrote: >> On Tue, 9 Mar 2010 13:08:48 -0500, Al wrote: >> I want more updates. I want them to be more frequent, incremental and >> each reasonably well tested. Trying to do too many changes at a time >> not only leads to an increased likelihood of error, it makes it much >> harder to determine which update caused a particular issue >> (regression, or simple behaviour change). > Then you need to evaluate the software at a lower level, though, instead > of waiting for official releases. You get incremental changes only if you > examine snapshots of the source code as found in a project's vcs. > Upstream next official release may contain too many changes already. > Even minor releases break badly sometimes, if a developer decided to > rewrite code sections. My point is that too many developers fall into the trap of adding too many changes (fixes, or enhancements) within a given set of changes (been there, done that, learned the hard lessions in multiple x00 KLOC projects). The route to sanity is to ensure that each set of changes is tested adequately (by the developer, and in real world conditions by the end users) before moving on to the next set of changes. The trap that many of the "release it every 6 months" folks fall into is the illusion that somehow this contains the damage. Often, it means that Fedora ends up staggering under heavy impacts as enormous changes are periodically (at release boundaries) thrown over the wall to the end users, like heavy rocks launched by trebuchet. >> I want a Fedora playground that is up-to-date (not quite rawhide, but >> supported if I find an issue). I am willing to accept a reasonable >> amount of risk, churn and extra effort as part of the cost of >> receiving those extra updates. The primary benefit to me is seeing new >> features and bug fixes in a useful timeframe. > There are packagers, who won't like to take such a risk in released > versions of Fedora, however. I would oppose also a policy that forced me to > upgrade to latest releases without a technical requirement/rationale. Their choice. They should know their codebase, and userbase. They have to measure the risks in real time, realistically. IMO, holding back a change too long can have a large negative impact. Making the change under controlled conditions (at least some active users testing and blessing each change with karma) might have better results. I would point out that many fedora users only work with released versions of Fedora. I would hope the latest release gets some love from the developers for a reasonable period (4-5 months) rather than an instantaneous switch of focus to the development release just as the users are coming online. One can argue that older releases should get fewer changes, but perhaps as the KDE folks have argued that means the difference between some changes or no change. In the end, it is their package, their choices, effort and the results will judged by their end-users - ungrateful lot that we might be. BTW, I'm a Gnome user, but support individual choice, Al -- Best regards, Almailto:al.dunsm...@sympatico.ca -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PROPOSAL: Fedora user survey
Hello Ewan, Tuesday, March 9, 2010, 12:41:26 PM, you wrote: >> On Tue, Mar 09, 2010 at 12:07:20PM -0500, Al Dunsmuir wrote: >> To some extent, I view my current contribution to Fedora as being >> unreasonable and insisting that it be able to perform basic server >> tasks reasonably for a small home system. If it can't do that, why >> would I believe that future RHEL releases won't follow the current >> problematic trends that currently plague Fedora? >> > It depends what you think the problems are; if you're concerned about a > high rate of updates, and updates being poorly tested, then those are > process issues that are not going to be replicated in RHEL. If you're > worried about the direction the actual software is going in, then I'd > have thought that the closer Fedora gets to a 'release early, release > often' approach, the better informed you are about what's likely to be > coming, as well as having more of a chance to change it before it's too > late. I want more updates. I want them to be more frequent, incremental and each reasonably well tested. Trying to do too many changes at a time not only leads to an increased likelihood of error, it makes it much harder to determine which update caused a particular issue (regression, or simple behaviour change). > Fedora shouldn't /just/ be a development playground for RHEL, and I > don't think it is, but amongst everything else it does, it is that as > well, and there doesn't seem much point in trying to make Fedora > suitable for low maintanence long running servers when we already have > an excellent Fedora style OS for that. I want a Fedora playground that is up-to-date (not quite rawhide, but supported if I find an issue). I am willing to accept a reasonable amount of risk, churn and extra effort as part of the cost of receiving those extra updates. The primary benefit to me is seeing new features and bug fixes in a useful timeframe. That being said, I want a playground where the cats are kept out of the sandbox - minimal unexpected/unwanted surprises, if you know what I mean. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PROPOSAL: Fedora user survey
Hello Ewan, Tuesday, March 9, 2010, 11:50:21 AM, you wrote: > On Tue, Mar 09, 2010 at 09:33:45AM -0500, Al Dunsmuir wrote: >> Hello Seth, >> >> Tuesday, March 9, 2010, 9:23:00 AM, you wrote: >> >> > Your primary server runs fedora? May I ask why? >> > -sv >> >> I have limited time to do system installs and maintenance. Sticking >> with one distribution helps keep that sane. I have a dual boot XP + >> Ubuntu machine that I do some play with, but I find it strange, having >> used Fedora since FC3. >> > You should consider running a RHEL rebuild like Scientific Linux or > CentOS then; they're very Fedora-like in most respects, and are > supported for very, very long periods. > Ewan More to the point, RHEL/Centos reflect past Fedora releases. To some extent, I view my current contribution to Fedora as being unreasonable and insisting that it be able to perform basic server tasks reasonably for a small home system. If it can't do that, why would I believe that future RHEL releases won't follow the current problematic trends that currently plague Fedora? I don't pretend to be mainstream. For example, my intention is to become involved in the Fedora ARM secondary arch. I recently acquired an OpenRD-Client box... which still ships with a crufty F8 ARM port. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PROPOSAL: Fedora user survey
Hello Seth, Tuesday, March 9, 2010, 9:37:26 AM, you wrote: > On Tue, 9 Mar 2010, Al Dunsmuir wrote: >> Hello Seth, >> >> Tuesday, March 9, 2010, 9:23:00 AM, you wrote: >> >>> Your primary server runs fedora? May I ask why? >>> -sv >> >> I have limited time to do system installs and maintenance. Sticking >> with one distribution helps keep that sane. I have a dual boot XP + >> Ubuntu machine that I do some play with, but I find it strange, having >> used Fedora since FC3. >> >> If Fedora isn't up to the task of handling the basic services that my >> server provides (dns, dhcp, samba, ftp and http) for my home office >> with multiple PCs, what good is it? > Handle the tasks? Sure fedora can - but it doesn't have the updates > lifespan for a server. > -sv Until F8, I had no problems with the 6 month release cycle. I'd update my desktop, then update my server once I was confident that everything was stable. I don't mind if it works. I prefer to work on the server in X. The massive X changes over the last few releases introduced problems were for a good cause (but at the time were painful). I expect that to be fairly settled down, as I don't run any applications that require 3d. Bind seems to messy by nature. Starting in F10, configuration changes were required each release. These were not necessarily all documented (selinux, chroot not working/recommended). Opening problem reports in Bugzilla helped to get those addressed. I'd like to get back to where Fedora "just works", so I could have some time to do development work in areas that would help move Fedora ahead. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PROPOSAL: Fedora user survey
Hello Seth, Tuesday, March 9, 2010, 9:23:00 AM, you wrote: > Your primary server runs fedora? May I ask why? > -sv I have limited time to do system installs and maintenance. Sticking with one distribution helps keep that sane. I have a dual boot XP + Ubuntu machine that I do some play with, but I find it strange, having used Fedora since FC3. If Fedora isn't up to the task of handling the basic services that my server provides (dns, dhcp, samba, ftp and http) for my home office with multiple PCs, what good is it? Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PROPOSAL: Fedora user survey
Hello Seth, Tuesday, March 9, 2010, 8:38:44 AM, you wrote: > On Tue, 9 Mar 2010, Jaroslav Reznik wrote: >> On Tuesday 09 March 2010 14:02:07 Seth Vidal wrote: > I'm sure with the same logic I can say a lot of things. > What I said was " I want fewer broken things." > -sv Seth, The problem is that when things do get broken in a stable release, the updates that fix the problem often only get released in the next release. When I installed F11, two of my systems ran fine for the install and those updates available at time of installation. One of those was an Intel system which only was able to do graphical install with the final release (not any of the snapshots before release). The other was an older ATI board. Both systems were borked by X11 updates that came one week after the GA. I was able to get both system running vesa-mode with help from the mailing list. I dutifully opened bug reports... which I updated regularly. It took on the order of three months until things got back into good enough shape to run native X again. Part of that was because I'd upgraded my monitor and replaced the built-in Intel with an ATI card (needed to support a widescreen LCD at 1920x1200). I am worried that the direction a number of folks is taking would place excessive focus on minimizing risk due to changes. Stuff happens, so in complex areas such as X my experience of a "stable release" being broken a week after release was unpleasant but not all that unexpected. What was unexpected was that it would be acceptable for this regression to be left unaddressed for months, with all of the development resources focused on the next release. My primary server is stuck at F10, waiting for the bind/dnssec smoke to clear. Until I can get my second server functional at F12, it will not be touched. Reality says that I need it functional so I can log in to my day job and get stuff done. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed udpates policy change
-1. Nay. NoWay. No thanks. Uh uh. I could find little or nothing in your proposal to which I agreed... so decided not to quote any. I just registered at Fedoraforums.org and voted "adventurous" in Adam's poll. Just to make sure my voice is heard, and not the shouting of folks who think they know what I want, and want to limit my choices for my own good. I'm using Fedora, which means I want to run leading edge (or at worst current) software. I do software development, and want to have access to the latest and greatest without running Rawhide. I've been a Fedora user since FC3. I have no interest in using RHEL on my systems. You appear to want to turn Fedora into a RHEL clone. Centos does that well enough already. If you don't want to update your own packages except in rawhide or the development release at alpha level, that is your choice. Please do not inhibit my choices by trying to outlaw the very thing that makes Fedora vital for me as an end user. By the way, you made a trivial error when you created the Subject line. Since stuff like that happens with packages, I'd like packagers to have the ability to correct problems. Similarly, if a package is under active development I appreciate the ability to receive enhancements in the service stream for supported releases. Either fixes or enhancements should be reasonably well tested, and well documented (including update comments). Radically incompatible fixes/enhancements that inconvenience users and break running systems are indeed problematic... why yes, I do run bind on my Fedora servers. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to handle a gui- and non-gui-version of the same library/soname
Hello Milos, Monday, January 18, 2010, 2:27:22 PM, you wrote: > is there any good way how to handle the situation described at > > https://bugzilla.redhat.com/show_bug.cgi?id=528524 > > ? > > I.e. you have a single library (single soname) which can be compiled > with or without GUI support (with different ABI) -- and we'd like to > have both of them, of course -- the non-GUI version on headless servers, > the GUI one for desktop. > > As far "yelling at upstream" sounds like the most correct way. I'd suggest that the proper solution would be to separate the GUI functions into a separate library with a separate-but-related soname, and have that library depend on the non-GUI library. That way the final GUI tools would depend on both libraries, and the equivalent command line tools only on the non-GUI library. If possible, common functions should use shared code hosted in the non-GUI library. Otherwise you could get different results from the slightly different code in the two libraries. These lead to "it works if I do it by A1, but fails with A2" bug reports. >From this user's POW, it gets more insane if A1 and A2 are the same tool that supports running in GUI and command line modes. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
