Orphaning cloud-init, python-boto
Hi, My time to work on Fedora cloud-related things has diminished in recent months, so I have not been able to give the cloud-init and python-boto packages the care they deserve. They are free to a good home. Thanks, -- Garrett Holmstrom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
License change: cloud-init
Cloud-init has changed its license from "GPLv3" to "ASL 2.0 or GPLv3". -- Garrett Holmstrom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Announcing Bugzilla 5 Public Beta!
On 2017-04-27 09:13, Christine Freitas wrote: Hello All, We are pleased to announce Red Hat's Bugzilla 5 beta [1]! We’re inviting all of you to participate. We encourage you to test your current scripts against this new version and take part in the beta discussions on the Fedora development list [2]. Partners and customers may also use their existing communications channels to share feedback or questions. We ask that you provide feedback or questions by Wednesday, May 17th. Here is a short list of some of the changes in Bugzilla 5: * Major improvements in the WebServices interface, including a new REST-like endpoint, allowing clients to access data using standard HTTP calls for easy development. * The UI has been significantly overhauled for a modern browsing experience. * Performance improvements, including caching improvements to allow faster access to certain types of data. * Red Hat Associates, Customers and Fedora Account System users can now log in using SAML. * The addition of some of theBayoteers extensions allowing features such as inline editing of bugs in search results, team management and scrum tools, etc. * Ye Olde diff viewer has been replaced with the modern diff2html diff viewer * Improved, updated documentation including a rewrite using the reStructuredText format, which allows documentation to be more easily converted into different formats such as HTML and PDF, etc The official release date for Bugzilla 5 will be determined based on the beta feedback. We will communicate to you as the beta progresses. For more information refer to: https://beta-bugzilla.redhat.com/page.cgi?id=whats-new.html <https://beta-bugzilla.redhat.com/page.cgi?id=whats-new.html> https://beta-bugzilla.redhat.com/page.cgi?id=release-notes.html <https://beta-bugzilla.redhat.com/page.cgi?id=release-notes.html> https://beta-bugzilla.redhat.com/page.cgi?id=faq.html <https://beta-bugzilla.redhat.com/page.cgi?id=faq.html> https://beta-bugzilla.redhat.com/docs/en/html/using/index.html <https://beta-bugzilla.redhat.com/docs/en/html/using/index.html> https://beta-bugzilla.redhat.com/docs/en/html/api/index.html <https://beta-bugzilla.redhat.com/docs/en/html/api/index.html> Cheers, the Red Hat Bugzilla team. 1: https://beta-bugzilla.redhat.com/ <https://beta-bugzilla.redhat.com/> 2: https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/ <https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/> ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org A couple minor web UI issues: Logging in with a FAS account redirects to https://beta-bugzilla.redhat.com/None, which yields a 404 error. Several of the custom fields on the right side of show_bug pages have placeholder tooltips such as, "A custom Drop Down field in this installation of Bugzilla." -- Garrett Holmstrom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Replace Coolkey with OpenSC
On 2017-02-02 06:49, Jan Kurik wrote: = Proposed Self Contained Change: Replace Coolkey with OpenSC = https://fedoraproject.org/wiki/Changes/Replace_Coolkey_with_OpenSC Change owner(s): * Jakub Jelen There are more PKCS#11 libraries supporting the same smart cards in the system. For the next releases, we would like to promote OpenSC as a default PKCS#11 provided in place where Coolkey driver is used these days, which will extend a list of supported smart cards and make use of the most of the OpenSC. == Detailed Description == Currently, there are several PKCS#11 modules available in Fedora. Some of them provide the same functionality as the others. Currently, the majority of the work around smart cards is done in the OpenSC project supporting all the major cards we are interested to have in Fedora. On the other side, there is no significant development efforts in Coolkey project, which is currently used by default in some applications (NSS). The provided libraries are dynamically loaded PKCS#11 libraries, so existing applications should not depend directly on either package. The transition should be smooth as the change of the path in the configurations, if any. The only exceptions are NSS (Coolkey installs its module to the NSS database), ESC and pesign (explicit requires should be removed). $ dnf repoquery --whatrequires coolkey esc-0:1.1.0-30.fc25.x86_64 pesign-0:0.112-4.fc25.x86_64 We would like to: * Get rid of explicit requires (pesign, esc) * Switch the default PKCS#11 module in applications from Coolkey to OpenSC (NSS, ESC, pesign, ...?) * Retire the Coolkey package from Fedora (estimated in Fedora 27+) During last months we worked with NSS to implement and test missing features in OpenSC to follow CoolKey driver and specification behavior. == Scope == * Proposal owners: -- For Fedora 26, we want to switch all applications to OpenSC and leave Coolkey as a backup. We will unregister coolkey from NSS database and register OpenSC instead. Doesn't that still make this a systemwide change? -- Garrett Holmstrom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: User Visible Terminology
On 2016-09-16 08:43, Matthew Miller wrote: On Fri, Sep 16, 2016 at 05:02:04PM +0200, Petr Šabata wrote: This is for the labeling of, for example, separate PHP 5, 6, and 7 modules? Yes. Or even variations of the same upstream version. I'm really pro-stream here because these identifiers have nothing to do with upgrade paths and some modules or module stacks wouldn't even have any concept of numbered, progressive builds/releases. It's just a label. I would save the word "version" to identify updates within these "streams". I agree on not using "version" for this. I'm not completely sold on "stream", partly because we talk about "upstream" and "downstream" so much, and this is unrelated to that. How about "branch"? That fits with the idea of "rebase" for switching between them How about "series", as in "the PHP 7 series"? -- Garrett Holmstrom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Naming a sphinx-doc theme: python-sphinx_py3doc_enhanced_theme or python-sphinx-theme-py3doc-enhanced
On 2016-08-23 10:19, Julien Enselme wrote: Hi, Recently I opened a review [1] for a new sphinx theme: py3doc_enhanced_theme [2] The upstream name is sphinx_py3doc_enhanced_theme, so in my opinion, the the package should be named python-sphinx_py3doc_enhanced_theme. Furthermore, there's another sphinx theme with underscores in its name: python3-sphinx_rtd_theme. So I find it logical that the package is named this way. However, the reviewer (Zbigniew Jędrzejewski-Szmek) pointed out that: - Dashes are preferred (See the guidelines [3]) - Most themes are named with this pattern: python-sphinx-theme- Therefore, it would be consistent to name the package: python-sphinx- theme-py3doc-enhanced and I think that's a good point. A middle ground would be to use provides so the package can be installed with both names, but that leaves the question about the "main" name unresolved. Any thoughts? Using hyphens in the package name keeps the package collection more consistent, and adding a Provides entry that uses underscores will more or less seamlessly take care of the case where people installing it assume it uses those instead. It's a win-win to do it that way, IMO. -- Garrett Holmstrom -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F25 System Wide Change: KillUserProcesses=yes by default
On 2016-07-07 05:13, Jan Kurik wrote: == Scope == * Proposal owners: - work upstream to clarify what is the best way for programs to mark themselves to survive logout - update the documentation with more explanations and examples, as we learn what people find confusing in the current scheme of things - evaluate a "permissive" mode for KillUserProcesses, to make it easier to debug processes which stay around after a session terminates - remove the compile-time override in the systemd package - work with upstream authors and Fedora maintainers of programs like screen and tmux to implement the ability to automatically start them in a way that survives a user session, and if the system policy does not allow that, to warn the user. * Other developers: - cooperate on the last item from previous point - identify additional services which need to adapt to the changed default. Different services might merit different handling here: some might be updated them to start through the non-session-specific dbus instance, some might need documentation changes, while others possibly should be handled like tmux and screen. * Release engineering: N/A * List of deliverables: N/A (not a System Wide Change) But this is a system-wide change. Is the intention to fill out this list as people learn what needs to be changed? -- Garrett Holmstrom -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Hacks for multilib unclean C headers
On 2016-06-09 01:18, Jonathan Wakely wrote: On 09/06/16 08:02 +, Petr Pisar wrote: That's because gcc.x86_64 accepts -m32 but cannot produce 32-bit executable without the i686 toolchain packages. It sounds like broken dependencies. The alternative would be for gcc.x86_64 to unconditionally install the 32-bit packages, even though most users will not use -m32 and so won't need them. Another alternative would be to build gcc with --disable-multilib so you can't use -m32, which would be annoying and inconvenient for users. That sounds like a great reason for a Suggests or Recommends dependency. -- Garrett Holmstrom -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: 4.4 rebase coming to F23 soon
On 2016-02-18 17:51, Laura Abbott wrote: 4.4.2 is currently building and should be in updates-testing soon. As usual, please test and give karma appropriately (negative karma for new issues, not existing issues). Forgive my ignorance, but version 4.4.2 of _what_? -- Garrett Holmstrom -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Intend to retire kde-plasma-daisy
On 2015-03-02 2:52, Michael J Gruber wrote: Retired in f22 and rawhide now. Two remarks about the process: - 'fedpkg' always makes me feel uneasy. I don't know what's going on under the hood, and it messes up the git DAG. Those two separate retirement commits should have been one plus a merge. I'd rather use pure git here (but fedpkg also does some message bus thing). FWIW, using fedpkg for that isn't mandatory. I use git directly all the time and all the usual fedmsg stuff still seems to fire. -- Garrett Holmstrom -- 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: Schedule for Wednesday's FESCo Meeting (2014-11-05)
On 2014-11-05 7:21, Richard Hughes wrote: On 5 November 2014 00:47, Kalev Lember kalevlem...@gmail.com wrote: If you would like to add something to this agenda, you can reply to this e-mail Can we turn off updates-testing for future betas? It's hard to test the PackageKit-cached-metadata feature when the set of reps on the beta don't match the set of repos in the final version. We probably want to turn off updates-testing for future TC's if it's not turned off by default already. I should note that I filed that issue [1] for F17. Perhaps it is worth revisiting. [1] https://fedorahosted.org/fesco/ticket/705 -- Garrett Holmstrom -- 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: [pkgdb] python-boto ownership changed
On 2014-01-02 16:38, Andrew Lutomirski wrote: [Third try to send this email. The Gmail Android app has a lovely UI to select the sender address, but it doesn't do anything :(.] On Fri, Jan 3, 2014 at 5:31 AM, Garrett Holmstrom gho...@fedoraproject.org wrote: On Fri, Dec 27, 2013 at 10:32 PM, Orion Poplawski or...@cora.nwra.com wrote: On 12/27/2013 05:24 PM, Andrew Lutomirski wrote: On Fri, Dec 27, 2013 at 9:42 AM, Orion Poplawski or...@cora.nwra.com wrote: Is anyone interested in taking on python-boto, please? I can, although I won't be able to do anything beyond clicking the button for a couple weeks. --Andy Thanks! I can push new releases at times, but I really can't take on any more packages as primary maintainer. I can take it. I had actually discussed this with the previous maintainer before, but it seems that he orphaned it while I was on vacation out of town. Sorry about the delay. :-\ Go for it. Do I need to re-orphan it? I believe so. -- Garrett Holmstrom -- 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: [pkgdb] python-boto ownership changed
On Fri, Dec 27, 2013 at 10:32 PM, Orion Poplawski or...@cora.nwra.com wrote: On 12/27/2013 05:24 PM, Andrew Lutomirski wrote: On Fri, Dec 27, 2013 at 9:42 AM, Orion Poplawski or...@cora.nwra.com wrote: Is anyone interested in taking on python-boto, please? I can, although I won't be able to do anything beyond clicking the button for a couple weeks. --Andy Thanks! I can push new releases at times, but I really can't take on any more packages as primary maintainer. I can take it. I had actually discussed this with the previous maintainer before, but it seems that he orphaned it while I was on vacation out of town. Sorry about the delay. :-\ -- Garrett Holmstrom -- 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: EPEL python-boto rebase
On Wed Jul 3 02:44:42 UTC 2013, Matthew Miller wrote: On Tue, Jul 02, 2013 at 03:47:25PM -0700, Garrett Holmstrom wrote: Hi, folks, Since a large number of people have requested new features in python-boto I'd like to update it from version 2.5.2 to the current version, 2.9.6. API-wise it should be completely backwards-compatible, but there is one change of note: it now verifies SSL certs by default. Will that break anybody? I can help with patches if necessary. https://admin.fedoraproject.org/updates/python-boto-2.9.6-2.el6 We've still got the 2.6.0 in Fedora 19 -- at what point did the SSL change come in? 2.6.0. An F19 update should be on its way to updates-testing if it isn't already there. -- Garrett Holmstrom ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL python-boto rebase
Hi, folks, Since a large number of people have requested new features in python-boto I'd like to update it from version 2.5.2 to the current version, 2.9.6. API-wise it should be completely backwards-compatible, but there is one change of note: it now verifies SSL certs by default. Will that break anybody? I can help with patches if necessary. https://admin.fedoraproject.org/updates/python-boto-2.9.6-2.el6 Thanks, -- Garrett Holmstrom ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Feature template update [was Re: Anaconda is totally trashing the F18 schedule...]
On 2012-11-05 12:22, Jóhann B. Guðmundsson wrote: On 11/05/2012 07:52 PM, Miloslav Trmač wrote: A crit path update that affects, say, two packages and nothing else, could be approved by default as well. Many of the crit path features however affect a large or extremely large package set (e.g. the sysv-systemd script migration), in which case explicitly involving every maintainer as the feature owner before even proposing the feature wouldn't scale; that's where FESCo does need to step in as a more efficient way to represent the large group of packagers. Case in point for F18 [1] and perfect example of one thing that should have been completed within one release cycle... JBG 1.http://fedoraproject.org/wiki/Features/PackagePresets As that feature is about changing distribution-wide policy, I cannot act on it until said policy is written. (See https://fedorahosted.org/fesco/ticket/945) The feature's owners do not appear to be interested in doing so. If you are, I would greatly appreciate it if you would add a proposal to that FESCo ticket so I can have a clear path forward. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: small tip regarding git branch bash prompt in F18/Rawhide
On 2012-08-25 10:09, Todd Zullinger wrote: Enrico Scholz wrote: Todd Zullinger t...@pobox.com writes: Doing this would break current users that have already configured their system to use __git_ps1(). What are current users? Those who installed your just released rawhide changes? No, it breaks anyone that's currently using __git_ps1(), as the function was previously defined in /etc/bash_completion.d/git. Newer releases of bash-completion are moving to on-demand loading, hence upstream git has split out the __git_ps1() function and a few other support functions. Not having this available for current users means anyone with __git_ps1() in their prompt will get an ugly error every time they hit return, e.g.: bash: __git_ps1: command not found That's far more annoying to far more people than having this function in the environment, in my opinion. I don't see the compelling reason to jump through hoops or expect users to make more changes than needed to enable git info in their prompts. Without some justification of harm, I'm not inclined to change this. What's the reason to strongly oppose this being in /etc/profile.d? It's the fact that you're now adding functions to *every* shell, whereas before it was just bash, and then only for people who opted into completion. Since git-prompt.sh makes no attempt to whitelist (or even blacklist) shells for compatibility its code will unconditionally attempt to run, whether doing so will result in errors or not. Since you're looking to maintain compatibility with bash users who rely on that function, is there another, bash-specific location where that file could go? Or might it make more sense to add a simple whitelist or some other check to the top of the file instead? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass changes to packaging
On Tue, Aug 21, 2012 at 12:01 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Tue, Aug 21, 2012 at 02:23:41PM -0400, Lukas Nykryn wrote: Sorry for this mess. After a discussion, we have decided, that the best way would be to create bugs for every packages and then helping creating patches for specfiles. Just to be clear, I had no problem at all with the bugs being filed, nor with the changes (which seem very sensible). I just pointed out it would be better if you actually fixed the packages, or at least offered to do that for packagers. We want to give maintainers possibility to fix this on their own and because we want this change in all packages, creating bug seemed as a better option then spamming devel-list. So my suggested wording for the bug report would be to give the packager a choice: either they do nothing now and can fix the package themselves, or they indicate that they want you to fix the package. I am pleased that I got a bug report and not an involuntary patch, as it gives me a chance to take care of special cases and schedule things appropriately. I do agree, however, that offering to patch affected packages would also be a good gesture and a great way to help move the changes along. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On 2012-08-07 10:35, Lennart Poettering wrote: On Tue, 07.08.12 13:31, Gary Gatling (gsgat...@ncsu.edu) wrote: Question about new systemd policy, If your package is under review, and it enables its service by default, do you add it to the bugzilla of the systemd package or would that be one of the things that needs to happen if it gets approved? To enable a service by default after package installation you need permission from FESCO. See the last line of: https://fedoraproject.org/wiki/Starting_services_by_default If you have permission from FESCO then I will add it to the default preset file in systemd and upload it to Fedora. What service are you specifically wondering about? I maintain a package (cloud-init) with several services that meet the runs once then goes away grant. Shall I file a bug against the systemd package or something else? Going forward, when a package adds or removes a systemd service that starts by default, what is the best way to coordinate the change with the preset policy maintainers? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Change to the Packaging Guidelines
On Wed, Aug 8, 2012 at 8:57 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 08.08.12 00:17, Garrett Holmstrom (gho...@fedoraproject.org) wrote: I maintain a package (cloud-init) with several services that meet the runs once then goes away grant. Shall I file a bug against the systemd package or something else? Cloud sounds like something that is network facing, so I guess you need the OK from FESCO if you want to run it by default. Perhaps, but the second permission grant on that page carries no such restriction on network-enabled services: In addition, any service which does not remain persistent on the system (aka, it runs once then goes away) and does not require configuration to be functional may be enabled by default (but is not required to do so). Examples of runs once then goes away services include iptables and udev. As a set of oneshot services that run once at boot time and then terminate, cloud-init falls entirely within the bounds of that grant. But if the fact that it contacts the network makes you uneasy then I can ask FESCo to clarify their statement. Would that help? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Intent to retire: axis2c
The axis2c package doesn't build against httpd 2.4, and since it is effectively subsumed by one of wso2-wsf-cpp's sub-packages, wso2-axis2, I think it would be better to just retire it. Nothing appears to depend on that package, but if someone wants to take it for some reason then please let me know so I can release ownership. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
On 2012-07-19 15:57, Sam Varshavchik wrote: The fact that the same consequences can occur from upgrades, or some other unspecified events, is irrelevant, because appropriate measures /can/ be easily put in place, to take the appropriate action when upgrading, and most likely for whatever those other mysterious reasons might be. But this is not easily doable with prelink, without resorting to unwarranted nonsense, like inotify or similar workarounds. Why is it simultaneously acceptable to put measures in place to deal with package replacement and unacceptable to put measures in place to deal with prelink when each of these methods of file modification has a well-documented and well-supported method of allowing you to react to them? Technical reasons would be greatly preferred to value judgments. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Introduction: Interested in becoming a packager for fis-gtm and vista
On 2012-07-16 22:50, Clive Hills wrote:
Coincidentally I was looking at gtm this weekend.
One of the interesting points in re packaging it is that one must
bootstrap gtm from an existing gtm using the providing source.
I'm wondering a bit how that might be affected by the Fedora packaging
guidelines?
You need to file a FPC ticket to get a one-time exception.
http://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions says:
Some software (usually related to compilers or cross-compiler
environments) cannot be built without the use of a previous toolchain or
development environment (open source). If you have a package which meets
this criteria, contact the Fedora Packaging Committee for approval.
Please note that this exception, if granted, is limited to only the
initial build of the package. You may bootstrap this build with a
bootstrap pre-built binary, but after this is complete, you must
immediately increment Release, drop the bootstrap pre-built binary,
and build completely from source. Bootstrapped packages containing
pre-built bootstrap binaries must not be pushed as release packages or
updates under any circumstances. These packages should contain the
necessary logic to be built once bootstrapping is completed and the
prebuilt programs are no longer needed. This can be done like this:
# Set this to 0 after we've bootstrapped
%{!? with_bootstrap: %global bootstrap 1}
[...]
%if 0%{?with_bootstrap}
# Do stuff involving the prebuilt files
%else
# The normal build
%endif
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prelink should not mess with running executables
On 2012-07-15 15:00, Sam Varshavchik wrote: Benny Amorsen writes: Perhaps it's just me, but why would the daemon stat /proc/self/exe? I presume prelink writes a new file and renames into place as a proper Unix program should, which still leaves the original program intact on disk until the last open file descriptor referring to it is gone. A means for authenticating a filesystem domain socket's peer. Receive the peer's credentials, then check /proc/pid/exe and /proc/self/exe. If they're same, the daemon is talking to another instance of itself. Admittedly without knowledge of what daemon you are referring to, how is the file name alone sufficient to be able to determine that something is, indeed, the same program? My security-sense seems to be tingling. ;-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Tue, Jun 19, 2012 at 12:21 PM, Dennis Gilmore den...@ausil.us wrote: El Tue, 19 Jun 2012 20:11:20 +0100 Matthew Garrett m...@redhat.com escribió: On Tue, Jun 19, 2012 at 08:54:59PM +0200, Dennis Jacobfeuerborn wrote: pvgrub peeks into the guest disk so it needs to understand the partition table, the filesystem and the grub config file in the guest. Initially it didn't handle things like ext4, grub2 and EFI but AFAIK these should be fine now. I'm not sure what Amazons host systems use but hopefully they run a relatively modern version of pvgrub. Ok, so we need to be able to write a grub config file. We don't need to ship grub, though, right? Correct, we only need to write out a grub compatable config file. it doesnt use a bootloader installed into the disk image at all. it doesnt care if there is one there or not. Like I mentioned two days ago, the only thing that matters for EC2 images is that the kernel post-install scripts continue to be capable of updating grub configuration files, which means that wholesale replacement of grubby with grub2-mkconfig will probably wind up breaking things. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On 2012-06-16 21:08, Ben Rosser wrote: It seems to me that we should make the boot menu more consistent somehow. I feel like the simplest solution is just to run grub2-mkconfig at every kernel update, and stop using grubby for this. Then everything would look consistent- the Fedora Linux boot option would have the latest kernel and all kernels would always be listed under the submenu. (As far as I know, this would just be a change to the kernel specfile, right?). Fedora's EC2 images require grub-legacy configuration files to boot due to EC2's reliance on pvgrub to boot kernels that reside on virtual machines' disks. As a result, making kernel packages exclusively call grub2-mkconfig when they install would likely result in cloud instances with updated kernels that, unbeknownst to the instances' owners, never run. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide: libudev version bump, merged into systemd, libudev user need rebuild
On 2012-06-06 6:26, Adam Jackson wrote: On Wed, 2012-06-06 at 01:12 +0200, Sandro Mani wrote: After having had some funny issues in the past due to there being two systemds (x86_64, i686) installed for some reason, something tells me that it's a bad idea to proceed with the update. Or am I wrong? Having two systemd packages installed isn't necessarily a problem, rpm's color concept on ELF objects should mean that x86_64 should win wherever the two packages' files collide, which should only be in /usr/*bin. It's still not the prettiest thing in the world, I admit; I'd be happier if there were a systemd-libs even if it were effectively not optional. Does rpm handle binaries' colors everywhere, or just in selected locations? I'm especially curious about /usr/lib. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: supercat anybody working on it?
On 6/2/2012 7:03 PM, Adrian Alves wrote: am not following what u mean? On Sat, Jun 2, 2012 at 5:30 AM, Michael Schwendt mschwe...@gmail.com mailto:mschwe...@gmail.com wrote: On Fri, 1 Jun 2012 23:00:29 -0300, Adrian Alves wrote: done I built it, check this out: Spec URL: http://alvesadrian.fedorapeople.org/supercat.spec Check this out: This means to read the following link because it describes a mistake that your spec file makes: https://fedoraproject.org/wiki/Packaging:UnownedDirectories And the following page is _not_ just for reviewers: ;-) This means to read the following link because it is wise to follow the packaging guidelines even before formally submitting a package for review: https://fedoraproject.org/wiki/Packaging:ReviewGuidelines Happy packaging! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On Fri, Jun 1, 2012 at 1:44 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Fri, Jun 1, 2012 at 12:28 PM, Reindl Harald h.rei...@thelounge.net wrote: * it is a valid workload that a application creates a 10 GB tempfile * ok, you say: use /var/tmp * well, i say: my whole rootfs is only 4 GB and 2 Gb are used If your rootfs wasn't big enough for your tmp workload you would have had to have had a separate tmp partition. Either continue to use it— or mount it as swap and set size= to allow you to use it in tmp. It works great. Part of this feature involves patching applications to write temporary files to /var/tmp instead of /tmp. Reindl's point is that this change will cause temporary files that were previously written to the /tmp filesystem that he had explicitly prepared for this purpose to instead be written to /var/tmp and fill up his / filesystem. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On May 30, 2012 5:41 PM, Lennart Poettering mzerq...@0pointer.de wrote: Please be aware that since the most recent systemd uploads /tmp is now in tmpfs by default in Rawhide/F18. For details please see this feature page: https://fedoraproject.org/wiki/Features/tmp-on-tmpfs Thanks for the heads-up! If you have an explicit /tmp entry in fstab things should continue to work the same as before. If you don't then you will now get a tmpfs on /tmp by default. What does an fstab entry that means, leave /tmp on the / filesystem, look like? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-java] Roadmap for Java things in Fedora
On Mar 7, 2012 7:54 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: - Remove mention of maven2 in guidelines since all supported versions have maven-3.x. Some other small cleanups as well perhaps Is there already a separate set of java guidelines for EPEL? If there isn't does this mean we should create them? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need help with systemd service files
On Feb 28, 2012 6:12 AM, Juerg Haefliger jue...@gmail.com wrote: [ 92.376121] systemd[1]: cloud-init-local.service changed start - failed Of interest here is the fact that the script that cloud-init-local.service runs currently has a bug that causes it to return the wrong return code. Since cloud-init.target Requires that service (cloud-config.service does not function correctly without it), two of those services should not be running at all, if I understand the systemd documentation correctly. On Feb 28, 2012 6:12 AM, Juerg Haefliger jue...@gmail.com wrote: On Tue, Feb 28, 2012 at 12:02 PM, Michal Schmidt mschm...@redhat.com wrote: On 02/26/2012 07:37 AM, Garrett Holmstrom wrote: On 2012-02-24 4:22, Juerg Haefliger wrote: So I installed the official Fedora version of cloud-init but the service startup ordering is broken there too: [root@342 ~]# dmesg | grep cloud | grep About [ 91.668396] systemd[1]: About to execute: /usr/bin/cloud-init start-local [ 91.993238] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all config [ 92.540255] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all final [ 92.559834] systemd[1]: About to execute: /usr/bin/cloud-init start I can't reproduce the problem. They are started in the expected order here. Juerg, is this a log of the order during boot? Or did you test the services by listing all 4 of them in systemctl start ...? The latter would show bug 704214. This is the boot order. Different than the last time: [root@fedora ~]# dmesg | grep cloud [1.639947] systemd[1]: Installed new job cloud-config.service/start as 80 [1.639952] systemd[1]: Installed new job cloud-config.target/start as 81 [1.639957] systemd[1]: Installed new job cloud-init-local.service/start as 82 [1.639961] systemd[1]: Installed new job cloud-init.service/start as 83 [1.639966] systemd[1]: Installed new job cloud-final.service/start as 84 [1.640413] systemd[1]: cloud-config.target changed dead - active [1.640426] systemd[1]: Job cloud-config.target/start finished, result=done [ 91.676503] systemd[1]: About to execute: /usr/bin/cloud-init start-local [ 91.686093] systemd[1]: Forked /usr/bin/cloud-init as 489 [ 91.686227] systemd[1]: cloud-init-local.service changed dead - start [ 91.990133] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all config [ 91.998048] systemd[1]: Forked /usr/bin/cloud-init-cfg as 549 [ 91.998213] systemd[1]: cloud-config.service changed dead - start [ 92.364807] systemd[1]: Received SIGCHLD from PID 549 (cloud-init-cfg). [ 92.364835] systemd[1]: Got SIGCHLD for process 549 (cloud-init-cfg) [ 92.364877] systemd[1]: Child 549 belongs to cloud-config.service [ 92.364889] systemd[1]: cloud-config.service: main process exited, code=exited, status=0 [ 92.375143] systemd[1]: cloud-config.service changed start - exited [ 92.375160] systemd[1]: Job cloud-config.service/start finished, result=done [ 92.375264] systemd[1]: Got SIGCHLD for process 489 (cloud-init) [ 92.375302] systemd[1]: Child 489 belongs to cloud-init-local.service [ 92.375311] systemd[1]: cloud-init-local.service: main process exited, code=exited, status=1 [ 92.376121] systemd[1]: cloud-init-local.service changed start - failed [ 92.377151] systemd[1]: Job cloud-init-local.service/start finished, result=failed [ 92.377175] systemd[1]: Unit cloud-init-local.service entered failed state. [ 92.377833] systemd[1]: About to execute: /usr/bin/cloud-init start [ 92.385184] systemd[1]: Forked /usr/bin/cloud-init as 599 [ 92.385262] systemd[1]: cloud-init.service changed dead - start [ 92.385293] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all final [ 92.393218] systemd[1]: Forked /usr/bin/cloud-init-cfg as 600 [ 92.393358] systemd[1]: cloud-final.service changed dead - start [ 92.394075] systemd[1]: cloud-config.service: cgroup is empty [ 92.394927] systemd[1]: cloud-init-local.service: cgroup is empty [ 92.550734] systemd[1]: Received SIGCHLD from PID 600 (cloud-init-cfg). [ 92.550760] systemd[1]: Got SIGCHLD for process 600 (cloud-init-cfg) [ 92.550803] systemd[1]: Child 600 belongs to cloud-final.service [ 92.550810] systemd[1]: cloud-final.service: main process exited, code=exited, status=0 [ 92.559058] systemd[1]: cloud-final.service changed start - exited [ 92.559072] systemd[1]: Job cloud-final.service/start finished, result=done [ 92.559522] systemd[1]: cloud-final.service: cgroup is empty [ 116.415829] systemd[1]: Received SIGCHLD from PID 599 (cloud-init). [ 116.415854] systemd[1]: Got SIGCHLD for process 599 (cloud-init) [ 116.415896] systemd[1]: Child 599 belongs to cloud-init.service [ 116.415908] systemd[1]: cloud-init.service: main process exited, code=exited, status=0 [ 116.422236] systemd[1]: cloud-init.service changed start - exited [ 116.422252] systemd[1
Re: Need help with systemd service files
On 2012-02-24 4:22, Juerg Haefliger wrote: So I installed the official Fedora version of cloud-init but the service startup ordering is broken there too: [root@342 ~]# dmesg | grep cloud | grep About [ 91.668396] systemd[1]: About to execute: /usr/bin/cloud-init start-local [ 91.993238] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all config [ 92.540255] systemd[1]: About to execute: /usr/bin/cloud-init-cfg all final [ 92.559834] systemd[1]: About to execute: /usr/bin/cloud-init start This is strange. Cloud-init is split into four services that mirror their upstart counterparts. The two services that run /usr/bin/cloud-init are supposed to run first, in sequence: cloud-init-local.service: Wants=local-fs.target After=local-fs.target cloud-init.service: After=local-fs.target network.target cloud-init-local.service Requires=network.target Wants=local-fs.target cloud-init-local.service They then use a target to effect the equivalent of the upstart signal that cloud-init would normally emit at this point: cloud-config.target: Requires=cloud-init-local.service cloud-init.service Note that targets are allowed to omit ordering dependencies. Finally come the two services that run /usr/bin/cloud-init-cfg: cloud-config.service: After=network.target syslog.target cloud-config.target Requires=cloud-config.target Wants=network.target cloud-final.service: After=network.target syslog.target cloud-config.service rc-local.service Requires=cloud-config.target Wants=network.target Given this dependency tree, I don't see how cloud-init.service could possibly start after cloud-config.service and cloud-final.service. Anyone have ideas? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to determine FAS from BZ email?
On 2012-02-23 10:20, John5342 wrote: It is possible that they don't match but they are more or less required to though. Last i checked the bugzilla editbugs permissions and the like are set from fas by email address so if the addresses don't match up then the user won't be able to manage bugzilla properly anyway. Even that may not be true, as the infrastructure team has mapped FAS accounts to Bugzilla accounts with different e-mail addresses in the past. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 17’s unified filesystem (/usr-move)
On 2012-01-27 5:10, Harald Hoyer wrote: Any files with conflicting names, which the conversion could not resolve, will be backed up to files named *.usrmove~ residing in /usr/lib, /usr/lib64, /usr/bin and /usr/sbin. To which file does the conversion script append this suffix when it resolves a conflict: the one under / or the one under /usr? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Differences between koji and mock rawhide environments?
On 2011-11-10 8:35, Tom Lane wrote:
(And why is glibc ignoring the convention to use %{?dist} in
Release:?)
There is a bug open for this. Note that dist tags are still optional.
https://bugzilla.redhat.com/show_bug.cgi?id=676755
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
On 2011-11-09 18:48, Adam Williamson wrote: thanks both of you; I hadn't really thought about the consequences of merging vs. cherry-picking, I think I'd just cargo-culted from somewhere the idea of using git merge instead of manually re-doing changes without considering cherry-picking instead. so I guess in general it's both a better idea and more likely to work to use cherry-pick instead of merge, unless the two branches are really expected to be identical? FWIW, that is the way I approach it. If several branches are in sync (or nearly so) then merging makes more sense to me. But if the branches diverge then merging from the rawhide branch to a maintenance branch makes little sense, making cherry-picking the better choice. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New bodhi bugfix release in production
On 2011-10-25 15:17, Adam Williamson wrote: It's not just the updates-testing list, though. When I go to the web interface, search for updates to, say, grub2, get a list, and click on one of the results, I get an ID-based URL, not a package name-based one. I then paste that into an email, IRC conversation, or trac compose request ticket, and no-one can see what the update *is* unless they click on the link. And after a few hours that link may have false information and stop working altogether. It doesn't even have to wait until the next push happens. Multi-package updates are especially fragile, as a change in any constituent can break all existing links, invalidating browser histories and links in bugzilla and e-mail messages. They also lead to links of incredible length. Perhaps the permanence problem could be solved for the majority of cases if bodhi were to remember the last update with which each n-v-r was associated rather than only the n-v-rs that are currently associated with updates. If the change to links outside of mailing lists will also be reverted, then instances where length matters (e.g. IRC) could be improved by making update IDs in search results and individual update pages into ID-based links so people at least don't have to construct them on their own. Thoughts? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 Final Release Criterion for Xen DomU
On 2011-10-10 12:05, David Nalley wrote: On Mon, Oct 10, 2011 at 2:36 PM, Adam Miller maxamill...@fedoraproject.org wrote: Do any of those cloud providers ever run the stock image or do they roll their own with a custom built kernel anyways? I don't have a lot of insight into this but was just curious what the landscape is looking like out there. I personally think it would be cool to have F16 boot/install as DomU out of the box, but I don't really have a dog in the fight either way... just an idle curiousity. Well at least for Amazon, what is there is what we (Fedora) push up, so it's all Fedora now, with our own kernel. I am sure Max Spevack and Justin Forbes can speak to this more intelligently than I can. You are correct: Fedora's images in Amazon EC2 are composed entirely of software in Fedora's repositories, including the kernel. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: release number when upstream *only* has git hashes?
On 2011-10-04 12:01, Toshio Kuratomi wrote: So my solyution: foo-0-1.20110120git.fc16 vs Your solution: foo-20110120-1.20110120git.fc16 (Since it's a snapshot, the date has to go into the release string anyway) Which is uglier? Also, since these are snapshots, a date in the upstream version field isn't really that great either. Which branch is this from? Which repository (in the case of DVCS)? With respect to a package's n-v-r, it doesn't matter which repository one's checkout of a given git commit comes from. One of git's main tenets is that a given hash refers to the same object in every repository in which it exists. Git commit hashes are also independent of the branches (if any) that point to them. With respect to recording source URLs, we already require commentary with a list of commands when people pull sources directly from version control. This will necessarily include a URL for the appropriate git repository. Now do we want to put the git hash into the version field too? For the package's n-v-r alone to uniquely refer to a given commit it *must* contain the hash in a case such as this. To comply with packaging guidelines it also needs to contain a date and the string git. This means it would need to contain 20111005git0123456. (I would also posit that the date is unnecessary, as it may not identify a unique commit, but that is a topic for another thread.) If upstream is shipping releases where they put dates in as their versions (as some fonts do) you might be able to make a case for this. In this case, though, I don't think this is really a place to create our own release string and put it in the field reserved for the upstream version. +1. I specifically suggest foo-0-1.20111005git0123456.fc16. Doing so will do a number of useful things: * A version of 0 is a clear signal that upstream does not use traditional version numbering. * A version of 0 provides a natural upgrade path if upstream later chooses to start using traditional version numbering. * Including the git hash makes the n-v-r alone refer to unique code. * It does not duplicate information. * It requires one to bend the fewest packaging guidelines. (One is only filling the Version field with an obvious placeholder) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: unison formal review
On 2011-09-28 14:15, Kevin Fenzi wrote: On Wed, 28 Sep 2011 22:00:40 +0100 Richard W.M. Jonesrjo...@redhat.com wrote: I was thinking of something slightly simpler: a single 'unison' package that contained several binaries, like /usr/bin/unison227, /usr/bin/unison (symlink to latest). That does help with needing re-reviews and names and such, but it doesn't help in that you have to update everything everytime a new version comes out. One build could produce a package for each version. The packages' n-v-rs could then be maintained independently. I am not sure how bodhi would behave in such a case, though. This most certainly is not optimal; I'm simply throwing the idea over the wall. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
grub1 support in grubby
Given the grub1/grub2 discussion that is going on, I could use some info about the state of grubby's support for grub1. The virtual machine images that the Cloud SIG publishes on Amazon EC2 do not require bootloaders, but they do require valid grub1 *configuration files* to start. So while these images will survive grub1's eventual retirement, they will still need grubby to support grub1 configuration files for the foreseeable future so kernel updates can continue to work correctly. Is that realistic? Are there currently any plans to kill off grubby's grub1 support at some point? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
systemd not in critpath
Neither bodhi nor mash appears to consider systemd to be in the critical path. Why is this? Is that the way we want it to be? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RPM version goes backward in Rawhide
On 2011-08-19 20:41, Kevin Kofler wrote: Updates can be pulled out of updates-testing at any moment, which makes a lot of sense, but which means that users with updates-testing enabled will end up with the EVR going backwards, something that's not even allowed in Rawhide. Enabling updates-testing by default means forcing EVR downgrades on users of Branched by default, making the policy banning them in Rawhide totally pointless. The problem is that basically nobody is testing the actual release package set, considering that it's much less straightforward to opt out of updates- testing than to opt in, and that probably only few people are doing it (and those who do bother to explicitly opt out of updates-testing are the ones who just need early access to the releases for whatever reason, e.g. because they need a newer version of some package, and don't actually want to do any testing whatsoever, just to seamlessly move on to the release when it's out officially). FESCo discussed both of these issues before the release of the Fedora 15 Alpha at its meetings on 16 Feb 2011 and 2 Mar 2011. The current recommendation [1] is to run ``yum distro-sync'' after upgrading from pre-releases to the final release. [1] https://fedoraproject.org/wiki/Upgrading_from_pre-release_to_final#After_updating_to_final.2C_why_does_yum_complain_about_mismatched_package_versions_even_though_my_rawhide_repo_is_disabled.3F -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Defining build options based on available compiler version
On 2011-07-30 9:44, Jussi Lehtola wrote:
I tried using
%global gccver %(gcc -dumpversion)
%if %{gccver}= 4.6.0
foo here
%endif
to conditionalize usage of quadruple precision support in a spec file
that ships on multiple distros, but the comparison gives the error
parseExpressionBoolean returns -1
Is there a way to check if the gcc version is sufficient with some rpm
macro?
RPM 4.7 and later let you use a bit of inline Lua to do this:
%if %{lua:rpm.vercmp('%{gccver}', '4.6.0')} 0
This has the benefit of neither comparing lexically nor dragging in
extra build dependencies.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Starting user UIDs at 1000 - please check your packages
On 2011-07-20 9:18, Miloslav Trmač wrote: On Wed, Jul 20, 2011 at 6:15 PM, Benjamin Lewisben.le...@benl.co.uk wrote: Out of curiosity, how does this affect existing systems which have human UIDs of 500, 501, etc..? Do they suddenly become system UIDs or is login.defs left alone then (and consequently no change happens)? login.defs is %config(noreplace), so nothing is changed for existing systems. I was under the impression that few users edit login.defs. Won't a package update replace it when it hasn't been manually changed? Maybe I'm missing some important bit of information... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security updates for Firefox 4 in F-15
On 2011-06-26 12:33, Christoph Wickert wrote: And I have no idea what part of our update policy should be violated by this update. Please somebody enlighten me. This part: * Avoid changing the user experience if at all possible. Specifically, the update breaks a number of user-installed extensions because the extensions expect a certain version string. This is a functional regression regardless of whether or not the extension API changed. Please do not misconstrue this message as a value judgment. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are 3.0 kernels working for anyone?
On 2011-06-11 12:11, Lucas wrote: Actually it does relabel by it self after boot with option selinux=0 That sounds rather useful. How does it know whether or not it was previously booted with selinux=0? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
On Fri, Jun 10, 2011 at 12:11 PM, Richard W.M. Jones rjo...@redhat.com wrote: Customers ask us to make the changes they want -- for server use and scalability -- and KVM is absolutely the best in that area as a result. See many recent benchmarks. Usability on single desktops is, well ... we do our best. If you want excellent desktop usability, then organize a group and make the work and patches happen. Why would many prospective contributors choose to work on KVM's desktop usability when VirtualBox's is already superior? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package Reviews Needed
On 2011-06-06 11:17, Tom Callaway wrote: As usual, I will swap reviews or favors (within limits) for reviews on some new packages for me: mono-reflection: https://bugzilla.redhat.com/show_bug.cgi?id=711181 pyrit: https://bugzilla.redhat.com/show_bug.cgi?id=691894 gambas3: https://bugzilla.redhat.com/show_bug.cgi?id=710203 As soon as I clarify the licensing, I will also have gnome-shell-extension-pidgin up for review. I can have a look at pyrit. I need to iron out some issues with my next package submission before I can ask anyone to review anything for me, though. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UID_MIN GID_MIN changed
On Wed, May 25, 2011 at 1:14 PM, Simo Sorce s...@redhat.com wrote: On Wed, 2011-05-25 at 20:04 +, Jóhann B. Guðmundsson wrote: reserved/system IDs are supposed to be once that has been done we can start looking at what is the best approach to implement and or fix things that might break because of it. Changing the reserved id space should break only new allocations on systems that may have used the newly allocated IDs already. The only way to fix that is to have the admin manually intervene after the error is brought to his attanetion. This affects more than just the space between the old and new SYS_UID_MIN. How will you ensure that accountsservice/gdm/etc continue to enumerate preexisting user accounts with UIDs that are now below UID_MIN? Can this be done while simultaneously preventing system accounts in the new range from showing up? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Some changes to EPEL package reviews
On 4/29/2011 9:12, Jesse Keating wrote: It is somewhat difficult, and odd, to create a git repo that does not have a master branch. It would be a little more odd to potentially at some point in the future create the master branch for a package should it find a home within Fedora. As you say, this practice is somewhat unusual, but it is not difficult. It takes but a single easily-scriptable command prior to the first commit to change the name of the initial branch. Since Fedora's repo creation scripts already do an initial commit in every new package repository this should not be difficult to add to that process. Creating a master branch where none existed would primarily be a matter of deciding which existing branch to branch the new master branch from. This part should only be difficult to do programmatically if the desired preexisting branch is not the initial one that the repository's first commit was created on. There need not be much/any content in the master branch, but there should still be one for each package. For the sake of code simplicity, I agree: every repo ought to have a master branch. Having one omnipresent branch lets Fedora's repo management scripts make some very useful assumptions. (Yes, this opinion flies in the face of my previous statements.) ;-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Some changes to EPEL package reviews
On 4/28/2011 13:25, Bill Nottingham wrote: EPEL now has a 'Package Review' component in bugzilla. If you've got an EPEL-only package you'd like to get reviewed, feel free to file it there. How is this any different, given that process-git-requests creates a rawhide branch without regard to whether one asks for it or not? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora SPEC Review Tool
On 4/6/2011 11:11, Jeffrey Ness wrote: As I'm new to the community and RPM Package Review (and development), I figured a tool to assist with reviews would be a nice time saver. With that said I have a simple Python tool (still in early beta stages) which does just that. Keeping with the concept of sharing, I wanted to hand this tool out to the community and get any feedback from y'all: https://github.com/jness/spec_checks This tool uses the Package Review Guidelines written by Tom 'spot' Callaway: http://fedoraproject.org/wiki/Packaging/ReviewGuidelines I was expecting some sort of automated spec file / RPM checker, but it turned out to essentially be a checklist program. I guess I should have read the readme first. ;) On that note, one thing that could improve it would be making it capable of automatically providing relevant information to the reviewer. Printing source file checksums, for instance, would be a small, but relatively easy thing of this nature to do. The review guidelines include the packaging guidelines by reference. Your program does not. Though the packaging guidelines tend to leave more up to reviewers' discretion, they might still be worth including, at least in part. If it helps, several people posted wiki pages with the lists of things that they look for when reviewing packages. AFAIK mine is up to date and fairly exhaustive, if you're interested in a starting point: https://fedoraproject.org/wiki/Gholms/review_template I hope at least some of that feedback helps. Anything that makes reviewing easier is a good thing, so thanks for sharing your work! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-15 Branched report: 20110325 changes
On 3/25/2011 17:38, Branched Report wrote: Compose started at Fri Mar 25 13:15:31 UTC 2011 An empty list? Quick, ship it! In all seriousness, did something go wrong with the compose or are there actually no depsolving problems? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git repository with Fedora kernel(s) sources
On 2/25/2011 7:19, Michał Piotrowski wrote: I've got an interesting idea - why not to provide a git repository with the sources of current Fedora kernel? This could simplify the maintenance of patches, allows other to easily backport stuff from kernel.org's master and greatly improves the current situation with transparency of development process. I mean I almost sure that Fedora Kernel team uses git internally, so why not to allow others to fork it? git://pkgs.fedoraproject.org/kernel That repository has the spec file and build files; he means using git for the kernel sources themselves. Rather than keeping a stack of patches and porting them forward all the time, one can instead keep Fedora's patched kernel sources in a git repository and then include kernel-2.6.38-1.1.fc15.tar.bz2 in the source RPM instead of vanilla kernel-2.6.38.tar.bz2 and fifty patches. Red Hat appears to do this with RHEL 6's kernel, but their kernel repository is not publicly-accessible. While I can see how this might make things a bit easier, it can obscure what commits are Fedora-specific as they are lost in the sea of the upstream kernel's commits, making me firmly against the proposal. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Services that can start by default policy feedback
On 2/24/2011 8:14, Lennart Poettering wrote: Some people have been asking us to extend the systemd unit file header to include information about whether a service should be on or off by default (Michal!), like chkconfig had it. But after thinking about this we came to the conclusion that this information is not specific to services at all, but to the distro image you install, and hence has no place in the unit files. Ideally unit files are shipped along the upstream sources, and whether a service is enabled by default is not an upstream decision, but genuinely one not only of the distro but by the particular distro profile installed. Hence the place to encode this information is not the upstream shipped unit files and not packaging spec files, but other distro specific list. So whether or not a given package will be enabled by default after I tell yum to install it depends on which spin, if any, that I initially installed my system with? Why should the initial package set that my system came up with have any effect at all on what happens when I install something new? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg build version numbering discrepancy
On Thu, Jan 27, 2011 at 3:56 PM, Thomas Spura toms...@fedoraproject.org wrote:
On Thu, 27 Jan 2011 18:46:34 -0500
Jean-Marc Pigeon wrote:
rversion=2.1
subversion=400
Spec file extract:
Version: %{rversion}.%{subversion}
Release: 2%{?locmark}
Source: ./%{name}-%{version}.tar.gz
So the potential for disasters is real?
It would help to know which package this is about. :)
It looks like the clement package, whose maintainer should reread
the packaging guidelines for packages with svn revisions as part of
their e-v-r combinations.
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#NonNumericRelease
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg build version numbering discrepancy
On Thu, Jan 27, 2011 at 6:23 PM, Jean-Marc Pigeon j...@safe.ca wrote: Ok, this means having an uptodate sources file is not mandatory. I pushed the tar file in same time as spec to GIT, koji was smart enough to forgive my error. So I can work one way or the other... right? While it will technically work, uploading tarballs and other binaries to git is a bad idea. git behaves very badly with larger files such as 524 KB tarballs because they clutter or obfuscate commit diffs and they remain in the repository's history forever, making every clone of the git repository take substantially more time and network traffic to create. So if at all possible, please do not upload your tarballs to git, but rather use the sources file. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc 4.6 for package monkeys
On 1/27/2011 23:26, Julian Sikorski wrote: I have just run into an issue with gcc-4.6, namely RPM Fusion's mame failed to compile [1]. I was told that #includestddef.h was missing. So I have two questions: why did including this header directly became necessary (code builds fine with 4.5) and are there any other issues we package monkeys might run into with a new compiler? GCC 4.6 changed a lot of compiler warnings to errors, so a lot of code (especially C++ code) that used to get away with violations like omitting headers or assigning to un-assignable things will now fail to build. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
@core in F14 pulls in libX11
It seems that the core yum group pulls in X11 libraries, at the very least on x86_64, via the following dependency chain: policycoreutils dbus-glib gobject-introspection cairo libX11 Does that much seriously need to be in what we consider a bare minimum Fedora install? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Tue, Jan 4, 2011 at 4:31 PM, Bernie Innocenti ber...@codewiz.org wrote: What sort of attack would this enable? Wait... any unprivileged process can create sockets in the abstract namespace? Uh-oh. Any unprivileged process can prevent you from running X on a given display by using up the socket name that X wants to use. This is a textbook DOS scenario. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On 12/14/2010 21:28, Lennart Poettering wrote: On Tue, 14.12.10 12:08, Bill Nottingham (nott...@redhat.com) wrote: Thanks, Bill, for replying in so much detail. Here are a few other points: - systemd mounts API filesystems without them needing to be in /etc/fstab. This is for a variety of reasons - having every system installer have to write /proc, /sys, and so on is pretty wasteful. It also can give inexperienced admins the idea that it's configuration that can be changed - they then rename the mount point from /proc to /processes and *kaboom*. The main reason we mount /sys and /proc and friends in C code this early is that we simply need them ourselves. To do what systemd does, it must be able to rely that it can read process data from /proc, or device information from /sys, or cgroup information from /sys/fs/cgroup. There is simply no way around this, and just to make a point, Upstart mounts some of those FS too, in C code (however not /dev/shm), there's very little effective difference here, and if people whine and say things have never een done this way, you a are breaking UNIX, then I can only reply, that that's simply wrong. Having said all this I actually believe that there is very little point in listing API file systems like these in /etc/fstab. They are after all API, hence only relevant for application code, not really useful for direct interaction or even reconfiguation by the user. Or in other words: While it definitely makes sense to ount /dev/sda5 to whatever mount point the user chooses, the mount point and options for the API file systems are pretty much an implementation detail for the OS, and there should never be a need to change them. In order to make things secure we minimize what is allowd on the various API file systems we mount. That includes that we set noexec and similar options for the file systems involved. The interface how to access /dev/shm is called shm_open(), and given that this is how it is there is very little reason to allow people to execute binaries from them. Of course, this is a very recent change, and at this point while we assume that this will not break any valid use of this directory, we cannot be sure about this, so we'd be very interested to learn why exactly you want the noexec to be dropped. What is your application that needs that? If there is a point in dropping the noexec, we'll definitely be willing to do so, but if the only reason would be I always misused /dev/shm as a scratch space, then we won't be very convinced. The API fom /dev/shm is shm_open(), and if you place other stuff in there, then you are misusing it and actually creating all kinds of namespacing problems (since /dev/shm is actually an all-user shared namespace), and we aren't particularly keen to support such misuses by default. That said, because we anticipated that there are some valid uses to change the settings of these mount points (e.g. change size= for tmpfs) we actually do apply the options from /etc/fstab, if the file system is listed there. So if you really really want to misuse /dev/shm, you may. Apparently this particular feature was broken (see Bill's comments), and hence please file a bug about this. I'm fine with that as long as it is documented, particularly in the fstab man page and as commentary in /etc/fstab on newly-installed systems so people who read it and notice missing filesystems don't panic. Thanks for explaining your thought process. It sounds like /tmp would be a better location to remove noexec from than /dev/shm if one needs memory-backed storage for things and doesn't want to create a new filesystem for that purpose. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On 12/13/2010 7:37, Karel Zak wrote:
On Sun, Dec 12, 2010 at 07:49:27PM -0800, John Reiser wrote:
How did /dev/shm get noexec in Fedora 15 rawhide?
$ grep /dev/shm /proc/mounts
tmpfs /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
$ grep -srl noexec /etc
/etc/alternatives/ld
/etc/fstab ## derived from /proc/mounts
/etc/mtab## derived from /proc/mounts
This is a change from Fedora 14, and I cannot find documentation.
The only 'noexec' that I can find in the source to systemd-15
is two mentions in units/var-{lock,run}.mount.
the MS_NOEXEC flags is in private systemd fstab, see
systemd/src/mount-setup.c:
static const MountPoint mount_table[] = {
{ proc, /proc, proc, NULL,
MS_NOSUID|MS_NOEXEC|MS_NODEV, true },
{ sysfs,/sys, sysfs,NULL,
MS_NOSUID|MS_NOEXEC|MS_NODEV, true },
{ devtmpfs, /dev, devtmpfs, mode=755,
MS_NOSUID,true },
{ tmpfs,/dev/shm, tmpfs,mode=1777,
MS_NOSUID|MS_NOEXEC|MS_NODEV, true },
{ devpts, /dev/pts, devpts, NULL,
MS_NOSUID|MS_NOEXEC, false },
{ tmpfs,/sys/fs/cgroup, tmpfs,mode=755,
MS_NOSUID|MS_NOEXEC|MS_NODEV, true },
{ cgroup, /sys/fs/cgroup/systemd, cgroup,
none,name=systemd, MS_NOSUID|MS_NOEXEC|MS_NODEV, true },
};
As a site administrator, how can I change the default to omit 'noexec'?
mount -o remount,exec ?
If systemd is going to ignore fstab entries, could we please have the
fstab file on newly-installed systems replace the entries that would be
ignored with commentary that explains which filesystems will be ignored?
That said, this should really be configurable without recompiling the
init system.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
Mamoru Tasaka wrote: So, when a package - contains some example scripts - the packager thinks that such scripts are useful and many people actually want to execute them - but such scripts need additional dependencies then the packager actually may want to add additional dependencies. Irrespective of files' usefulness or purposes, it seems like an incredibly bad idea for a package to Provide any files that, because they are %doc files, may not even get installed on target systems. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed package blocking due to FTBFS
On 12/6/2010 23:01, Matt Domsch wrote: I would like to propose blocking packages at the F15 alpha compose point if they have not resolved their FTBFS from F14 or earlier. The lists may be broken down by when they last did build. With 3 exceptions, these 110 bugs are all still in NEW state as well, so they haven't had much maintainer love in quite some time (6-18 months). Is the policy we already have for this [1] insufficient or merely unenforced? [1] http://fedoraproject.org/wiki/Fails_to_build_from_source#Package_Removal_for_Long-standing_FTBFS_bugs -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Request for comment: Potential change to dist-git branch structure
On 12/3/2010 18:34, Jesse Keating wrote: The original thought was to have top level branches that are named after distribution releases, eg f14, f15, el5. Then we would force branches of those branches use a naming structure of f14/topic. The reason was so that our tooling could look at the name of the branch and easily work back to the f14 part. This would work even if it was f14/user/fred/topic/mybranch or other such craziness. When I went to test this, I realized that git won't allow you to have both f14 and f14/topic as branches, because of the way the git metadata works on the filesystem. When I encountered this, I made f14/master become the top level branch, and then f14/somethingelse could coexist. Unfortunately I also wanted to keep things easy for users and tried to maintain tooling that would allow you to just say f14. This didn't get enough real world testing and in hindsight was a bad idea. Things go wrong quickly in git if your local branch name doesn't match the remote branch name. When thinking about the above, and the two bugs I'm working on, I realized that we don't have any real strong need to be using / as a delineator. It makes some code easier, but makes other things more complex and difficult. So what if we changed it? What I'm thinking about now is switching from / to - as a delineator. This would improve a couple things. First, we could achieve upstream top level branch names that are short and simple: f14, f15, master. We can have branches that build upon those names: f14-rebase, f15-cve223, f15-user-jkeating-private. We could keep the simple fedpkg tooling that allows users to just type f14 and the like to reference a branch, and now the local branch will match the name of the remote branch. Yes, please! Getting rid of the '/' strangeness ought to make things a little easier to understand and use across the board. I suspect that few enough packages use shared feature or bugfix branches that a transition won't trip up very many people. Perhaps a hook on Fedora's repositories that prints transition instructions when one attempts to push to old-style branches in conjunction with a fedpkg command that attempts to migrate existing local branches and remotes would help somewhat. As for the first two bugs I mentioned, it doesn't directly help them. However I would feel better about telling people that their local branches must follow a naming scheme ofrelease-something and then we could easily guess what release the local branch is for if it isn't tracking a remote branch. However the bug about what to do if there are no remote branches is really not touched by any of this, it just got me thinking about branches :) Why tie branch names down to specific releases? While that scheme makes it easy for fedpkg to guess what release to attempt to build against when one only cares about one release, it makes little sense to call a branch f14-rh123456 when in reality that branch will merge into f13 as well as f14. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates Criteria Summary/Brainstorming
On 11/21/2010 17:51, Björn Persson wrote: Andre Robatino wrote: My feeling is that it would be better for Bodhi to always require a login. Even Bugzilla does that. I suspect that a lot of people who give anonymous karma don't realize that it doesn't count, and would have created an account if they did. And using an account allows people to build a reputation, which is useful in case Bodhi is ever besieged by malicious comments and is forced to disable some accounts, or disable anonymous comments completely. Having a single account for all of Fedora including Bugzilla ought to help somewhat. Anyone who has taken the trouble of reporting a bug could then easily give karma in Bodhi. Separate accounts seems like an unnecessary obstacle to me. +1, though something tells me making it happen would take nothing short of a heroic effort. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 11/18/2010 8:09, Dominik 'Rathann' Mierzejewski wrote: On Monday, 15 November 2010 at 12:29, Richard W.M. Jones wrote: [...] This is a silly straw-man. No one[1] formats external HDs with anything other than MS-DOS FAT. Fedora changing the default for the main hard disk will not make any difference to this case of your contrarian user giving away LVM-formatted USB drives. I'd think NTFS would be much more common, if only for its ability to store files larger than 4GB. UDF can be a useful alternative since Windows = Vista, RHEL = 5, and Fedora handle it perfectly. Windows XP can read it. OS X can also use it read/write, but you have to manually mount it first. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: build rpm packages such as Redhat/Fedora
On 11/13/2010 18:15, Christopher Stolzenberg wrote: yum install mock useradd mockbuild usermod -G mock mockbuild Unless you want to ``su'' to a dedicated mockbuild account every time you want to build you should add your usual account to the mock group instead. mock rebuild -r epel-6-x86_64 /home/mockbuild/kernel-2.6.32-71.7.1.el6.src.rpm Mock typically grabs packages from CentOS, so until CentOS 6 is out you're going to have to build using RHEL 6. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On 11/6/2010 11:28, Dennis Jacobfeuerborn wrote: As for the if all apps are ported to Wayland I will not be able to use them remotely anymore I think this is bogus. Nowadays virtually all application aren't X application but gtk/qt applications and the toolkits tend to support different backends. So you will be able to use your apps as long as the toolkits support X and I think that's going to be a long time unless Wayland is dramatically successfull. Does this sort of portability make any difference in a distribution where package maintainers make that decision at compilation time? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package review template
On 11/1/2010 9:32, Jean-Francois Saucier wrote:
I just put my package review template on my wiki space at :
https://fedoraproject.org/wiki/User:Jfsaucier/Review_Template
[ ] SourceX is a working URL.
[ ] SourceX / PatchY prefixed with %{name}.
[ ] Final provides and requires are sane (rpm -q --provides and rpm -q
--requires).
[ ] %check is present and all tests pass.
[ ] Latest version is packaged.
Where do these come from? I understand why they're useful and all, but
I'm not sure what guidelines recommend them.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default partitioning
On 10/29/2010 14:37, David Cantrell wrote: (1) For VGs= 50 GB, we will continue to make swap and / as normal. (2) For VGs 50 GB, / will cap at 50 GB and /home will consume the rest. 50 GB is fairly arbitrary, and was based on the fact that an Everything install of Fedora right now is ~ 40 GB, plus some room for expansion. Very few users are likely to do an Everything install so this should provide plenty of space for upgrades and future growth. Additionally, this is only a default partitioning suggestion and can always be overridden by the user. We discussed how /home would be created during automatic partitioning and based on the feedback from many people, the above algorithm was determined. So, the odd 4GB /home in your case is most likely due to your disk being on the 50GB line. If you want to keep defaulting to a separate /home partition, how about doing so only when the disk is above a larger size such as 80 or 100 GB? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: who broke fedoraproject.org usability?
Chris Adams wrote: Once upon a time, Tom spot Callaway tcall...@redhat.com said: Also, it is worth noting that the new website makes heavy use of Javascript, so if you have NoScript (or equivalent) running, you'll not get a good view of the site. :) Yeah, apparently that was the problem I was seeing. Honestly, making a site that looks broken with NoScript is a bad idea, especially for a user base that probably has a higher-than-average number of Firefox users (and probably mode advanced users that are likely to use things like NoScript). Requiring JavaScript just to get the correct layout is IMHO broken. I opened a ticket about that a little while ago if anyone is interested in following the issue. https://fedorahosted.org/fedora-websites/ticket/30 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i686/x86_64 dual install media
Thorsten Leemhuis wrote: But a combo x86-32/x86-64 install media OTOH would be very interesting for magazines that want to ship Fedora on a enclosed DVD, as that's cheaper than two and makes way more readers happy than a x86-32 only DVD. Ohh, and a combo install media might be interesting as hand out for fairs and conferences, too. What I would like to see is a regular net install CD (not b.f.o) that is capable of installing either x86_64 or i686. I'm not sure if it's worth the work, though... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: policycoreutils needs cairo.
Peter Robinson wrote: On Mon, Oct 25, 2010 at 11:52 PM, Adam Williamson awill...@redhat.com wrote: On Mon, 2010-10-25 at 17:55 -0400, Bill Nottingham wrote: Colin Walters (walt...@verbum.org) said: On Mon, Oct 25, 2010 at 5:21 PM, Colin Walters walt...@verbum.org wrote: Unfortunately we didn't notice this dependency until pretty late in F14...I'm not sure what can be done reasonably at this point, since all of these packages are critical path. Though I will say that if this was determined to be a blocker, here's a really safe minimal fix: AFAIK, there's nothing on the release criteria which make this a blocker. You can submit an update whenever for it, of course. It's worth pointing out that we're not religious about the criteria: we want to have criteria to cover each blocker issue, but that doesn't mean that no issue can ever be a blocker unless it meets the existing criteria. When we come across an issue that is widely agreed ought to be a blocker, but doesn't meet the existing criteria, we write a new criterion. :) Having said that, I don't think this seems serious enough to be a blocker, though obviously we'd like the minimal install to be as minimal as possible. Does it cause major problems for any spins? I doubt it, I expect most of them will have cairo for one reason or another anyway. I wouldn't expect it to affect the usual spins on s.fp.o, but the image for EC2 might be as I would expect that to be aimed at Just Enough OS but then I'm not sure how stripped down they've tried to make it. While we (the Cloud SIG) are shooting for a very minimal EC2 image, last I heard we still planned to ship it with SELinux. But if that isn't the case then I'm pretty sure this will impact the size of the images we need to upload. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: i686/x86_64 dual install media
On 10/24/2010 9:45, Mark Bidewell wrote: Sorry if this has been discussed, but has there every been discussion of a dual 32/64-bit install media? I realize that the default package selection would be reduced but with a high speed connection it shouldn't be too big of an issue. Having a single ISO for both my 64-bit desktop and 32-bit laptop would be quite nice. If you have a high-speed Internet connection perhaps you should try a boot.fedoraproject.org CD, USB stick, or other medium. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-14 Branched report: 20101024 changes
On 10/24/2010 10:17, Branched Report wrote: Broken deps for x86_64 -- qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) rakudo-0.0.2010.08_2.7.0-1.fc14.x86_64 requires libparrot.so.2.7.0()(64bit) Any chance these are going to be fixed before release? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
Bill Nottingham wrote: Somewhere in the recesses of my memory I remember a UNIX where /bin, /lib, and so on were just symlinks to /usr/bin, /usr/lib, and so on. Tru64 (Yes, it's still supported!) does: gho...@seraph ~ % uname -a OSF1 seraph.tetraforge.com V5.1 2650 alpha gho...@seraph ~ % ls -l /bin /lib lrwxr-xr-x 1 root system 7 Apr 21 2010 /bin@ - usr/bin/ lrwxr-xr-x 1 root system 7 Apr 21 2010 /lib@ - usr/lib/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git commit in all available branches
Paul Wouters wrote: On Fri, 8 Oct 2010, Pavel Alexeev (aka Pahan-Hubbitus) wrote: After made some changes in origin/master and commit is I also must do for each available branches something similar: fedpkg switch-branch el5; git pull git merge origin/master git push fedpkg build fedpkg update Does that not mangle the changelog of the different branches? Only if they diverge after they have been initially merged. If every branch is the same it makes history easier to track. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Yubikeys are now supported
On 10/7/2010 12:04, Mike McGrath wrote: http://fedoraproject.org/wiki/Infrastruture/Yubikey ^^ Typo alert! ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Passing arguments into LDFLAGS
Stephen Gallagher wrote: On 09/22/2010 08:08 AM, Paul F. Johnson wrote: I know I can do the likes of export CFLAGS=$CFLAGS -blah and it will pass whatever CFLAGS is plus the argument -blah to the compiler. How do I do this with LDFLAGS. I'm trying to pass --build-id using export LDFLAGS=$LDFLAGS --build-id It's about the only way I can get mono to build currently! TTFN Paul Try export LDFLAGS=$LDFLAGS -Wl,--build-id - -Wl, means pass the part after the comma directly to the linker This. When gcc is used to indirectly call ld, it won't always pass the $LDFLAGS to the linker. To force it to you have to use the -Wl switch and replace all spaces in the switch with commas. For example: LDFLAGS=-Wl,-O1 -Wl,--sort-common -Wl--build-id -s -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Bodhi, and odd error pushing a package update to testing
On 9/20/2010 16:41, Michel Alexandre Salim wrote: On Mon, Sep 20, 2010 at 11:30 PM, Fedora Koji Build System build...@fedoraproject.org wrote: Package: Miro NVR: Miro-3.0.3-2.fc13 User: bodhi Status: failed Tag Operation: untagged From Tag: dist-f13-updates-testing-pending Miro-3.0.3-2.fc13 unsuccessfully untagged from dist-f13-updates-testing-pending by bodhi Operation failed with the error: koji.TagError: build Miro-3.0.3-2.fc13 not in tag dist-f13-updates-testing-pending Might this have to do with the deployment of the new Bodhi? Bodhi still thinks the update has not been pushed to testing: https://admin.fedoraproject.org/updates/Miro-3.0.3-2.fc13 but Koji already has the package tagged dist-f13-updates-testing: http://koji.fedoraproject.org/koji/buildinfo?buildID=196032 I see something similar with my latest round of stable pushes: Package: euca2ools NVR: euca2ools-1.3.1-1.fc13 User: bodhi Status: failed Tag Operation: untagged From Tag: dist-f13-updates-pending euca2ools-1.3.1-1.fc13 unsuccessfully untagged from dist-f13-updates-pending by bodhi Operation failed with the error: koji.TagError: build euca2ools-1.3.1-1.fc13 not in tag dist-f13-updates-pending -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg workflow and release numbers
On 9/19/2010 9:40, Christoph Höger wrote: Hi all, since I keep offlineimap the same version for the latest stable (that I got my hands on) + devel versions, my fedpkg workflow looks like: 1. master build package 2. f14 git pull origin master fedpkg push fedpkg build ... 3. f13 git pull origin master fedpkg push fedpkg build ... I think this is how git should be used in that case (no difference between all branches). But this means taking the release number from step 1 through all steps (e.g. building offlineimap-6.2.0-2.fc14 without ever building offlineimap-6.2.0-2.fc14). Is that ok in terms of fedora package policies? It sounds like you're doing more work than you have to if all the branches are the same. Why not just run ``git merge'' on the other branches? Here's what I generally do: * git checkout master; edit files; git commit ...; git push * git checkout f14; git merge master; git push * git checkout f13; git merge master; git push * (...and so on for the other branches) * koji build --nowait dist-f15 'git://pkgs.fedoraproject.org/pkgname?#199d3785f44e4f4d0005e2670b1e58179b290c95' * koji build --nowait dist-f14-updates-candidate 'git://pkgs.fedoraproject.org/pkgname?#199d3785f44e4f4d0005e2670b1e58179b290c95' * (...and so on for the other branches) Koji doesn't care what branch a given hash comes from since either you or fedpkg will specify a target when calling it, so having several branches at the same commit is not a problem. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yet another git problem
Roman Rakus wrote: On 09/16/2010 04:21 PM, Neal Becker wrote: Updating igraph to 0.5.4. Success for devel and f14. Then for f13 I get: fedpkg switch-branch f13 Branch f13 set up to track remote branch f13/master from origin. git merge master CONFLICT (rename/delete): Rename .cvsignore-.gitignore in HEAD and deleted in master Automatic merge failed; fix conflicts and then commit the result. Strange, that seems to be the same thing I did for f14. How do I fix? What are you trying to do? I guess `git cherry-pick' will work for you. Or you can just resolve the merge conflict yourself. You only have to merge the disparate branches once. :-\ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedpkg prep
Andreas Schwab wrote: Matt McCutchen m...@mattmccutchen.net writes: I propose that fedpkg should consider a --dist option, a branch file, and the name of the current git branch in that order. Or make it a branch config (eg. git config branch.$branch.dist f14). This, please. Using magical branch names or files to decide what release a branch corresponds to seems silly when it can be a property of the branch itself. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphan packages retired for F-14 (and rawhide)
On 8/27/2010 2:03 PM, Bill Nottingham wrote: In accordance with the normal process, the following packages have been orphaned for Fedora 14 and rawhide. Will packages with untouched FTBFS bugs also be removed like the normal process dictates? http://fedoraproject.org/wiki/FTBFS#.28Proposed.29_Package_Removal_for_Long-standing_FTBFS_bugs -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
Kevin Kofler wrote: We probably need to attack this trend more aggressively, like putting expiration dates into the installer after which it'll just refuse to install, stuffing fedora-release-n+1 into the Fedora n updates repository at Fedora n's EOL date etc. Not only is this disingenuous, but it also contradicts Fedora's Freedom policy. Adding a big fat warning message to the installer, however, is much less of a problem and gets the message across just as effectively. Just make sure that the expiration date is far enough out in the future that we can be certain that it will occur after the release's EOL date since we don't know when that will be at the time of image creation. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop default MTA for Fedora 15
On Aug 26, 2010, at 13:50, Adam Williamson awill...@redhat.com wrote: On Thu, 2010-08-26 at 20:30 +0200, Krzysztof Halasa wrote: Jon Masters jonat...@jonmasters.org writes: What's the benefit of having no default MTA at all? Is it that Desktop users don't care about MTAs being installed? what about those of us who care more about server installations than Desktop? I have desktops with no MTA. I can read mail on them using remote pop3/imap (with ssh), sending mail also uses ssh and /usr/sbin/sendmail on remote machine. Alternatively, SMTP to a smarthost. Plays nicely with e.g. Emacs/Gnus. There is absolutely no need for a local MTA there. That wasn't the question. The question was what is the benefit of not having one. Is it simply that it saves 1.6MB of disk space? If so, uh, woop? While it may be debatable what benefit one might get from removing it from the default install, can we at least remove MTAs from @core to help make things easier for appliance folks? One can still go in @base, which would make it continue to appear on all but the most minimal of installs. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora mission (was Re: systemd and changes)
On 8/26/2010 11:53 PM, Michal Hlavinka wrote: On Thursday 26 of August 2010 21:21:53 Garrett Holmstrom wrote: Kevin Kofler wrote: We probably need to attack this trend more aggressively, like putting expiration dates into the installer after which it'll just refuse to install, stuffing fedora-release-n+1 into the Fedora n updates repository at Fedora n's EOL date etc. Not only is this disingenuous, but it also contradicts Fedora's Freedom policy. Adding a big fat warning message to the installer, however, is much less of a problem and gets the message across just as effectively. Just make sure that the expiration date is far enough out in the future that we can be certain that it will occur after the release's EOL date since we don't know when that will be at the time of image creation. I don't think it should be far enough. It should be some time before EOL happens. What's the point installing and configuring new system that will EOL tomorrow / after one week? But still... +1 to warning message in the installer At the time the install images are composed the release's EOL date has not yet been decided, so we would be stuck with guessing a date and hoping it will be somewhat close. Fedora releases are either Supported or Unsupported. Unless the community wants to define some third, Sort-of-supported state then there should be no functional changes in the installer's and repositories' behaviors until after the release goes Unsupported. -- Garrett Holmstrom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Old gdm themes
Why are bluecurve-gdm-theme and fedoraflyinghigh-gdm-theme still in the distribution? The other gdm theme packages were deprecated after F12 (!?!), and I was under the impression that none of them work with new-style gdm at all. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Notifications System.
Jaroslav Reznik wrote: Reading this - I'm not sure all Fedora notifications should go through system notification system. Why? I understand it for urgent/priority notification like Close your desktop, nuclear war out there (or just a security update combined with some steps how to fix it). But I hope it should work for a lot of things like Fedora elections etc. - this should for example go to your calendar, some tips how to use Fedora (just a RSS feed like Plasma widget?) etc. That essentially already exists [0], so just point your existing widgets at that. I personally think that shoving things of this nature in users' faces is not the job of an operating system. [0] http://planet.fedoraproject.org/atom.xml -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: a note on order of arguements to systemctl command
Matthew Miller wrote: The service command has a syntax like this: service servicename action where as systemctl has a syntax like this: systemctl action servicename.service This is inconvienient for the common case where more than one action is performed in sequence on the same service, since with the first ordering, one just hits the up arrow, ctrl-w, and then types the new action (with tab-completion). With the systemctl order, one must first skip back over the first word, which due to the awesome emacsness of bash keybindings is more of a pain. I'm not saying that systemctl's syntax needs to be changed. I am saying, however, that it's important to get the service command working with systemctl so that people can use that instead. I'm of two minds here. On the one hand it would be nice to preserve the long-standing syntax convention for the reason Matt described. But on the other hand, putting the verb before the object seems to mesh well with how the English language usually works. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and filesystems with noauto
Lennart Poettering wrote: So, to turn this around. Do you think this behaviour is problematic? Can you make a good case for dropping this automatism? If so I'd be willing to do so. That behavior might be fine, but don't add filesystems marked noauto to the list of filesystems to be mounted automatically when reading fstab. Here are my use cases and other rationale. I'm sure other people have more: * fstab(5) documents the noauto option * I manually mount network shares that aren't always available with the noauto and user options * Removable media that appear in fstab are usually marked noauto * /boot doesn't always need to be mounted on every distro * I mount large filesystems after the boot process finishes so fscking doesn't pause booting at $dayjob -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and filesystems with noauto
Lennart Poettering wrote: Well, we took the liberty to interpret noauto a little bit differently than you: everything marked auto will be mounted at boot, and boot will not proceed until all devices listed as auto appeared and are fully mounted (or things timed out). File systems marked as noauto won't delay the boot process if they aren't, but they'll still be mounted when they are plugged in, regardless whether that is at boot or during runtime. i.e. auto → wait for this on boot; noauto → don't delay boot for this. This is not a reinterpretation, but rather completely new semantics that differ from existing documentation on a variety of UNIX and UNIX-like systems, including Fedora itself: Fedora: ‘‘noauto’’ (do not mount when mount -a is given, e.g., boot time) FreeBSD: If the option ``noauto'' is specified, the file system will not be automatically mounted at system startup. OpenBSD and Mac OS X: The option ``auto'' can be used in the ``noauto'' form to cause a file system not to be mounted automatically (with mount -A or mount -a, or at system boot time). Please implement noauto as documented and assign these new semantics to another option. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd and filesystems with noauto
Lennart Poettering wrote: On Mon, 23.08.10 10:52, Garrett Holmstrom (gho...@fedoraproject.org) wrote: * fstab(5) documents the noauto option Well, what it says is that noauto results in the -a option will not cause the filesystem to be mounted. And that's still the case. We execute either the real mount -a (or actually something equivalent) at bootup, and that by itself won't cause the fs to be mounted still. mount(8): noauto Can only be mounted explicitly Several other UNIX and UNIX-like systems are much more explicit about this, saying that noauto means that a filesystem will not be mounted at boot time. If you are going to break decades of tradition you not only have to provide good reasons for it, but you also have to update all of the documentation that goes with it. * I manually mount network shares that aren't always available with the noauto and user options That's not the issue here. systemd will never mount non-device mount points automatically, unless listed as auto. That's useful to know, but inconsistent since some filesystems default to auto and others default to noauto. * Removable media that appear in fstab are usually marked noauto And? Systemd should not try to mount them because the administrator explicitly asked for them to *not* be mounted. There is no sense trying to mount a device with no media just because it appears in fstab. * /boot doesn't always need to be mounted on every distro And? Systemd should not try to mount it because the administrator explicitly asked for it to *not* be mounted. If I don't want /boot mounted then the init system must respect that until all of the relevant system documentation changes and a release note mentions the change. * I mount large filesystems after the boot process finishes so fscking doesn't pause booting at $dayjob And? Systemd should not try to mount them because the administrator explicitly asked for them to *not* be mounted. Doing otherwise while ignoring noauto semantics could delay booting for hours if long-running fscks are triggered. Your new auto/noauto semantics aren't documented in important places like fstab(5) and mount(8), so rc scripts that, as per documentation, expect the filesystems they work with to be unmounted will fail. I apologize; I thought my request was clear: please implement auto/noauto in the traditional, documented way, use a different keyword for this new behavior, and document any new semantics or keywords in the relevant man pages and release notes. I think Ubuntu uses bootwait and nobootwait if you need ideas. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RCS keywords rewritten in dist-git conversion?
Paul Howarth wrote: No changes: the heads of the f12, f13, f14 and master branches all point to the dist-git conversion commit. In case it matters, these branches point to two completely separate commits; f12 has an entirely different history from f13, f14, and master as far as git is concerned. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What does the DVD media check if installing a new Fedora version? / Proposal
Joachim Backes wrote: having the following question: What does the DVD/CD media check exactly if booting a Fedora DVD/CD? Is it the sha256sum? If yes, why this media check, because it could be done after having burned the DVD? If not, is it possible to perform this media check immediately after having burned the DVD (means: can I start the media check from that freshly burned DVD?) Part of the point of the media check is to ensure that a disk matches its expected checksum even after the disk itself may have changed due to wear and tear or the passage of time. Adding this functionality to the installer itself makes this sort of check convenient to perform immediately before one uses a disk of unknown quality to install a system. Fortunately, this does not preclude you from checksumming a disk immediately after burning it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Staying close to upstream
Kevin Kofler wrote: * This policy of sticking religiously to upstream means we are not shipping KDE integration for Firefox, despite patches from openSUSE existing. This makes Firefox suck under KDE. Our Firefox maintainers refuse to do anything about it. What reason does upstream give for not accepting said patches? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HEADS UP! Ohloh Fedora repositories
On 8/12/2010 9:16, Peter Lemenkov wrote: I'm currently in process of automatic enlisting of all ~10K Fedora Git repos at Ohloh. Do you have some way of automatically adding new packages as they are added to Fedora in the future? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
