Re: Packaging changes for libev in Rawhide
On Sat, 2013-11-23 at 13:47 -0500, Simo Sorce wrote: > On Tue, 2013-11-19 at 15:30 +0800, Mathieu Bridon wrote: > > libverto > > > > > > Upstream itself requires the pkgconfig file for libev. > > > > That's just a terrible idea, as it means libverto won't build on e.g > > Debian, or with the upstream libev. > > > > libverto should be fixed upstream here IMHO. > > Libverto builds against both libevent and libev being a event loop > abstraction library, if you make libev and libevent conflict libeverto > cannot be built anymore. That's why I said I wouldn't make libev-devel conflict with libevent-devel. I said I would put the event.h header from libev into a libev-libevent-devel subpacke, and only this one would conflict with libevent-devel. I presume libverto uses ev.h from libev and event.h from libevent, right? In that case, it would still do that just fine even after I make the changes. -- Mathieu -- 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: [pkgdb2] call for testers, bug reports and RFE
On Sat, Nov 23, 2013 at 05:34:19PM -0600, Dennis Gilmore wrote: >By using github you are also eliminating the possibility of some people to >contribute to your project. I personally won't create an account on >github. Just because I believe that open projects should be hosted on open >platforms. I'd rather us work out a way to have an open patch submission >and review process. I accept patches coming in any forms, email, fpaste, pull-request via github, git request-pull from git itself... If an upstream only accepts patches coming from the github pull-request mechanism then I would agree with you, but the fact that you don't want to create an account on github is not a reason to not contribute on a project. Pierre -- 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: [pkgdb2] call for testers, bug reports and RFE
Pierre-Yves Chibon wrote: > You're forgeting, patch/code reviews, Export patch from git, attach to new issue in the bug tracker; as the maintainer, apply it with git am and push it; where's the problem? > possibility to close or refer to a ticket from the git commit, Referring just works in Trac (use '#' + ticket number, it will create a link in Trac's display of the commit message). > the possibility to easily follow a project and be informed of its changes The Trac timeline has an RSS feed. > Anyway, did you see the link in the footer? The one that says 'pkgdb'? But the pkgdb2 code is not in there, is it? Kevin Kofler -- 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: [pkgdb2] call for testers, bug reports and RFE
On Sun, Nov 24, 2013 at 12:57:25PM +0100, Kevin Kofler wrote: > Pierre-Yves Chibon wrote: > > You're forgeting, patch/code reviews, > > Export patch from git, attach to new issue in the bug tracker; as the > maintainer, apply it with git am and push it; where's the problem? It is possible, but I have to agree that github is more convenient/efficient than the workflow you describe. > > possibility to close or refer to a ticket from the git commit, > > Referring just works in Trac (use '#' + ticket number, it will create a link > in Trac's display of the commit message). Will it add a notification in the issue tracker? Regards Till -- 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: Using git for patch management in Fedora
On Fri, Nov 22, 2013 at 04:25:00PM +0100, Kevin Kofler wrote: > Richard W.M. Jones wrote: > > > Several packages are using git for patch management. eg: > > > > http://pkgs.fedoraproject.org/cgit/erlang.git/tree/erlang.spec#n46 > > http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/libguestfs.spec?h=f20#n22 > > http://pkgs.fedoraproject.org/cgit/qemu.git/tree/ > > http://pkgs.fedoraproject.org/cgit/ocaml.git/tree/ocaml.spec#n16 > > Ewww, we need packaging guidelines banning this bizarre practice. > > I can see using git-am if you're backporting upstream patches from upstream > git (though patch and thus %patchN is usually good enough for that, too), > but for Fedora-specific patches, it's really the wrong tool for the job. > > > Some of these packages have invented home-brewed methods to generate > > the Patch lines in the spec file, eg: > > > > http://pkgs.fedoraproject.org/cgit/erlang.git/tree/otp-get-patches.sh > > http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/copy-patches.sh?h=f20 > > Ewww! Yuck! Could you explain why you don't like this? If you had actually used it, I'm sure you would see it is far more sensible than manually managing and rebasing patches. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- 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: [pkgdb2] call for testers, bug reports and RFE
On Sun, Nov 24, 2013 at 12:57:25PM +0100, Kevin Kofler wrote: > Pierre-Yves Chibon wrote: > > You're forgeting, patch/code reviews, > > Export patch from git, attach to new issue in the bug tracker; as the > maintainer, apply it with git am and push it; where's the problem? > > > possibility to close or refer to a ticket from the git commit, > > Referring just works in Trac (use '#' + ticket number, it will create a link > in Trac's display of the commit message). > > > the possibility to easily follow a project and be informed of its changes > > The Trac timeline has an RSS feed. > > > Anyway, did you see the link in the footer? The one that says 'pkgdb'? > > But the pkgdb2 code is not in there, is it? And pkgdb2 is in prod? And your conclusions of the fact that this link is there are? Pierre -- 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: [pkgdb2] call for testers, bug reports and RFE
On Sun, Nov 24, 2013 at 01:48:53PM +0100, Till Maas wrote: > On Sun, Nov 24, 2013 at 12:57:25PM +0100, Kevin Kofler wrote: > > Pierre-Yves Chibon wrote: > > > You're forgeting, patch/code reviews, > > > > Export patch from git, attach to new issue in the bug tracker; as the > > maintainer, apply it with git am and push it; where's the problem? > > It is possible, but I have to agree that github is more > convenient/efficient than the workflow you describe. > > > > possibility to close or refer to a ticket from the git commit, > > > > Referring just works in Trac (use '#' + ticket number, it will create a > > link > > in Trac's display of the commit message). > > Will it add a notification in the issue tracker? If the proper git hooks and trac settings are enabled, it is in theory possible. I didn't manage to get it to work on the fedocal project when I looked at it. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20131124 changes
Compose started at Sun Nov 24 08:15:02 UTC 2013 Broken deps for i386 -- [OpenEXR_CTL] OpenEXR_CTL-1.0.1-16.fc20.i686 requires libImath.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIlmThread.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIlmImf.so.7 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIexMath.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIex.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libHalf.so.6 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIlmThread.so.6 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIlmImf.so.7 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIex.so.6 [R-RScaLAPACK] R-RScaLAPACK-0.6.1-13.fc20.i686 requires libatlas.so.3 [bcfg2] bcfg2-server-cherrypy-1.3.3-1.fc21.noarch requires python-cherrypy > 0:3.3 [blueman] blueman-1.23-7.fc20.i686 requires obex-data-server >= 0:0.4.3 blueman-1.23-7.fc20.i686 requires gvfs-obexftp [converseen] converseen-0.6.2-2.fc20.i686 requires libMagick++-6.Q16.so.1 [derelict] derelict-tcod-3-20.20130626gite70c293.fc20.i686 requires tcod derelict-tcod-devel-3-20.20130626gite70c293.fc20.i686 requires tcod [dragonegg] dragonegg-3.3-11.fc21.i686 requires gcc = 0:4.8.2-1.fc21 [drawtiming] drawtiming-0.7.1-11.fc20.i686 requires libMagick++-6.Q16.so.1 [evolution-rss] 1:evolution-rss-0.3.94-2.fc21.i686 requires libcamel-1.2.so.46 [fatrat] 1:fatrat-1.2.0-0.14.beta2.fc20.i686 requires liblog4cpp.so.4 [firstaidkit] firstaidkit-plugin-openscap-0.3.2-7.fc20.noarch requires openscap-content >= 0:0.7.2 [freefem++] freefem++-3.19-3.1.fc18.i686 requires libf77blas.so.3 freefem++-3.19-3.1.fc18.i686 requires libcblas.so.3 freefem++-3.19-3.1.fc18.i686 requires libatlas.so.3 freefem++-glx-3.19-3.1.fc18.i686 requires libf77blas.so.3 freefem++-glx-3.19-3.1.fc18.i686 requires libcblas.so.3 freefem++-glx-3.19-3.1.fc18.i686 requires libatlas.so.3 freefem++-mpi-3.19-3.1.fc18.i686 requires libf77blas.so.3 freefem++-mpi-3.19-3.1.fc18.i686 requires libcblas.so.3 freefem++-mpi-3.19-3.1.fc18.i686 requires libatlas.so.3 [ghc-happstack-server] ghc-happstack-server-7.1.0-1.fc21.i686 requires libHSthreads-0.5.0.2-ghc7.6.3.so ghc-happstack-server-7.1.0-1.fc21.i686 requires ghc(threads-0.5.0.2-e4dbb933a3190a4bd85aab395a8b346f) ghc-happstack-server-devel-7.1.0-1.fc21.i686 requires ghc-devel(threads-0.5.0.2-e4dbb933a3190a4bd85aab395a8b346f) [gtkd] gtkd-2.0.0-29.20120815git9ae9181.fc18.i686 requires libphobos-ldc.so.60 [httpdtap] httpdtap-0.2-2.fc21.noarch requires kernel-debuginfo httpdtap-0.2-2.fc21.noarch requires httpd-debuginfo httpdtap-0.2-2.fc21.noarch requires apr-util-debuginfo httpdtap-0.2-2.fc21.noarch requires apr-debuginfo [initial-setup] initial-setup-0.3.11-1.fc21.noarch requires anaconda-tui >= 0:21.7 initial-setup-gui-0.3.11-1.fc21.noarch requires anaconda-gui >= 0:21.7 [kawa] 1:kawa-1.11-5.fc19.i686 requires servlet25 [koji] koji-vm-1.8.0-2.fc20.noarch requires python-virtinst [kscreen] 1:kscreen-1.0.2.1-1.fc21.i686 requires libkscreen(x86-32) = 1:1.0.2.1 [kyua-cli] kyua-cli-0.5-3.fc19.i686 requires liblutok.so.0 kyua-cli-tests-0.5-3.fc19.i686 requires liblutok.so.0 [libghemical] libghemical-2.99.1-24.fc20.i686 requires libf77blas.so.3 libghemical-2.99.1-24.fc20.i686 requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1 [maven-doxia] maven-doxia-module-itext-1.4-4.fc21.noarch requires mvn(com.lowagie:itext:2.1.7) [mpqc] mpqc-2.3.1-23.fc20.i686 requires libf77blas.so.3 mpqc-2.3.1-23.fc20.i686 requires libatlas.so.3 [netdisco] netdisco-1.1-6.fc20.noarch requires perl(SNMP::Info::Layer2::Bay) [nifti2dicom] nifti2dicom-0.4.6-3.fc20.i686 requires libvtksys.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkWidgets.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkVolumeRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkViews.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkTextAnalysis.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkParallel.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkInfovis.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkImaging.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkIO.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkHybrid.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkGraphics.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkGeovis.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires li
Re: [pkgdb2] call for testers, bug reports and RFE
On Fri, Nov 22, 2013 at 02:34:28PM +0100, Kevin Kofler wrote: > I really don't see what is missing there, apart from missing automation for > the one-time creation process. Something I just noticed: - Github allows to reply to ticket notifications via email instead of requiring to change to a browser and to re-login there. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
debuginfo packages available in updates later than regular packages.
Hi,
I wondered what the reason is that debuginfo packages seem to enter the
repos only at the successive push compared to the regular packages,
which ultimately means that debuginfo packages are available in updates
ca 1 day after the regular packages. From abrt-reported bugs where
people generate the backtraces locally, it occasionally happens that
they send incomplete backtraces due to mismatching debugsymbols, and it
would certainly help increasing the quality of backtraces if such cases
could be avoided (btw, can this also happen on the retrace server?).
A nice solution to ensure consistency could be to have each debuginfo
package require the exact version of the base package installed. Since
the debuginfo package however cannot know which base (sub)package it
should depend on, I wonder whether it could work if the package and all
subpackages should provide something like: Provides:
debuginfo-requirement(%{name}) = %{version}-%{release}?
Thanks,
Sandro
--
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: debuginfo packages available in updates later than regular packages.
On Sun, 2013-11-24 at 16:50 +0100, Sandro Mani wrote: > From abrt-reported bugs where > people generate the backtraces locally, it occasionally happens that > they send incomplete backtraces due to mismatching debugsymbols, and > it > would certainly help increasing the quality of backtraces if such > cases > could be avoided This does suck, but the bigger problem is that debuginfo packages are not updated at all - not ever - unless you either a) use yum instead of PackageKit b) manually enable the updates-debug repository So requiring the exact version of the base package will only work if that gets fixed first. signature.asc Description: This is a digitally signed message part -- 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: debuginfo packages available in updates later than regular packages.
On 24.11.2013 17:55, Michael Catanzaro wrote: On Sun, 2013-11-24 at 16:50 +0100, Sandro Mani wrote: From abrt-reported bugs where people generate the backtraces locally, it occasionally happens that they send incomplete backtraces due to mismatching debugsymbols, and it would certainly help increasing the quality of backtraces if such cases could be avoided This does suck, but the bigger problem is that debuginfo packages are not updated at all - not ever - unless you either a) use yum instead of PackageKit b) manually enable the updates-debug repository So requiring the exact version of the base package will only work if that gets fixed first. Oh, I never noticed this! I take the reason the debuginfo packages do not live in the "normal" repos is that one wants to reduce the repodata/filelist size? Could the current situation be improved by an approach similar to: - Move the debuginfo repo definitions to separate files - Have a package fedora-release-debug (or similar) install the repo file in /etc/yum.repos.d. The repos would be enabled by default when installed. - Have all debuginfo packages depend on fedora-release-debug - (ugly) Have debuginfo-install install the repo file before proceeding as before. ? Thanks, Sandro -- 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: debuginfo packages available in updates later than regular packages.
On 11/24/2013 09:13 AM, Sandro Mani wrote: > Oh, I never noticed this! I take the reason the debuginfo packages do > not live in the "normal" repos is that one wants to reduce the > repodata/filelist size? Could the current situation be improved by an > approach similar to: > - Move the debuginfo repo definitions to separate files > - Have a package fedora-release-debug (or similar) install the repo file > in /etc/yum.repos.d. The repos would be enabled by default when installed. > - Have all debuginfo packages depend on fedora-release-debug > - (ugly) Have debuginfo-install install the repo file before proceeding > as before. > ? debuginfo-install does install yum-plugin-auto-update-debug-info, which automatically enables $REPO-debuginfo for each $REPO you have enabled. -- 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: debuginfo packages available in updates later than regular packages.
On 11/24/2013 10:51 AM, Josh Stone wrote: > On 11/24/2013 09:13 AM, Sandro Mani wrote: >> Oh, I never noticed this! I take the reason the debuginfo packages do >> not live in the "normal" repos is that one wants to reduce the >> repodata/filelist size? Could the current situation be improved by an >> approach similar to: >> - Move the debuginfo repo definitions to separate files >> - Have a package fedora-release-debug (or similar) install the repo file >> in /etc/yum.repos.d. The repos would be enabled by default when installed. >> - Have all debuginfo packages depend on fedora-release-debug >> - (ugly) Have debuginfo-install install the repo file before proceeding >> as before. >> ? > > debuginfo-install does install yum-plugin-auto-update-debug-info, which > automatically enables $REPO-debuginfo for each $REPO you have enabled. ... and now I see you're trying to solve this for !yum, e.g. PackageKit. Sorry for the noise... -- 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: debuginfo packages available in updates later than regular packages.
On Sun, 24 Nov 2013 16:50:51 +0100, Sandro Mani wrote: > Hi, > > I wondered what the reason is that debuginfo packages seem to enter the > repos only at the successive push compared to the regular packages, > which ultimately means that debuginfo packages are available in updates > ca 1 day after the regular packages. Where did you observe this? On a mirror or on the Fedora Project download server? -- 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: debuginfo packages available in updates later than regular packages.
On 24.11.2013 21:52, Michael Schwendt wrote: On Sun, 24 Nov 2013 16:50:51 +0100, Sandro Mani wrote: Hi, I wondered what the reason is that debuginfo packages seem to enter the repos only at the successive push compared to the regular packages, which ultimately means that debuginfo packages are available in updates ca 1 day after the regular packages. Where did you observe this? On a mirror or on the Fedora Project download server? I am running rawhide and it always happens that updates come one day, and the corresponding debuginfo packages the next day. Actually I'm not sure if this is the case also in stable releases, but I though that was why the debuginfo symbols in various abrt bugs were mismatching. However, I didn't realize that the debuginfo packages were only updated via yum and not via PackageKit (as Michael mentioned before in this thread), so that is probably the more likely cause. As far as the mirror is concerned: just using the mirror which yum picks for me, so I guess the answer is: pretty much any mirror. Sandro -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Proven packager help requested: Rebuild python-tag
Hi, Python-tag is broken in F19/20/rawhide. It failed to build during the boost 1.54 rebuild for some reason and is therefore in FTBFS for rawhide. I checked out the SCM and rebuilt it in mock, both for F20 and rawhide, quite successfully. No fixes were needed. Could a proven packager please bump the spec and rebuild the package on Koji? It's required by sonata and a few other apps and currently breaks the upgrade path as the bug reports. https://bugzilla.redhat.com/show_bug.cgi?id=1016174 https://bugzilla.redhat.com/show_bug.cgi?id=991882 -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Planned Outage: Server reboots - 2013-11-25 22:00 UTC
Planned Outage: Server reboots - 2013-11-25 22:00 UTC There will be an outage starting at 2013-11-25 22:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2013-11-25 22:00 UTC' Reason for outage: We have another few servers to reboot to bring up to RHEL 6.5 before we go into freeze for Fedora 20 release. This outage should be short and particular services should not be down long during the window. Affected Services: Ask Fedora - http://ask.fedoraproject.org/ Badges - https://badges.fedoraproject.org/ BFO - http://boot.fedoraproject.org/ Blockerbugs - https://qa.fedoraproject.org/blockerbugs/ Bodhi - https://admin.fedoraproject.org/updates/ Buildsystem - http://koji.fedoraproject.org/ GIT / Source Control - pkgs.fedoraproject.org Darkserver - https://darkserver.fedoraproject.org/ DNS - ns-sb01.fedoraproject.org, ns02.fedoraproject.org, ns04.fedoraproject.org, ns05.fedoraproject.org Docs - http://docs.fedoraproject.org/ Elections - https://admin.fedoraproject.org/voting Email system Fedmsg busmon - http://apps.fedoraproject.org/busmon Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ Fedora Calendar - https://apps.fedoraproject.org/calendar/ Fedora Hosted - https://fedorahosted.org/ Fedora OpenID - https://id.fedoraproject.org/ Fedora People - http://fedorapeople.org/ Main Website - http://fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ QA Services Secondary Architectures Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Contact Information: Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/4127 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. signature.asc Description: PGP signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora Workstation Desktop Environment Concept
Hello list, I'm a computer science major interested in Linux software engineering and just beginning to learn programming so I'm use-case #1 and #2. Currently out of all my peers I'm the only one using Linux as far as I know. Most students and developers even those working on Linux oriented projects either use Mac OS out of personal preference or Windows because it's the default in most organizations and institutions of learning. If users cannot naturally and effortlessly migrate to the Fedora Workstation from Mac or Windows and find a "normal" environment they're used to, the product will fail. The problem is that the vast majority of Linux desktops don't meet the design standards set by the established commercial leaders. Currently my favorite desktop environment is Gnome Shell and my second favorite is Mate. Gnome Shell is "almost" there, nearly meets the modern Mac OS level of quality end-users expect, and has an excellent technical foundation, it just needs some simple layout modifications and changes to menu behavior. I've put together a *.pdf document outlining my suggestions and ideas outlining my suggestions in this regard, see the attached link. Hopefully this can be useful to the working group and a provide a starting point for a discussion about the default graphical user interface for the Workstation product. Document Link: http://goo.gl/0IzNgK *this is a Google Documents link Thank you for your time and attention! Regards, Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Best practice for multiple version/OS boot?
Hi, IIRC fedora-review suggested to test packages on all sup- ported Fedora releases. So, with a larger hard disk, I want to install Fedora 19, 20 (soon) and Rawhide and throw in (recent) Debian and Ubuntu as well. As my notebook doesn't support VMs, I'm interested in best practices for partition- ing and multi-boot setups. Currently I use a partition for /boot and another for an en- crypted LVM, so I only need to worry not to put private data in /boot, and I would like to keep such flexibility. I suppose I need to create a /boot partition for each ver- sion/OS. I have had different Fedora versions share the same encrypted LVM without problems; I assume Debian and Ubuntu will do so as well, but I will keep some free space and partitions just in case. More contested seems to be the multi-boot setup. https://bugzilla.redhat.com/show_bug.cgi?id=872826 has a myriad of opinions on how it should be set up; http://fedoraproject.org/wiki/User:Jlaska/Multiple_OS_Bootloader_Guide suggests "chainloader", and http://www.gnu.org/software/grub/manual/html_node/Multi_002dboot-manual-config.html recommends "configfile". Of course there is also GRUB's OS prober. So what are Fedora developers /actually/ using? Creating a separate GRUB partition and "chainloader"/"configfile"? Running OS prober in the "main" OS after each installation/ kernel update? Something else? How often do the setups al- low one to shoot oneself in the foot, or are they (more or less) "foolproof"? Thanks in advance, Tim -- 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: Best practice for multiple version/OS boot?
On Mon, 2013-11-25 at 06:33 +, Tim Landscheidt wrote: > More contested seems to be the multi-boot setup. > https://bugzilla.redhat.com/show_bug.cgi?id=872826 has a > myriad of opinions on how it should be set up; > http://fedoraproject.org/wiki/User:Jlaska/Multiple_OS_Bootloader_Guide > suggests "chainloader", and > http://www.gnu.org/software/grub/manual/html_node/Multi_002dboot-manual-config.html > recommends "configfile". Of course there is also GRUB's OS > prober. > > So what are Fedora developers /actually/ using? Creating a I have noticed a fairly strong correlation here: the more you know about how booting works, the more strongly you are inclined to avoid multiboot as far as possible... There really aren't any perfect options. The upstream advice of using 'configfile' as a sort of chainload-lite is probably the best approach for grub2-booted OSes, overall. jlaska's page is outdated; upstream grub2 explicitly discourages doing full chainloading. I'll slap a 'this is obsolete' header on that page, I don't think James would mind. You'll note, though, that the _design_ of both approaches is fairly similar: have a 'master bootloader' not owned by any OS, let each OS own its own boot configuration, and have the master bootloader read each OS's own bootloader configuration when booting that OS. It's just that the old 'chainloading' method actually loaded each OS's bootloader, while the 'configfile' method has the master bootloader read in the config files from the slaves rather than loading a whole bootloader that they control. Personally, I use VMs. > separate GRUB partition and "chainloader"/"configfile"? > Running OS prober in the "main" OS after each installation/ > kernel update? Something else? How often do the setups al- > low one to shoot oneself in the foot, or are they (more or > less) "foolproof"? No, none of them are foolproof. I'd expect either the configfile or 'let one OS be in charge and run mkconfig from that OS every time you update any other OS' approach would mostly work most of the time. The configfile approach is less of a pain and, because it involves less manual work, less subject to snafus. If I really had to multiboot, I'd probably go with the configfile approach. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] 2013-11-25 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2013-11-25 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again on Monday! We're into Final validation grind now, so I expect we'll mostly be discussing that. Andre has a topic for updating the validation matrices. I had a look at the blocker list and it doesn't look like we could vote on more than one or two, so it doesn't seem like we need to do a blocker review meeting as well - it can wait till Wednesday. This is a reminder of the upcoming QA meeting. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/20131125 The current proposed agenda is included below. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Matrix revisions 3. Fedora 20 Final status 4. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- 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: Best practice for multiple version/OS boot?
On 11/25/2013 07:58 AM, Adam Williamson wrote:
On Mon, 2013-11-25 at 06:33 +, Tim Landscheidt wrote:
More contested seems to be the multi-boot setup.
https://bugzilla.redhat.com/show_bug.cgi?id=872826 has a
myriad of opinions on how it should be set up;
http://fedoraproject.org/wiki/User:Jlaska/Multiple_OS_Bootloader_Guide
suggests "chainloader", and
http://www.gnu.org/software/grub/manual/html_node/Multi_002dboot-manual-config.html
recommends "configfile". Of course there is also GRUB's OS
prober.
So what are Fedora developers /actually/ using?
Depends on what you want to test. To check for packaging issues I am
just using mock. In cases I really want to/need to test a package, I am
using a chainloaded multiboot configuration on an eldery/"written-off"
machine ("a dedicated testing machine").
> Creating a
I have noticed a fairly strong correlation here: the more you know about
how booting works, the more strongly you are inclined to avoid multiboot
as far as possible...
There really aren't any perfect options. The upstream advice of using
'configfile' as a sort of chainload-lite is probably the best approach
for grub2-booted OSes, overall. jlaska's page is outdated; upstream
grub2 explicitly discourages doing full chainloading. I'll slap a 'this
is obsolete' header on that page, I don't think James would mind. You'll
note, though, that the _design_ of both approaches is fairly similar:
have a 'master bootloader' not owned by any OS, let each OS own its own
boot configuration, and have the master bootloader read each OS's own
bootloader configuration when booting that OS. It's just that the old
'chainloading' method actually loaded each OS's bootloader, while the
'configfile' method has the master bootloader read in the config files
from the slaves rather than loading a whole bootloader that they
control.
Personally, I use VMs.
separate GRUB partition and "chainloader"/"configfile"?
That's what I am using. However, Fedora's installer and grub2 can make
this a challenge (It once was easy, but these days it's .
Running OS prober in the "main" OS after each installation/
kernel update? Something else? How often do the setups al-
low one to shoot oneself in the foot, or are they (more or
less) "foolproof"?
No, none of them are foolproof. I'd expect either the configfile or 'let
one OS be in charge and run mkconfig from that OS every time you update
any other OS' approach would mostly work most of the time.
I can imagine the works to some extend within the Red Hat family of
Linuxes, but is almost non-workable when installing several different
Linux distros or different OSes in parallel.
The
configfile approach is less of a pain and, because it involves less
manual work, less subject to snafus. If I really had to multiboot, I'd
probably go with the configfile approach.
The only approach I found working fairly reliable is using a
traditional, strictly separated, cascade of bootloaders with strictly
separated physical partitions.
Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
