Re: Announce: fedostree/rpm-ostree v2014.3
Hi Dennis, On Tue, 2014-01-21 at 07:40 +0100, Dennis Jacobfeuerborn wrote: > Interesting. I've downloaded the VM Image and tried to understand the > setup. Some bits are documented here https://people.gnome.org/~walters/ostree/doc/layout.html > Apparently there exist sort of two root trees / and /sysroot in > the system with some links targeting the /sysroot tree. With OSTree, you boot directly into a chroot - dracut switches root and starts systemd right after mounting the rootfs. See: https://git.gnome.org/browse/ostree/tree/src/switchroot/ostree-prepare-root.c /sysroot is a bind mount to the real root /. > What I'm > wondering about is that /dev/mapper/fedora-root is mounted several times > on /, /var, /usr and /sysroot (twice!) sometimes rw and sometimes ro. /usr is simply a bind mount to itself so it can be mounted read-only. This is important because otherwise one could corrupt the object store in /ostree/repo by mutating the hardlink farm in /usr. Note the /usr here is really /ostree/deploy/fedostree/deploy//usr as seen from the physical root. /var is a special bind mount to /ostree/deploy/fedostree/var which is shared between each deployment (chroot). > The impression I get is that /sysroot is the actual root fs in the image > and / the ostree directory at least that's what the links seem to > suggest. I still don't understand the mount-voodoo though. Is there some > documentation about this available? I'll look at adding more to the gtk-doc, though I suspect I may need to make a separate "system administrators new to OSTree" document which is a bit distinct from the "how to use OSTree underneath your package manager" document that the current one is. -- 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: SELinux RPM scriplet issue annoucement
On Tue, 2014-01-21 at 01:01 -0600, Ian Pilcher wrote: > On 01/20/2014 11:48 AM, Adam Williamson wrote: > > The bug currently under discussion was caused by a change that came in > > inadvertently, not intentionally, and was actually intended for Rawhide. > > I can't help wondering if there's an opportunity for process/workflow > improvement right there. Well, I'd have to leave that to the SELinux folks to comment, but I would say it's only happened once since I came to Fedora that I remember, and everyone makes mistakes sometimes :/ -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Summary/Minutes from today's FESCo Meeting (2014-01-15)
On Po, 2014-01-20 at 12:10 -0500, Matthew Miller wrote:
> On Mon, Jan 20, 2014 at 09:48:05AM +0100, Miroslav Suchý wrote:
> > > 18:31:13 Requires: foo > 1.0-1.%{release}
> > > 18:31:22 1.0-1.fc20.copr *satisfies* that
> > I have no objections against disttag. Hoever I would prefer "fc20-copr".
> > I.e. not to use dot as separator.
>
> That would require changes to RPM -- the "-" has special meaning.
We could use underscore "_" instead.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
--
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: SELinux RPM scriplet issue annoucement
On 01/20/2014 11:48 AM, Adam Williamson wrote: > The bug currently under discussion was caused by a change that came in > inadvertently, not intentionally, and was actually intended for Rawhide. I can't help wondering if there's an opportunity for process/workflow improvement right there. -- Ian Pilcher arequip...@gmail.com Sent from the cloud -- where it's already tomorrow -- 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: Announce: fedostree/rpm-ostree v2014.3
On 20.01.2014 19:03, Colin Walters wrote: Hello devel@, I'm excited to announce the first public release (v2014.3) of the fedostree/rpm-ostree project. The web page is here: http://rpm-ostree.cloud.fedoraproject.org/#/ rpm-ostree is a quite new, raw, and also quite unofficial project (the instance above is in the Fedora private scratch cloud). It is suitable for evaluation primarily by engineers who are working on build/packaging/deployment tooling in Fedora, and advanced testers. If you're one of those people, before you read any more, if you have a few minutes, please jump to: http://rpm-ostree.cloud.fedoraproject.org/images/ and start downloading the preconfigured VM. (Or alternatively see http://rpm-ostree.cloud.fedoraproject.org/#/installation for parallel install instructions inside an existing system). I've often struggled with explaining OSTree to people - but for the audience here, I want to emphasize that OSTree is designed to be *complementary* to package systems like rpm/dpkg. While OSTree does take over some roles from RPM such as handling /etc, if you study it carefully, I think you'll come to agree. The overall vision is to change Fedora (and really its prominent downstream) into a less flexible, but more reliable set of products, tested and delivered *much* *much* faster. That's about all for this mail - the "Background" section of the web page has more. As for what's coming next - I plan to bring gnome-continuous style fast testing to the rpm-ostree codebase too (assuming I get push notification from Koji). For example, test boot both "fedostree/20/x86_64/base/minimal", "fedostree/20/x86_64/workstation/gnome/core" after any package affecting them changes. Then if the tests pass, tag those trees as smoketested, like: "fedostree/20/smoketested/x86_64/base/minimal". If you have questions, please follow up here! (There's no mailing list for rpm-ostree at the moment; you can use ostree-l...@gnome.org for questions about the core OSTree model). What I need now is evaluation from some of the stakeholders in various parts of the deployment stack; for example, the changes to the handling of /var in RPM needs discussion. Interesting. I've downloaded the VM Image and tried to understand the setup. Apparently there exist sort of two root trees / and /sysroot in the system with some links targeting the /sysroot tree. What I'm wondering about is that /dev/mapper/fedora-root is mounted several times on /, /var, /usr and /sysroot (twice!) sometimes rw and sometimes ro. The impression I get is that /sysroot is the actual root fs in the image and / the ostree directory at least that's what the links seem to suggest. I still don't understand the mount-voodoo though. Is there some documentation about this available? Regards, Dennis -- 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: NetworkManager Bridges in Fedora
On 01/20/2014 08:18 PM, Nico Kadel-Garcia wrote: Networkmanager is not your friend for stable servers. I'm using it on a server with multiple interfaces, multiple vlans, multiple bridges, a VPN and a VM and it doesn't give me any trouble. I would say 95% of the setup was done through the GUI and I had to do some small tweaks, most of that due to the installer messing up the interface names. -- 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: NetworkManager Bridges in Fedora
My old notes at https://wikis.uit.tufts.edu/confluence/display/TUSKpub/Configure+Pair+Bonding,+VLANs,+and+Bridges+for+KVM+Hypervisor were pretty good. If you want stable KVM bridging, pair bonding, jumbo frames, or consistent network connections of any sort for server grade installations, my urgent advice is to rip NetworkManager out by the routes. It provides no useful benefit for a stable server environment, and is actively destabilizing because it rewrite and overwrites network configurations inconsistently, and in ways that are not "idempotent": the same steps executed two times in a row do not produce the same results, and only approach consistency thorugh a sort of "Newtonian approximation" eventually, but only eventually, publishing a vaguely stable configuration. Networkmanager is not your friend for stable servers. On Sat, Jan 18, 2014 at 11:35 AM, Mateusz Marzantowicz wrote: > On 16.01.2014 21:38, Dan Williams wrote: >> On Thu, 2014-01-16 at 14:53 -0500, Steve Dickson wrote: >>> >>> On 16/01/14 14:39, Steve Dickson wrote: On 16/01/14 14:09, Dan Williams wrote: > Also, if wouldn't mind passing along the systemd journal output for > NetworkManager, that might help us figure out what's going on: > > journalctl -b _SYSTEMD_UNIT=NetworkManager.service The log is at: http://steved.fedorapeople.org/tmp/nm.log >>> I bet ya the hang has something to do with these messages: >>> >>> (bridge0): IPv4 config waiting until carrier is on >>> (bridge0): IPv6 config waiting until carrier is on >>> Activation (bridge0) Stage 3 of 5 (IP Configure Start) complete. >>> >>> What carrier is it waiting on? em1 is already up and running... >> >> So what's happening here is that you two >> configurations/connections/profiles that apply to em1: "ifcfg-em1", and >> "ifcfg-bridge0_slave_1". And "ifcfg-em1" is getting chosen, but it's >> not a bridge slave configuration, it's just a normal DHCP configuration. >> >> Since "ifcfg-em1" is not a bridge slave configuration, it never gets >> added to the bridge master, and the bridge master sits around waiting >> for slaves because it has no carrier which is required for DHCP. >> >> Persistent fix #1: >> edit ifcfg-em1 and change ONBOOT=yes to ONBOOT=no >> nmcli con reload >> then do "Runtime fix" below >> >> Persistent fix #2: >> rm /etc/sysconfig/network-scripts/ifcfg-em1 >> nmcli con reload >> then do "Runtime fix" below >> >> (or use nm-connection-editor to delete 'em1' or uncheck "Connect >> automatically" from the General tab.) >> >> Runtime fix (not persistent): >> nmcli dev disconnect em1 >> nmcli con up "bridge0 slave 1" >> >> >> -- >> (In old "network" service speak, the runtime operation would be: >> >> ifdown em1 >> ifup bridge0_slave_1 >> >> and we still expect these commands to work even when NetworkManager is >> managing the interface.) >> -- >> >> Dan >> > > I'm doing this differently and now I don't know which method is > recommended by RH/Fedora gurus. I don't use > /etc/sysconfig/network-scripts at all but placed all network related > configuration in /etc/NetworkManager/system-connections/ directory. Now > I'm not sure if I should convert back to using /etc/sysconfig or what? > Not to mention that GUI tool is c... and I had to use text editor to > configure network bridging. > > > > Mateusz Marzantowicz > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: NetworkManager Bridges in Fedora
On Sat, 2014-01-18 at 14:53 +0200, Alek Paunov wrote: > On 18.01.2014 03:34, Adam Williamson wrote: > > On Fri, 2014-01-17 at 08:57 -0500, Steve Dickson wrote: > >> > >> On 17/01/14 07:30, Harald Hoyer wrote: > journalctl -b _SYSTEMD_UNIT=NetworkManager.service > >>> better use > >>> > >>> # journalctl -b -u NetworkManager > >>> > >>> "-u" has the advantage, that you can specify it multiple times with > >>> different > >>> units and get a combined output. > > > >> Good go know... thanks! > > > > How long has that parameter been in systemd now, Harald? Is it safe to > > suggest it for all supported Fedoras (F19, F20, Rawhide) at least? > > Thanks! > > > > -u works since systemd versions shipped with F18. Woth F19: Awesome. Thanks for saving me the 30 seconds it would've cost me to boot up my F19 VM and check. I love it when the lazyweb works :P -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Mon, 2014-01-20 at 17:00 -0800, Adam Williamson wrote: > On Mon, 2014-01-20 at 15:35 -0500, Matthew Miller wrote: > > On Mon, Jan 20, 2014 at 09:48:28AM -0800, Adam Williamson wrote: > > > I'd suggest this test should be a high priority for implementation once > > > taskotron is operational, perhaps equal in importance to re-implementing > > > the current AutoQA tests. > > > > *nod* Sounds good to me. > > > > > > > what we have. I don't know how to quantify that point, though. All's I > > > can do is reiterate that yes, this is a really significant pain point in > > > our current processes, the proposed Bodhi 2.0 design would make things > > > almost immeasurably better, and plead with anyone reading this who has > > > the power to bump up the importance of / resources assigned to Bodhi > > > 2.0's development to do so. > > > > So many things at top priority. :) I know Luke Macken is actually actively > > working it. > > I know he is. He's been actively working on it for the said three-four > year period. Every FUDCon/Flock he tells me it's nearly done. ;) > > Not ragging Luke, but it rather seems like we need about six more of > him. Oh, and naturally, every FUDCon/Flock we tell him that Taskotron will be rolling out any week now ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Mon, 2014-01-20 at 15:35 -0500, Matthew Miller wrote: > On Mon, Jan 20, 2014 at 09:48:28AM -0800, Adam Williamson wrote: > > I'd suggest this test should be a high priority for implementation once > > taskotron is operational, perhaps equal in importance to re-implementing > > the current AutoQA tests. > > *nod* Sounds good to me. > > > > what we have. I don't know how to quantify that point, though. All's I > > can do is reiterate that yes, this is a really significant pain point in > > our current processes, the proposed Bodhi 2.0 design would make things > > almost immeasurably better, and plead with anyone reading this who has > > the power to bump up the importance of / resources assigned to Bodhi > > 2.0's development to do so. > > So many things at top priority. :) I know Luke Macken is actually actively > working it. I know he is. He's been actively working on it for the said three-four year period. Every FUDCon/Flock he tells me it's nearly done. ;) Not ragging Luke, but it rather seems like we need about six more of him. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RPMbuild mystery parameters "--with" and "--without"
Ville Skyttä wrote: >On Mon, Jan 20, 2014 at 4:24 PM, Björn Persson > wrote: >> Apparently RPMbuild has a pair of parameters "--with" and "--without" >> that can supposedly enable and disable optional features in a >> package. Has anyone seen any documentation that explains how those >> work and how they interact with a spec file? > >See /usr/share/doc/rpm*/conditionalbuilds and "Conditional build >stuff" in /usr/lib/rpm/macros. Thanks, that was what I needed. Björn Persson signature.asc Description: PGP signature -- 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: F20: Puppet depchain pulls in Java
On Mon, Jan 20, 2014 at 10:29 AM, Vít Ondruch wrote: >> Seems to be bug. Haven't seen any bug report from you yet, so I did one >> for you: https://github.com/bkabrda/rubypick/issues/4 > > > https://admin.fedoraproject.org/updates/rubypick-1.1.1-1.fc20 > https://admin.fedoraproject.org/updates/rubypick-1.1.1-1.fc19 Thank you -- fantastic! I got dragged into the vortex of the weekend, and was planning to follow things up this week. You're too quick. I am also glad to see that the puppet ruby dep has some eyes on it. It is a far more gnarly topic if you think (as I do) that the depsolve machinery really needs a way to express preferences (ruby > jruby). cheers, m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- 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: SELinux RPM scriplet issue annoucement
On 01/20/2014 06:48 PM, Adam Williamson wrote: On Mon, 2014-01-20 at 12:17 -0500, Matthew Miller wrote: On Sun, Jan 19, 2014 at 08:10:29PM +0100, Michael Schwendt wrote: A simple "yum -y update ; reboot ; Oh, everything seems to work" has not been enough this time. And it was an update with a screen full of ticket numbers for the included bug-fixes/changes. It could have broken something else, too. Once we have a better automation framework in place, we can have tests like: install selinux update, reboot, install (special) test package version 1, update to test package version 2. (In addition to a series of other things that should work with selinux enabled.) Btw, some other packages are in the same boat. Imagine a graphics driver update "seems to work" for three testers that are required for a +3 vote in the updates system, but fails badly for a hundred other users once it appears in the stable updates repo. That's a little harder, of course. So I've read through this thread now. A few notes: 1) The precise nature of the failure here makes it a tricky issue to deal with. We actually already know that this kind of 'delayed action' bug is a tricky scenario to deal with, because we already have a whole pretty well-known *category* of similar bugs: scriptlet errors themselves. As Harald has pointed out, scriptlet errors are very messy bugs that our current testing process is very poor at catching. If anyone's not familiar with the scriptlet error category, see https://fedoraproject.org/wiki/Common_F20_bugs#preun-fail . So while the idea of an SELinux-specific 'update it, then update it again' test case seems to make superficial sense, it's not actually an SELinux-specific test. We should in fact be doing this for *all* updates, or at the least, all updates that include any scriptlets. However, it's not even that simple, because this is something that makes much more sense to test in an automated way than manually - even more so than many things. This specific bug was a bit easier to test than the scriptlet case, because you just had to update *any other* package after updating selinux-policy to see the bug, but it's clearly in the same category as the more difficult case, and we should come up with an approach that handles them all. What looks like the right approach has already been suggested in the FESCo ticket on this: an automated test that takes the update, bumps the spec one revision and tries to update. So if the update is foo-1.1-2, the test would build a foo-1.1-3 package with no other changes, and try updating from 1.1-2 to 1.1-3. Doing this manually is of course a PITA and it's really a _very_ clear candidate for automation. Such a test would, I believe, have caught the bug. As posted to FESCo, though, it's still the case that we're working on the automation framework at present and the tests come after that. We are aiming to have the framework operational for the F21 cycle, AIUI, and it may be plausible to implement this test during that cycle. As such a test has several very desirable attributes - i.e. it catches bugs which: 1) cause serious problems that are difficult to recover from 2) we are currently very bad at catching manually 3) would be difficult and onerous to reliably catch manually even with improved manual testing procedures I'd suggest this test should be a high priority for implementation once taskotron is operational, perhaps equal in importance to re-implementing the current AutoQA tests. (Harald is probably correct to note that another bug of precisely this type might result in 'innocent' updates being 'blamed' for being broken, but we'd at least have a clear indication that something was seriously boned, and could investigate/clean up manually - the proposed automated test wouldn't make anything worse than it currently is). 1b) Just in case anyone had forgotten, though, we do have the infrastructure for creating package-specific test cases that get integrated with Bodhi to an extent, even though I don't think that's the way to go in this particular case: see https://fedoraproject.org/wiki/QA:SOP_package_test_plan_creation . 2) I already suggested to the SELinux devs on test@ that perhaps selinux-policy updates should have a higher autokarma threshold, and they agreed this might be a good idea. It would also be possible for them to disable autopush for selinux-policy updates and handle pushing them manually, based on whatever policy they choose, though of course that's more work than using autopush. 3) Someone noted that big selinux-policy updates are 'scary'. I think to be fair to the SELinux devs it's worth noting they push big updates all the time, with a very high success record. This is the first time I can recall a bug anywhere near this serious happening with an SELinux update to a stable release. AIUI, they have a very sensible policy for stable release updates, which is that except in very exceptional cases, updates can only make the policy *more l
Re: Proposal: Stop cc'ing Maniphest Tickets to qa-devel@
On Thu, 2014-01-16 at 09:20 -0700, Tim Flink wrote: > On Thu, 16 Jan 2014 08:33:12 -0500 (EST) > Kamil Paral wrote: > > > > > > > > > Any thoughts on whether it would be OK to start asking folks to > > > > create herald rules if they want to see all the tickets or if > > > > there is enough value in continuing our policy of cc'ing the list > > > > on all tickets? > > > > > > > > Tim > > > > +1. I already created my herald rule. > > > > Tim, does that apply only for newly created tasks, or for all of > > them? I hope for the latter, otherwise it wouldn't be that useful. > > As I recall, the rule is processed as tickets are created/modified. > > I've removed the default cc rule and remove qa-devel@ as cc from all > open tickets. My window for drowning folks in spam through creating > tickets has ended :( Don't worry! It looks like you can still do it by creating trac tickets. ;) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Review swap: BZ#1055721 - qpid-dispatch
I have a package review I posted today, looking to swap with someone. Thanks. -- Darryl L. Pierce http://mcpierce.fedorapeople.org/ "What do you care what people think, Mr. Feynman?" pgpmch1w1BF7g.pgp Description: PGP signature -- 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: SELinux RPM scriplet issue annoucement
On Mon, Jan 20, 2014 at 09:48:28AM -0800, Adam Williamson wrote: > I'd suggest this test should be a high priority for implementation once > taskotron is operational, perhaps equal in importance to re-implementing > the current AutoQA tests. *nod* Sounds good to me. > what we have. I don't know how to quantify that point, though. All's I > can do is reiterate that yes, this is a really significant pain point in > our current processes, the proposed Bodhi 2.0 design would make things > almost immeasurably better, and plead with anyone reading this who has > the power to bump up the importance of / resources assigned to Bodhi > 2.0's development to do so. So many things at top priority. :) I know Luke Macken is actually actively working it. "Immeasurably better" sounds pretty good, although it's a shame it isn't "measurably better." -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 10:54:22AM -0800, Andrew Lutomirski wrote: > On Mon, Jan 20, 2014 at 10:40 AM, Matthew Garrett wrote: > > It'd be pretty straightforward to re-implement the helper if it's > > vanished entirely - we haven't retired libx86, and the rest is pretty > > trivial. > > OTOH, if it has indeed vanished entirely, then maybe we could argue > that there can't be any users and therefore it's okay if the driver > stops working in F21. People are using -vesa right now, not uvesafb. > Going forward, if the simpledrm stuff ever starts being fully > functional, then it should provide a working, if rather crappy, way to > get fixed-resolution graphics running on any new-enough system. Non-EFI systems are still going to need some mechanism for calling out to userspace for setting a mode. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On Sun, 2014-01-19 at 12:30 -0500, Scott Schmit wrote: > On Sun, Jan 19, 2014 at 12:23:42PM -0500, Scott Schmit wrote: > > On Sat, Jan 18, 2014 at 11:47:37PM -0500, Rahul Sundaram wrote: > > > On Sat, Jan 18, 2014 at 8:20 PM, Andre Robatino wrote: > > > > I replaced the typo scriplet -> scriptlet in several places in that > > > > page, > > > > including the anchor link. Don't know if that breaks any existing links. > > > > > > Thanks. I just sent out the announcement. Hopefully it makes sense. > > > > The text of the announcement made sense, but the link doesn't point to > > anything -- https://fedoraproject.org/wiki/Common_F20_bugs exists, but > > https://fedoraproject.org/wiki/Common_F20_bugs#RPM_scriplets_fail_during_updates > > doesn't point to anything on the page. > > Weird -- I loaded the page again and now it shows up, but I still have > it in another tab the other way, so I know it wasn't just that I had > missed it. > > Maybe there are multiple mirrors at play that aren't all in sync? I've found anchors on the Fedora wiki to be very unreliable in general, but never had time/inclination to look into it systematically. I just make sure the pages I write are set up correctly and figure that if the implementation is broken it ain't my problem. :P -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RPMbuild mystery parameters "--with" and "--without"
On 01/20/2014 05:56 PM, Richard W.M. Jones wrote: On Mon, Jan 20, 2014 at 03:24:12PM +0100, Björn Persson wrote: Apparently RPMbuild has a pair of parameters "--with" and "--without" that can supposedly enable and disable optional features in a package. Has anyone seen any documentation that explains how those work and how they interact with a spec file? I want to be able to easily switch an option between these two states: · off by default but can be enabled with "--with" · on by default but can be disabled with "--without" What's a good way to code that in the spec? They are (IMHO) very confusing to implement. However have a look at a the libvirt spec file for a working example: http://pkgs.fedoraproject.org/cgit/libvirt.git/tree/libvirt.spec The confusion with bcond comes from the fact the logic seems entirely backwards. Which it kinda is, until one learns the logic behind it: "%bcond_with foo" adds support for "--with foo" build option to the spec. Which also happens to mean that the default is "without" - why else would you need a --with option? And conversely, "%bcond_without foo" adss "--without foo" build option, effectively also saying default is "with". The fact that *everybody* is (at least initially) confused about it says something about the intuitiveness of the feature ... or lack of thereof :) - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 10:40 AM, Matthew Garrett wrote: > On Mon, Jan 20, 2014 at 10:19:30AM -0800, Andrew Lutomirski wrote: > >> Does uvesafb actually work? I submitted a patch to the uvesafb kernel >> driver a few months back, and not only is the upstream link [1][2] to >> the v86d helper dead, but no one on the dri-devel list answered my >> request to see if anyone had a copy. Fedora does not appear to >> package a copy (at least yum whatprovides '*/v86d' doesn't come up >> with anything). This means that I got a patch into upstream drm and >> that it's quite possible that no one (or maybe a grand total of one >> person) has ever tested. > > It'd be pretty straightforward to re-implement the helper if it's > vanished entirely - we haven't retired libx86, and the rest is pretty > trivial. OTOH, if it has indeed vanished entirely, then maybe we could argue that there can't be any users and therefore it's okay if the driver stops working in F21. Going forward, if the simpledrm stuff ever starts being fully functional, then it should provide a working, if rather crappy, way to get fixed-resolution graphics running on any new-enough system. --Andy -- 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: RPMbuild mystery parameters "--with" and "--without"
On Mon, 20 Jan 2014, Panu Matilainen wrote: On 01/20/2014 07:31 PM, Alek Paunov wrote: On 20.01.2014 16:24, Björn Persson wrote: According to the Packaging Guidelines we're not supposed to use those parameters when building "the source RPM to be submitted", because they somehow get "serialized" into the source package. I don't understand this, because I don't submit any source packages. The source package gets built on a Koji server when I run "fedpkg build", and I don't know of a way to pass any options to that process. IMHO, an example of reasonable usage of this RPM facility in the current context is the samba.spec: http://pkgs.fedoraproject.org/cgit/samba.git/plain/samba.spec It defines --with testsuite, which is not supposed for real binary packages production. Instead, it builds the full Samba (with the AD bits enabled) and performs the whole testsuite on top of the test build. The samba.spec is a bit convoluted for a simple example of the bcond usage as it has a zillion other unrelated but confusingly similar self-defined _with_foo macros and conditions based on them. samba.spec wasn't designed with bcond in mind at all. Naming of the defines is just logical. :). -- / Alexander Bokovoy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 04:50:09PM +, Peter Robinson wrote: > Isn't -cirrus still used by virt in a number of cases? I know -mga is > used as a gpu chipset on a number of relatively new server platforms. > What about -vmware? Virt can use the cirrus kms driver, the server matrox is supported by mgag200 and doesn't the vmwgfx driver cover vmware? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 10:19:30AM -0800, Andrew Lutomirski wrote: > Does uvesafb actually work? I submitted a patch to the uvesafb kernel > driver a few months back, and not only is the upstream link [1][2] to > the v86d helper dead, but no one on the dri-devel list answered my > request to see if anyone had a copy. Fedora does not appear to > package a copy (at least yum whatprovides '*/v86d' doesn't come up > with anything). This means that I got a patch into upstream drm and > that it's quite possible that no one (or maybe a grand total of one > person) has ever tested. It'd be pretty straightforward to re-implement the helper if it's vanished entirely - we haven't retired libx86, and the rest is pretty trivial. > Or do you mean the older pre-uvesafb driver? That's problematic from the "You have to provide a fixed resolution on the kernel command line" perspective. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 7:48 AM, Hans de Goede wrote: > Hi, > > > On 01/20/2014 03:18 PM, Matthew Garrett wrote: >> >> On Mon, Jan 20, 2014 at 10:08:01AM +0100, Hans de Goede wrote: >> >>> So now it is time to start looking into some of the corner cases, or >>> rather at >>> the elephant in the room. What about non-kms drivers. We still have the >>> vesa >>> driver around as most prominent example, and this is useful for some >>> oddball >>> cards and for cards which are too new. >> >> >> -mga is probably also still relevant in some small number of cases. > > > Don't we've a kms driver for those? Or you mean for mga cards not supported > by > the kms driver? > > >> We can probably kill -cirrus. That would leave -openchrome, which I think >> is probably only really relevant for OLPC? What's the situation with the >> binary nvidia and amd drivers? > > > Oh, I completely did not think about the binary drivers yet. Ugh. AFAIK > those > are not compatible with kms, so the helper for other ums drivers would just > do > the right thing there since there would be no kms capable card to be found > in /dev. > > >>> I would like to not break the vesa driver, while still killing the suid >>> bit on >>> the X server. >> >> >> It's probably worth considering whether porting uvesafb to kms would be >> worthwhile, and then just using -modesetting. > > > Yes that is something I was thinking about too, that would be an interesting > approach, > it would make it somewhat harder for people to use binary drivers, but not > impossible. > Does uvesafb actually work? I submitted a patch to the uvesafb kernel driver a few months back, and not only is the upstream link [1][2] to the v86d helper dead, but no one on the dri-devel list answered my request to see if anyone had a copy. Fedora does not appear to package a copy (at least yum whatprovides '*/v86d' doesn't come up with anything). This means that I got a patch into upstream drm and that it's quite possible that no one (or maybe a grand total of one person) has ever tested. Or do you mean the older pre-uvesafb driver? [1] http://dev.gentoo.org/~spock/projects/uvesafb [2] http://lxr.free-electrons.com/source/Documentation/fb/uvesafb.txt > And then we could simply forget about supporting ums at all I guess. > > Regards, > > Hans > > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: RPMbuild mystery parameters "--with" and "--without"
On 01/20/2014 07:31 PM, Alek Paunov wrote: On 20.01.2014 16:24, Björn Persson wrote: According to the Packaging Guidelines we're not supposed to use those parameters when building "the source RPM to be submitted", because they somehow get "serialized" into the source package. I don't understand this, because I don't submit any source packages. The source package gets built on a Koji server when I run "fedpkg build", and I don't know of a way to pass any options to that process. IMHO, an example of reasonable usage of this RPM facility in the current context is the samba.spec: http://pkgs.fedoraproject.org/cgit/samba.git/plain/samba.spec It defines --with testsuite, which is not supposed for real binary packages production. Instead, it builds the full Samba (with the AD bits enabled) and performs the whole testsuite on top of the test build. The samba.spec is a bit convoluted for a simple example of the bcond usage as it has a zillion other unrelated but confusingly similar self-defined _with_foo macros and conditions based on them. There are quite a few packages which use bcond, for example this is a more straightforward as an example: http://pkgs.fedoraproject.org/cgit/mutt.git/plain/mutt.spec - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 8:50 AM, Peter Robinson wrote: >>> So now it is time to start looking into some of the corner cases, or rather >>> at >>> the elephant in the room. What about non-kms drivers. We still have the vesa >>> driver around as most prominent example, and this is useful for some oddball >>> cards and for cards which are too new. >> >> -mga is probably also still relevant in some small number of cases. We >> can probably kill -cirrus. That would leave -openchrome, which I think >> is probably only really relevant for OLPC? What's the situation with the >> binary nvidia and amd drivers? > > Isn't -cirrus still used by virt in a number of cases? I know -mga is > used as a gpu chipset on a number of relatively new server platforms. > What about -vmware? I have several recent servers with MGA (compatible?) chips, and they all work fine with mgag200 (i.e. KMS). --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Announce: fedostree/rpm-ostree v2014.3
Hello devel@, I'm excited to announce the first public release (v2014.3) of the fedostree/rpm-ostree project. The web page is here: http://rpm-ostree.cloud.fedoraproject.org/#/ rpm-ostree is a quite new, raw, and also quite unofficial project (the instance above is in the Fedora private scratch cloud). It is suitable for evaluation primarily by engineers who are working on build/packaging/deployment tooling in Fedora, and advanced testers. If you're one of those people, before you read any more, if you have a few minutes, please jump to: http://rpm-ostree.cloud.fedoraproject.org/images/ and start downloading the preconfigured VM. (Or alternatively see http://rpm-ostree.cloud.fedoraproject.org/#/installation for parallel install instructions inside an existing system). I've often struggled with explaining OSTree to people - but for the audience here, I want to emphasize that OSTree is designed to be *complementary* to package systems like rpm/dpkg. While OSTree does take over some roles from RPM such as handling /etc, if you study it carefully, I think you'll come to agree. The overall vision is to change Fedora (and really its prominent downstream) into a less flexible, but more reliable set of products, tested and delivered *much* *much* faster. That's about all for this mail - the "Background" section of the web page has more. As for what's coming next - I plan to bring gnome-continuous style fast testing to the rpm-ostree codebase too (assuming I get push notification from Koji). For example, test boot both "fedostree/20/x86_64/base/minimal", "fedostree/20/x86_64/workstation/gnome/core" after any package affecting them changes. Then if the tests pass, tag those trees as smoketested, like: "fedostree/20/smoketested/x86_64/base/minimal". If you have questions, please follow up here! (There's no mailing list for rpm-ostree at the moment; you can use ostree-l...@gnome.org for questions about the core OSTree model). What I need now is evaluation from some of the stakeholders in various parts of the deployment stack; for example, the changes to the handling of /var in RPM needs discussion. -- 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 repo signing [was Re: Python 3 for 7?]
On Mon, 20 Jan 2014 09:11:48 -0500 Matthew Miller wrote: > On Fri, Jan 17, 2014 at 03:42:34PM -0700, Kevin Fenzi wrote: > > > My thoughts are these (in no particular order). > > > * Treat this branch like Rawhide. All builds targeted at this are > > > composed to a repo. Signing is nice, but not mandatory in my > > > opinion. > > It's pretty much impossible to sign rawhide style repos. ;) ...snip a bunch of stuff I agree with... Yes, sorry I was unclear here. It's pretty much impossible with our current signing setup to sign rawhide style repos. ;) sigul has no ability to do non interactive signing. You always have to provide it with a passphrase with the list of things to sign. There is a koji plugin to sign all built packages, but it stores gpg keys on the hub, passphrases in the koji config and is pretty much never going to be acceptable to upstream koji to add. Ideally we would have someone able to improve sigul so we could do some kind of unattended signing in specific cases (and lock that down as much as we can). Currently we don't have this. ;) kevin signature.asc Description: PGP signature ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: SELinux RPM scriplet issue annoucement
On Mon, 2014-01-20 at 12:17 -0500, Matthew Miller wrote: > On Sun, Jan 19, 2014 at 08:10:29PM +0100, Michael Schwendt wrote: > > A simple "yum -y update ; reboot ; Oh, everything seems to work" has not > > been enough this time. And it was an update with a screen full of ticket > > numbers for the included bug-fixes/changes. It could have broken something > > else, too. > > Once we have a better automation framework in place, we can have tests like: > install selinux update, reboot, install (special) test package version 1, > update to test package version 2. (In addition to a series of other things > that should work with selinux enabled.) > > > > Btw, some other packages are in the same boat. Imagine a graphics driver > > update "seems to work" for three testers that are required for a +3 vote > > in the updates system, but fails badly for a hundred other users once it > > appears in the stable updates repo. > > That's a little harder, of course. So I've read through this thread now. A few notes: 1) The precise nature of the failure here makes it a tricky issue to deal with. We actually already know that this kind of 'delayed action' bug is a tricky scenario to deal with, because we already have a whole pretty well-known *category* of similar bugs: scriptlet errors themselves. As Harald has pointed out, scriptlet errors are very messy bugs that our current testing process is very poor at catching. If anyone's not familiar with the scriptlet error category, see https://fedoraproject.org/wiki/Common_F20_bugs#preun-fail . So while the idea of an SELinux-specific 'update it, then update it again' test case seems to make superficial sense, it's not actually an SELinux-specific test. We should in fact be doing this for *all* updates, or at the least, all updates that include any scriptlets. However, it's not even that simple, because this is something that makes much more sense to test in an automated way than manually - even more so than many things. This specific bug was a bit easier to test than the scriptlet case, because you just had to update *any other* package after updating selinux-policy to see the bug, but it's clearly in the same category as the more difficult case, and we should come up with an approach that handles them all. What looks like the right approach has already been suggested in the FESCo ticket on this: an automated test that takes the update, bumps the spec one revision and tries to update. So if the update is foo-1.1-2, the test would build a foo-1.1-3 package with no other changes, and try updating from 1.1-2 to 1.1-3. Doing this manually is of course a PITA and it's really a _very_ clear candidate for automation. Such a test would, I believe, have caught the bug. As posted to FESCo, though, it's still the case that we're working on the automation framework at present and the tests come after that. We are aiming to have the framework operational for the F21 cycle, AIUI, and it may be plausible to implement this test during that cycle. As such a test has several very desirable attributes - i.e. it catches bugs which: 1) cause serious problems that are difficult to recover from 2) we are currently very bad at catching manually 3) would be difficult and onerous to reliably catch manually even with improved manual testing procedures I'd suggest this test should be a high priority for implementation once taskotron is operational, perhaps equal in importance to re-implementing the current AutoQA tests. (Harald is probably correct to note that another bug of precisely this type might result in 'innocent' updates being 'blamed' for being broken, but we'd at least have a clear indication that something was seriously boned, and could investigate/clean up manually - the proposed automated test wouldn't make anything worse than it currently is). 1b) Just in case anyone had forgotten, though, we do have the infrastructure for creating package-specific test cases that get integrated with Bodhi to an extent, even though I don't think that's the way to go in this particular case: see https://fedoraproject.org/wiki/QA:SOP_package_test_plan_creation . 2) I already suggested to the SELinux devs on test@ that perhaps selinux-policy updates should have a higher autokarma threshold, and they agreed this might be a good idea. It would also be possible for them to disable autopush for selinux-policy updates and handle pushing them manually, based on whatever policy they choose, though of course that's more work than using autopush. 3) Someone noted that big selinux-policy updates are 'scary'. I think to be fair to the SELinux devs it's worth noting they push big updates all the time, with a very high success record. This is the first time I can recall a bug anywhere near this serious happening with an SELinux update to a stable release. AIUI, they have a very sensible policy for stable release updates, which is that except in very exceptional cases, updates can only make the policy *more l
Re: RPMbuild mystery parameters "--with" and "--without"
On 20.01.2014 16:24, Björn Persson wrote: According to the Packaging Guidelines we're not supposed to use those parameters when building "the source RPM to be submitted", because they somehow get "serialized" into the source package. I don't understand this, because I don't submit any source packages. The source package gets built on a Koji server when I run "fedpkg build", and I don't know of a way to pass any options to that process. IMHO, an example of reasonable usage of this RPM facility in the current context is the samba.spec: http://pkgs.fedoraproject.org/cgit/samba.git/plain/samba.spec It defines --with testsuite, which is not supposed for real binary packages production. Instead, it builds the full Samba (with the AD bits enabled) and performs the whole testsuite on top of the test build. Kind regards, Alek P.S. Fedora .spec provided Samba AD works very well for me. If someone is interested to deploy Samba AD on Fedora 20, and is aware of MIT vs. Heimdal Kerberos caveats _or_ are used with deployment in isolation (dedicated instance, container) there are couple of COPR RPMs available: http://copr.fedoraproject.org/coprs/decalek/samba.dc/ -- 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: SELinux RPM scriplet issue annoucement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/20/2014 10:50 AM, Simo Sorce wrote: > On Mon, 2014-01-20 at 08:42 +0100, Michael Schwendt wrote: >> On Sun, 19 Jan 2014 23:02:24 -0500, Simo Sorce wrote: >> Anyone not aware of the problem and the fix, who applies the -117.fc20 selinux-policy update in _enforcing_ mode (since it has entered stable updates meanwhile) believing it to be a normal update, will face another failure and a partial update. Package selinux-policy updated to -117.fc20 but -targeted remaining at -116.fc20. >>> >>> I don't see this. I just updated today before reading this message (and >>> I haven;t read the whole thread, sorry) and I got selinux-policy and >>> targeted updated without any problem (I always run in enforcing mode). >> >> Did you update from -116.fc20 or an earlier one? >> >> Only if you come from -116.fc20, you would be affected, since -116.fc20 >> is the bad update. > > Ah I think I skipped 116, sorry for the noise. > > Simo. > Lucky man, hopefully a lot of users skipped it... -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLdXA4ACgkQrlYvE4MpobObvwCgrvA8ndAn5zBUpWA/LvO3fCUw qKUAoLHkon72qLTudvb/5LsHguzzt8Rg =8cRf -END PGP SIGNATURE- -- 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: SELinux RPM scriplet issue annoucement
On Sun, Jan 19, 2014 at 08:10:29PM +0100, Michael Schwendt wrote: > A simple "yum -y update ; reboot ; Oh, everything seems to work" has not > been enough this time. And it was an update with a screen full of ticket > numbers for the included bug-fixes/changes. It could have broken something > else, too. Once we have a better automation framework in place, we can have tests like: install selinux update, reboot, install (special) test package version 1, update to test package version 2. (In addition to a series of other things that should work with selinux enabled.) > Btw, some other packages are in the same boat. Imagine a graphics driver > update "seems to work" for three testers that are required for a +3 vote > in the updates system, but fails badly for a hundred other users once it > appears in the stable updates repo. That's a little harder, of course. -- Matthew Miller-- Fedora Project-- -- 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: Summary/Minutes from today's FESCo Meeting (2014-01-15)
On Mon, Jan 20, 2014 at 09:48:05AM +0100, Miroslav Suchý wrote:
> > 18:31:13 Requires: foo > 1.0-1.%{release}
> > 18:31:22 1.0-1.fc20.copr *satisfies* that
> I have no objections against disttag. Hoever I would prefer "fc20-copr".
> I.e. not to use dot as separator.
That would require changes to RPM -- the "-" has special meaning.
--
Matthew Miller-- Fedora Project--
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, 2014-01-20 at 15:58 +, Richard W.M. Jones wrote: > On Mon, Jan 20, 2014 at 02:18:22PM +, Matthew Garrett wrote: > > We can probably kill -cirrus. > > qemu? (I know that people "should" be using QXL, but cirrus is still > the default in plain qemu, and IMHO simpler and more secure.) I mean, I've crashed the hypervisor with both... - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
>> So now it is time to start looking into some of the corner cases, or rather >> at >> the elephant in the room. What about non-kms drivers. We still have the vesa >> driver around as most prominent example, and this is useful for some oddball >> cards and for cards which are too new. > > -mga is probably also still relevant in some small number of cases. We > can probably kill -cirrus. That would leave -openchrome, which I think > is probably only really relevant for OLPC? What's the situation with the > binary nvidia and amd drivers? Isn't -cirrus still used by virt in a number of cases? I know -mga is used as a gpu chipset on a number of relatively new server platforms. What about -vmware? Peter -- 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: SELinux RPM scriplet issue annoucement
On Sat, 2014-01-18 at 15:06 -0700, Kevin Fenzi wrote: > On Sat, 18 Jan 2014 15:47:38 -0500 > Rahul Sundaram wrote: > > > Hi > > > > Since updates don't automatically fix the issue created by > > https://bugzilla.redhat.com/show_bug.cgi?id=1054350 and users are > > required to run a set of steps as a workaround, shouldn't this be > > announced via the fedora announce list and posted in the Fedora > > website prominently as well? > > I would think a detailed common bugs entry and then a short > announcement pointing to that would be good. > > Would someone be able to write up the common bug entry? > > Adam? :) Many apologies for not helping out with this process, folks, and big thanks to others for picking up the slack (especially Rahul) - I was distracted by other shinies over the weekend, I'm afraid! I had this on my radar, but it looks like those involved did a great job, and I'd only have gotten in the way. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: NetworkManager Bridges in Fedora
On Sat, 2014-01-18 at 17:35 +0100, Mateusz Marzantowicz wrote: > On 16.01.2014 21:38, Dan Williams wrote: > > On Thu, 2014-01-16 at 14:53 -0500, Steve Dickson wrote: > >> > >> On 16/01/14 14:39, Steve Dickson wrote: > >>> > >>> > >>> On 16/01/14 14:09, Dan Williams wrote: > Also, if wouldn't mind passing along the systemd journal output for > NetworkManager, that might help us figure out what's going on: > > journalctl -b _SYSTEMD_UNIT=NetworkManager.service > >>> The log is at: > >>> http://steved.fedorapeople.org/tmp/nm.log > >> I bet ya the hang has something to do with these messages: > >> > >> (bridge0): IPv4 config waiting until carrier is on > >> (bridge0): IPv6 config waiting until carrier is on > >> Activation (bridge0) Stage 3 of 5 (IP Configure Start) complete. > >> > >> What carrier is it waiting on? em1 is already up and running... > > > > So what's happening here is that you two > > configurations/connections/profiles that apply to em1: "ifcfg-em1", and > > "ifcfg-bridge0_slave_1". And "ifcfg-em1" is getting chosen, but it's > > not a bridge slave configuration, it's just a normal DHCP configuration. > > > > Since "ifcfg-em1" is not a bridge slave configuration, it never gets > > added to the bridge master, and the bridge master sits around waiting > > for slaves because it has no carrier which is required for DHCP. > > > > Persistent fix #1: > > edit ifcfg-em1 and change ONBOOT=yes to ONBOOT=no > > nmcli con reload > > then do "Runtime fix" below > > > > Persistent fix #2: > > rm /etc/sysconfig/network-scripts/ifcfg-em1 > > nmcli con reload > > then do "Runtime fix" below > > > > (or use nm-connection-editor to delete 'em1' or uncheck "Connect > > automatically" from the General tab.) > > > > Runtime fix (not persistent): > > nmcli dev disconnect em1 > > nmcli con up "bridge0 slave 1" > > > > > > -- > > (In old "network" service speak, the runtime operation would be: > > > > ifdown em1 > > ifup bridge0_slave_1 > > > > and we still expect these commands to work even when NetworkManager is > > managing the interface.) > > -- > > > > Dan > > > > I'm doing this differently and now I don't know which method is > recommended by RH/Fedora gurus. I don't use > /etc/sysconfig/network-scripts at all but placed all network related > configuration in /etc/NetworkManager/system-connections/ directory. Now > I'm not sure if I should convert back to using /etc/sysconfig or what? > Not to mention that GUI tool is c... and I had to use text editor to > configure network bridging. Both ifcfg files (/etc/sysconfig/network-scripts) or keyfiles (/etc/NetworkManager/system-connections) are supported, and the GUI tools and nmcli work fine with both. If they don't, that's a bug and we'll fix it. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 03:58:23PM +, Richard W.M. Jones wrote: > On Mon, Jan 20, 2014 at 02:18:22PM +, Matthew Garrett wrote: > > We can probably kill -cirrus. > > qemu? (I know that people "should" be using QXL, but cirrus is still > the default in plain qemu, and IMHO simpler and more secure.) We have KMS support for the qemu cirrus, so you can just use -modesetting. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 04:48:55PM +0100, Hans de Goede wrote: > Hi, > On 01/20/2014 03:18 PM, Matthew Garrett wrote: > >-mga is probably also still relevant in some small number of cases. > > Don't we've a kms driver for those? Or you mean for mga cards not supported by > the kms driver? The KMS driver only supports the g200 cores embedded in some server chipsets, it doesn't handle real hardware. We've already dropped 3D support for those chips, though, so it's arguably not of great importance. The only real difference in functionality by dropping -mga would be losing multihead support, and I don't think anyone ever made that work on the UMS driver without the HAL blob. > >We can probably kill -cirrus. That would leave -openchrome, which I think > >is probably only really relevant for OLPC? What's the situation with the > >binary nvidia and amd drivers? > > Oh, I completely did not think about the binary drivers yet. Ugh. AFAIK those > are not compatible with kms, so the helper for other ums drivers would just do > the right thing there since there would be no kms capable card to be found in > /dev. The binary drivers don't need iopl(), so the only real question is whether they need root for anything else. It may just be permissions on device nodes, in which case we can probably just special-case them? > >It's probably worth considering whether porting uvesafb to kms would be > >worthwhile, and then just using -modesetting. > > Yes that is something I was thinking about too, that would be an interesting > approach, > it would make it somewhat harder for people to use binary drivers, but not > impossible. I don't see it being any harder than the blacklisting of nouveau/radeon that's already required. > And then we could simply forget about supporting ums at all I guess. That would be certainly be a glorious flying-car future. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Rose-DB-Object] update to version 0.810
commit a3f86a1cdab9dc5c47a287835cece6bc3978916d
Author: Bill Pemberton
Date: Mon Jan 20 10:59:29 2014 -0500
update to version 0.810
.gitignore |1 +
perl-Rose-DB-Object.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 5a2ac6f..037d173 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,3 +9,4 @@
/Rose-DB-Object-0.807.tar.gz
/Rose-DB-Object-0.808.tar.gz
/Rose-DB-Object-0.809.tar.gz
+/Rose-DB-Object-0.810.tar.gz
diff --git a/perl-Rose-DB-Object.spec b/perl-Rose-DB-Object.spec
index cd3346d..1e24237 100644
--- a/perl-Rose-DB-Object.spec
+++ b/perl-Rose-DB-Object.spec
@@ -1,5 +1,5 @@
Name: perl-Rose-DB-Object
-Version: 0.809
+Version: 0.810
Release: 1%{?dist}
Summary: Extensible, high performance object-relational mapper (ORM)
License: GPL+ or Artistic
@@ -68,6 +68,9 @@ make test
%{_mandir}/man3/Rose::DB::Object*.3pm*
%changelog
+* Mon Jan 20 2014 Bill Pemberton - 0.810-1
+- update to version 0.810
+
* Thu Dec 5 2013 Bill Pemberton - 0.809-1
- update to version 0.808
- fixes precision and scale for auto-loaded numeric column metadata
diff --git a/sources b/sources
index f34a925..00350b5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-5a871dfd2bbf3e827bf18096612dda2b Rose-DB-Object-0.809.tar.gz
+b73acf4ddaf7b893ce3cc7ae983b72d7 Rose-DB-Object-0.810.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 02:18:22PM +, Matthew Garrett wrote: > We can probably kill -cirrus. qemu? (I know that people "should" be using QXL, but cirrus is still the default in plain qemu, and IMHO simpler and more secure.) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RPMbuild mystery parameters "--with" and "--without"
On Mon, Jan 20, 2014 at 03:24:12PM +0100, Björn Persson wrote: > Apparently RPMbuild has a pair of parameters "--with" and "--without" > that can supposedly enable and disable optional features in a package. > Has anyone seen any documentation that explains how those work and how > they interact with a spec file? > > I want to be able to easily switch an option between these two states: > · off by default but can be enabled with "--with" > · on by default but can be disabled with "--without" > What's a good way to code that in the spec? They are (IMHO) very confusing to implement. However have a look at a the libvirt spec file for a working example: http://pkgs.fedoraproject.org/cgit/libvirt.git/tree/libvirt.spec Also there's a bug open to make these flags work from 'fedpkg local': https://bugzilla.redhat.com/show_bug.cgi?id=820596 > According to the Packaging Guidelines we're not supposed to use those > parameters when building "the source RPM to be submitted", because they > somehow get "serialized" into the source package. I don't understand > this, because I don't submit any source packages. Yeah I don't understand this either. I didn't know it was possible to submit an SRPM directly (except for scratch builds), and if there is it doesn't sound desirable. > The source package gets built on a Koji server when I run "fedpkg > build", and I don't know of a way to pass any options to that > process. There isn't .. and shouldn't be, since you'd want 'fedpkg build' to build exactly one RPM variant. However for 'fedpkg local' these flags could be pretty useful, see above. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File Rose-DB-Object-0.810.tar.gz uploaded to lookaside cache by wfp
A file has been added to the lookaside cache for perl-Rose-DB-Object: b73acf4ddaf7b893ce3cc7ae983b72d7 Rose-DB-Object-0.810.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: SELinux RPM scriplet issue annoucement
On Mon, 2014-01-20 at 08:42 +0100, Michael Schwendt wrote: > On Sun, 19 Jan 2014 23:02:24 -0500, Simo Sorce wrote: > > > > Anyone not aware of the problem and the fix, who applies the -117.fc20 > > > selinux-policy update in _enforcing_ mode (since it has entered stable > > > updates meanwhile) believing it to be a normal update, will face another > > > failure and a partial update. Package selinux-policy updated > > > to -117.fc20 but -targeted remaining at -116.fc20. > > > > I don't see this. > > I just updated today before reading this message (and I haven;t read the > > whole thread, sorry) and I got selinux-policy and targeted updated > > without any problem (I always run in enforcing mode). > > Did you update from -116.fc20 or an earlier one? > > Only if you come from -116.fc20, you would be affected, since -116.fc20 is > the bad update. Ah I think I skipped 116, sorry for the noise. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Rose-DB] Update to version 0.775
commit 88dd7be0a25723b4c63752266f71fc475ec21b5b
Author: Bill Pemberton
Date: Mon Jan 20 10:50:08 2014 -0500
Update to version 0.775
.gitignore|1 +
perl-Rose-DB.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index c7932f2..6e90def 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@
/Rose-DB-0.771.tar.gz
/Rose-DB-0.773.tar.gz
/Rose-DB-0.774.tar.gz
+/Rose-DB-0.775.tar.gz
diff --git a/perl-Rose-DB.spec b/perl-Rose-DB.spec
index 8932e26..db6998d 100644
--- a/perl-Rose-DB.spec
+++ b/perl-Rose-DB.spec
@@ -1,5 +1,5 @@
Name: perl-Rose-DB
-Version: 0.774
+Version: 0.775
Release: 1%{?dist}
Summary: DBI wrapper and abstraction layer
License: GPL+ or Artistic
@@ -64,6 +64,9 @@ make test
%{_mandir}/man3/Rose::DB*.3pm*
%changelog
+* Mon Jan 20 2014 Bill Pemberton - 0.775-1
+- update to version 0.775
+
* Mon Nov 4 2013 Bill Pemberton - 0.774-1
- update to version 0.774
- fixes some typos
diff --git a/sources b/sources
index ceefdc0..fb10645 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-926eaa7858f6a92423eb6301d5b95d9a Rose-DB-0.774.tar.gz
+a11a2bcb522af44865c8df9e06654428 Rose-DB-0.775.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: RFC: what to do with ums when the X server is not suid root ?
Hi, On 01/20/2014 03:18 PM, Matthew Garrett wrote: On Mon, Jan 20, 2014 at 10:08:01AM +0100, Hans de Goede wrote: So now it is time to start looking into some of the corner cases, or rather at the elephant in the room. What about non-kms drivers. We still have the vesa driver around as most prominent example, and this is useful for some oddball cards and for cards which are too new. -mga is probably also still relevant in some small number of cases. Don't we've a kms driver for those? Or you mean for mga cards not supported by the kms driver? We can probably kill -cirrus. That would leave -openchrome, which I think is probably only really relevant for OLPC? What's the situation with the binary nvidia and amd drivers? Oh, I completely did not think about the binary drivers yet. Ugh. AFAIK those are not compatible with kms, so the helper for other ums drivers would just do the right thing there since there would be no kms capable card to be found in /dev. I would like to not break the vesa driver, while still killing the suid bit on the X server. It's probably worth considering whether porting uvesafb to kms would be worthwhile, and then just using -modesetting. Yes that is something I was thinking about too, that would be an interesting approach, it would make it somewhat harder for people to use binary drivers, but not impossible. And then we could simply forget about supporting ums at all I guess. Regards, Hans -- 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: F20: Puppet depchain pulls in Java
Dne 20.1.2014 11:48, Vít Ondruch napsal(a): > Dne 17.1.2014 23:34, Martin Langhoff napsal(a): >> Interestingly enough, after uninstalling jruby, rubypick still thinks >> it's installed! >> >> [martin@tp-martin puppet-rlgold.git]$ ruby --help >> This is Fedora's rubypick - a Ruby runtime chooser. You can use it >> to execute Ruby programmes with any Fedora Ruby runtime. >> These currently include: >> Ruby - binary /usr/bin/ruby-mri - Installed >> JRuby - binary /usr/bin/jruby - Installed >> To run a specific runtime, use: >> ruby _mri_ [params] >> ruby _jruby_ [params] >> The default is _mri_. >> (...) >> >> [martin@tp-martin puppet-rlgold.git]$ stat /usr/bin/jruby >> stat: cannot stat ‘/usr/bin/jruby’: No such file or directory >> >> The whole thing seems... suboptimal :-) >> >> > Seems to be bug. Haven't seen any bug report from you yet, so I did one > for you: https://github.com/bkabrda/rubypick/issues/4 > > > Vít https://admin.fedoraproject.org/updates/rubypick-1.1.1-1.fc20 https://admin.fedoraproject.org/updates/rubypick-1.1.1-1.fc19 Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Owner-change] Fedora packages ownership change
Change in ownership over the last 168 hours === 1 packages were orphaned pxe-kexec [EL-5,EL-6] was orphaned by kevin Linux boots Linux via network https://admin.fedoraproject.org/pkgdb/acls/name/pxe-kexec 12 packages unorphaned -- daveisfera unorphaned : llvm [EL-6] rdieter unorphaned : qt5-qttools [EL-6] fantom unorphaned : checkdns [devel,f18,f19,f20] rdieter unorphaned : qt5-qtmultimedia [EL-6] cicku unorphaned : NetPIPE [EL-6,devel,f20] rdieter unorphaned : qt5-qtdeclarative [EL-6] msekletaunorphaned : mlocate [devel,f19,f20] anishpatil unorphaned : gettext-commons [devel,f19,f20] rdieter unorphaned : qt5-qtwebkit [EL-6] robert unorphaned : libvmime [EL-5,EL-6,devel,f18,f19,f20] gholms unorphaned : python-boto [EL-6] rdieter unorphaned : qt5-qtbase [EL-6] 5 packages were retired OpenGTL [devel] was retired by rdieter Graphics Transformation Languages https://admin.fedoraproject.org/pkgdb/acls/name/OpenGTL amiri-fonts [EL-5] was retired by moceap A classical Arabic font in Naskh style https://admin.fedoraproject.org/pkgdb/acls/name/amiri-fonts python-pexpect [epel7] was retired by leigh123linux Unicode-aware Pure Python Expect-like module https://admin.fedoraproject.org/pkgdb/acls/name/python-pexpect libQtGTL [devel] was retired by rdieter Qt bindings for OpenGTL https://admin.fedoraproject.org/pkgdb/acls/name/libQtGTL qt5-qtjsbackend [EL-6,f19] was retired by hobbes1069 Qt5 - QtJSBackend component https://admin.fedoraproject.org/pkgdb/acls/name/qt5-qtjsbackend 29 packages changed owner - limbgave to lkundrak : apache-commons-discovery [epel7] limbgave to leigh123linux : muffin [epel7] limbgave to leigh123linux : nemo [epel7] limbgave to sdake : openstack-heat-templates [EL-6,f20] limbgave to leigh123linux : cinnamon-session [epel7] limbgave to pradac : perl-Capture-Tiny [EL-6] limbgave to leigh123linux : python-pexpect [epel7] ppisar gave to pghmcfc: perl-utf8-all [epel7] limbgave to leigh123linux : nemo-extensions [epel7] limbgave to ignatenkobrain : SDL2_mixer [f19] limbgave to leigh123linux : cinnamon-translations [epel7] limbgave to leigh123linux : cjs [epel7] limbgave to leigh123linux : cinnamon-settings-daemon [epel7] limbgave to leigh123linux : cinnamon-screensaver [epel7] limbgave to leigh123linux : cinnamon-desktop [epel7] limbgave to cicku : python-pgpdump [EL-6,epel7] limbgave to stingray : md5deep [EL-5,EL-6,epel7] limbgave to sparks : cqrlog [epel7] limbgave to lbazan : python-django-filter [EL-6] limbgave to leigh123linux : cinnamon-control-center [epel7] limbgave to lkundrak : perl-Text-CSV [epel7] limbgave to remi : php-pear-Auth [EL-6,epel7] limbgave to petersen : cabal-rpm [EL-5] limbgave to rlandmann : perl-XML-Catalog [EL-5,EL-6] limbgave to cicku : httrack [EL-6,epel7] limbgave to kkeithle : nfs-ganesha [epel7] limbgave to sparks : create-tx-configuration [epel7] limbgave to maxamillion: perl-IPTables-ChainMgr [EL-6] limbgave to leigh123linux : cinnamon [epel7] Sources: https://github.com/pypingou/fedora-owner-change -- 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: SELinux RPM scriplet issue annoucement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/20/2014 04:42 AM, Michael Schwendt wrote: I think we should have a much higher Karma for SELinux-policy to be released. 5 or maybe 10. The problem with selinux-policy is it gets karma fast, since each update fixes multiple bugs. And people just update it, see if it fixes their bug, then the tester updates the karma. As has been said, the update broke the next update. Which no one caught. Forcing it to wait a week would probably not be a bad idea. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLdO8AACgkQrlYvE4MpobMbagCgsdkkZA2mSPvku/mrUlS6aOZu fKQAoKmGHU0kJJZilPXWULTKL6ZyG7MC =Tmvz -END PGP SIGNATURE- -- 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: RPMbuild mystery parameters "--with" and "--without"
On Mon, Jan 20, 2014 at 4:24 PM, Björn Persson wrote: > Apparently RPMbuild has a pair of parameters "--with" and "--without" > that can supposedly enable and disable optional features in a package. > Has anyone seen any documentation that explains how those work and how > they interact with a spec file? See /usr/share/doc/rpm*/conditionalbuilds and "Conditional build stuff" in /usr/lib/rpm/macros. -- 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: RPMbuild mystery parameters "--with" and "--without"
On 01/20/2014 04:24 PM, Björn Persson wrote: Apparently RPMbuild has a pair of parameters "--with" and "--without" that can supposedly enable and disable optional features in a package. Has anyone seen any documentation that explains how those work and how they interact with a spec file? I want to be able to easily switch an option between these two states: · off by default but can be enabled with "--with" · on by default but can be disabled with "--without" What's a good way to code that in the spec? See http://rpm.org/wiki/PackagerDocs/ConditionalBuilds According to the Packaging Guidelines we're not supposed to use those parameters when building "the source RPM to be submitted", because they somehow get "serialized" into the source package. I don't understand this, because I don't submit any source packages. The source package gets built on a Koji server when I run "fedpkg build", and I don't know of a way to pass any options to that process. I guess you'd be referring to this: https://fedoraproject.org/wiki/Packaging:Guidelines#Conditional_dependencies Its a rather complicated way of saying that Fedora packages must have their Fedora defaults for with/without set in the spec, ie rebuilding the package must not require any command-line switches. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
RPMbuild mystery parameters "--with" and "--without"
Apparently RPMbuild has a pair of parameters "--with" and "--without" that can supposedly enable and disable optional features in a package. Has anyone seen any documentation that explains how those work and how they interact with a spec file? I want to be able to easily switch an option between these two states: · off by default but can be enabled with "--with" · on by default but can be disabled with "--without" What's a good way to code that in the spec? According to the Packaging Guidelines we're not supposed to use those parameters when building "the source RPM to be submitted", because they somehow get "serialized" into the source package. I don't understand this, because I don't submit any source packages. The source package gets built on a Koji server when I run "fedpkg build", and I don't know of a way to pass any options to that process. Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 10:08:01AM +0100, Hans de Goede wrote: > So now it is time to start looking into some of the corner cases, or rather at > the elephant in the room. What about non-kms drivers. We still have the vesa > driver around as most prominent example, and this is useful for some oddball > cards and for cards which are too new. -mga is probably also still relevant in some small number of cases. We can probably kill -cirrus. That would leave -openchrome, which I think is probably only really relevant for OLPC? What's the situation with the binary nvidia and amd drivers? > I would like to not break the vesa driver, while still killing the suid bit on > the X server. It's probably worth considering whether porting uvesafb to kms would be worthwhile, and then just using -modesetting. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Environment and Stacks PRD
Environment and Stacks Working Group approved the first version of PRD. Feel free to comment what is missing or what should be altered. https://fedoraproject.org/wiki/Env_and_Stacks/Product_Requirements_Document Thanks, Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Agenda for Env-and-Stacks WG meeting (2014-01-21)
WG meeting will be at 13:00 UTC in #fedora-meeting on Freenode. == Topic == PRD was approved on mailing list. Possible further discussion about tasks: https://fedoraproject.org/wiki/Env_and_Stacks/Product_Requirements_Document I can't attend tomorrow, could someone chair the meeting? How to do it is mentioned on wiki page of Env and Stacks WG: https://fedoraproject.org/wiki/Env_and_Stacks/ Marcela -- 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: Source file audit - 2013-11-17
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/14/2014 10:03 AM, Jan Synacek wrote: > On 11/18/2013 04:54 PM, Kevin Fenzi wrote: >> jsynacek:BADURL:xferstats-2.16.tar.gz:xferstats > > xferstats.off.net seems to be down. I'll try to contact the author who is > mentioned in the manpage. In case I get no response, should I just remove the > URL? I couldn't find any other "upstream" sources. > I contacted the author and he told me that there was no upstream source anymore. I'm going to retire the package in 7 days. If somebody feels a strong urge to maintain it, let me know. - -- Jan Synacek Software Engineer, Red Hat -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS3RXIAAoJEL3BmMJQOtjBHP4QAJKb8M3ndnDfbNQai2UrJinj y/fE/IliaDd4F6773M96KJpHFUjp90s3AXunEGv1AxHFGTb2so0dRGquTBehLpxq 059lRxN6N3eQqih+YmRhVIaWSEWeiIS5VHKXwieGZRRU4XRGa5UhaMDfQrtd8//Y 0K31vERhNErje2xbdBNR1HHDc8yMgfqcxVIgTWjvrENC+M8nd65OlHSu/Ih6Fw4H V/dwo3ALaWoTLUe+QNPqP5AfuSCMwTbH8WVa+rW8faQCfic9bPlxBxSXZS+q0MzL gr0ARgpA88yVng/EYohz3pZgCUUMd7rpqg1i1IduNhOAMxhFKUN620KPGrLNIv6h VRC0rfYmyg1Nu1k6Kw8rA5pafFVXjQrUtRDERbnme+x0dHVR3ZG/mQ+kZkMLPkXT XMxafRNAm2+1EbWRlxq603klOPoUu4u3Vb94FsVTnE2v1ezcJKc95/ZFnRzx/dQ8 1gsAxq2uJfQHCDckbmlNUrJCH3nAdDPSZBwIA9FeReraBG8A1/UpQYuDZYVfr5YY W+IzASDpFG+Nfti330yWnexUwrTJa6Bbnx3KBC0m+W4j34GBvycYgVXvrWmEQi0M yWUUcdaonxI+3o3X9TmJCox6XK8o2DC0At7jK1Is2cKTToycN7iqOiuvpJBleCc+ bm/JBUP/i64Xm4xzXuPd =0xBS -END PGP SIGNATURE- -- 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: F20: Puppet depchain pulls in Java
Dne 17.1.2014 23:34, Martin Langhoff napsal(a): > Interestingly enough, after uninstalling jruby, rubypick still thinks > it's installed! > > [martin@tp-martin puppet-rlgold.git]$ ruby --help > This is Fedora's rubypick - a Ruby runtime chooser. You can use it > to execute Ruby programmes with any Fedora Ruby runtime. > These currently include: > Ruby - binary /usr/bin/ruby-mri - Installed > JRuby - binary /usr/bin/jruby - Installed > To run a specific runtime, use: > ruby _mri_ [params] > ruby _jruby_ [params] > The default is _mri_. > (...) > > [martin@tp-martin puppet-rlgold.git]$ stat /usr/bin/jruby > stat: cannot stat ‘/usr/bin/jruby’: No such file or directory > > The whole thing seems... suboptimal :-) > > Seems to be bug. Haven't seen any bug report from you yet, so I did one for you: https://github.com/bkabrda/rubypick/issues/4 Vít -- 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 Moving to testing repo?
On 17/01/14 07:27, Mathieu Bridon wrote: > On Fri, 2014-01-17 at 07:11 +0100, Daniel Pocock wrote: > >> I've been trying to do this for a new package, cajun-jsonapi >> >> bodhi refuses to let me request the update, it always gives the >> message: >> >> "cajun-jsonapi-2.0.3-1.el6 not tagged as an update candidate" >> >> >> It is in the Git repository branch for EPEL6 >> >> http://pkgs.fedoraproject.org/cgit/cajun-jsonapi.git/tree/?h=el6 >> >> and it is built on EPEL6: >> >> http://koji.fedoraproject.org/koji/buildinfo?buildID=489563 >> >> Would anybody know what I am doing wrong? Or is there some cooling off >> period before new packages can go to EPEL? > The build is indeed not tagged as an update candidate, it is tagged as > "trashcan". The change to trashcan happened some time after I tried to request the update. I received an email telling me that I had not made any update and that it would be tagged trashcan. > That means is has been (or soon will be, I forgot) removed. > > That being said, the build never succeeded: > http://koji.fedoraproject.org/koji/taskinfo?taskID=6385065 > > It is quite weird though that it is the tagging task which failed, > something seems to have gone wrong here. > > What you could do is: > koji tag-pkg dist-6E-epel-testing-candidate cajun-jsonapi-2.0.3-1.el6 > > That should put the build back in the proper state, and then Bodhi will > let you create the update. > > It looks like this worked, thanks for the feedback ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 11:29 AM, drago01 wrote: > On Mon, Jan 20, 2014 at 10:08 AM, Hans de Goede wrote: >> Hi All, >> >> As indicated here: >> https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights >> >> I'm working on making the X server run as a regular user. I actually have >> this >> pretty much working. >> >> So now it is time to start looking into some of the corner cases, or rather >> at >> the elephant in the room. What about non-kms drivers. We still have the vesa >> driver around as most prominent example, and this is useful for some oddball >> cards and for cards which are too new. >> >> I would like to not break the vesa driver, while still killing the suid bit >> on >> the X server. >> >> I'm currently thinking about implementing the following solution: >> >> 1) Make the X server a regular binary without any special rights >> >> 2) Implement a small suid root wrapper which gets the Xorg name and >> launches the real Xorg binary. >> >> This wrapper will search for kms capable cards and if one is found drop >> all root rights before executing the real Xorg binary. If no kms capable >> cards are found it will execute the real Xorg binary with root rights. >> >> 3) Put this wrapper in a separate package, make it part of comps so it >> will get installed by default, but don't depend on it in any packages >> so that security sensitive users can simply do >> "rpm -e xorg-x11-server-suid-helper" > > That will break badly for upgrades. If someone is using a ums driver, upgrades > and nothing pulls in the helper he / she will end up with a broken setup. (sent to eerily). So we should just let ums drivers require it. (Because they technically do require it after all). A user that does not use ums drivers can still remove (along with the drivers). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
On Mon, Jan 20, 2014 at 10:08 AM, Hans de Goede wrote: > Hi All, > > As indicated here: > https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights > > I'm working on making the X server run as a regular user. I actually have > this > pretty much working. > > So now it is time to start looking into some of the corner cases, or rather > at > the elephant in the room. What about non-kms drivers. We still have the vesa > driver around as most prominent example, and this is useful for some oddball > cards and for cards which are too new. > > I would like to not break the vesa driver, while still killing the suid bit > on > the X server. > > I'm currently thinking about implementing the following solution: > > 1) Make the X server a regular binary without any special rights > > 2) Implement a small suid root wrapper which gets the Xorg name and > launches the real Xorg binary. > > This wrapper will search for kms capable cards and if one is found drop > all root rights before executing the real Xorg binary. If no kms capable > cards are found it will execute the real Xorg binary with root rights. > > 3) Put this wrapper in a separate package, make it part of comps so it > will get installed by default, but don't depend on it in any packages > so that security sensitive users can simply do > "rpm -e xorg-x11-server-suid-helper" That will break badly for upgrades. If someone is using a ums driver, upgrades and nothing pulls in the helper he / she will end up with a broken setup. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
Hi, On 01/20/2014 10:16 AM, Peter Robinson wrote: As indicated here: https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights I'm working on making the X server run as a regular user. I actually have this pretty much working. So now it is time to start looking into some of the corner cases, or rather at the elephant in the room. What about non-kms drivers. We still have the vesa driver around as most prominent example, and this is useful for some oddball cards and for cards which are too new. I would like to not break the vesa driver, while still killing the suid bit on the X server. I'm currently thinking about implementing the following solution: 1) Make the X server a regular binary without any special rights 2) Implement a small suid root wrapper which gets the Xorg name and launches the real Xorg binary. This wrapper will search for kms capable cards and if one is found drop all root rights before executing the real Xorg binary. If no kms capable cards are found it will execute the real Xorg binary with root rights. 3) Put this wrapper in a separate package, make it part of comps so it will get installed by default, but don't depend on it in any packages so that security sensitive users can simply do "rpm -e xorg-x11-server-suid-helper" I'm not 100% sold on my own idea yet. The whole idea of dropping the suid bit is to remove the rather large attack surface the xserver offers. With the helper for people running kms that attack surface is reduced to a quite small, easily audited helper. But for people without kms nothing changes. On x86 most users will fall in the with kms category, but what about ie ARM? At the moment on ARM most devices that have X use the xorg-x11-drv-modesetting driver which I believe uses the KMS kernel drivers so I'm presuming we'll be OK on that front. The other two that are in use are xorg-x11-drv-armsoc (currently supported via the DRM_EXYNOS module, in theory can support other Mali GPUs) and xorg-x11-drv-omap (DRM_OMAP) which I believe also use the equivalent KMS drivers but I might be wrong there. Moving forward I can't see any new ARM devices not supporting KMS as I doubt they'll get accepted into the mainline kernel without it. So maybe we should not build, nor install, the helper for ARM at all ? We likely either have kms or in some (respin) cases fbdev there neither of which will need root rights. And the same likely goes for other non x86 archs, so maybe the helper should be an x86 only thing, for vesa (or other ums driver) support on oddball + very new cards ? Regards, Hans -- 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: F20: Puppet depchain pulls in Java
Dne 18.1.2014 07:40, Michael Stahnke napsal(a): > On Fri, Jan 17, 2014 at 6:53 PM, Rahul Sundaram wrote: >> Hi >> >> >> On Fri, Jan 17, 2014 at 9:43 PM, Mo Morsi wrote: >>> Yes as others have mentioned puppet requires ruby(release) which is >>> satisfied by both ruby-mri and jruby > So should it just require ruby-mri? > > The divergence from the way upstreams handle ruby here is quite > difficult to work with. I find ruby-pick ruby-pick has hardly anything to do with upstream similarly to RVM. > and bundler patching to be > less fun/friendly than having what I'd expect form upstream. This is going to be resolved with RubyGems 2.2 I hope. > I'm not > in love with the way upstream handles/does things, but I don't really > understand what happened to the 'upstream first' mantra. Here we > (Fedora) just made up their own rules and moved forward. > > >> >> ... which is fine. However yum install puppet should be pulling in only >> one. Not both. I would say almost everybody would expect that to be >> ruby-mri > I would say exactly everybody, since on jruby there are issues. If only RPM could give us way how to give a hint that MRI is preferred, if nothing satisfies ruby(runtime_executable) Vít -- 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: SELinux RPM scriplet issue annoucement
On Mon, 20 Jan 2014 01:53:42 -0500, Nathaniel McCallum wrote: > Is it possible to build a one-time build of selinux-policy without > scriptlets so that the update will succeed? Define what you mean with "update will succeed". Simply replacing the bad package with a new package doesn't fix it. The selinux-policy-targeted scriptlets run some stuff to activate the changed policy. See: rpm -q --scripts selinux-policy-targeted Some of that would need to be run manually, at least. Also don't forget other updates in the same transaction. They won't install without problems as long as RPM scriptlets don't execute. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC: what to do with ums when the X server is not suid root ?
> As indicated here: > https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights > > I'm working on making the X server run as a regular user. I actually have > this > pretty much working. > > So now it is time to start looking into some of the corner cases, or rather > at > the elephant in the room. What about non-kms drivers. We still have the vesa > driver around as most prominent example, and this is useful for some oddball > cards and for cards which are too new. > > I would like to not break the vesa driver, while still killing the suid bit > on > the X server. > > I'm currently thinking about implementing the following solution: > > 1) Make the X server a regular binary without any special rights > > 2) Implement a small suid root wrapper which gets the Xorg name and > launches the real Xorg binary. > > This wrapper will search for kms capable cards and if one is found drop > all root rights before executing the real Xorg binary. If no kms capable > cards are found it will execute the real Xorg binary with root rights. > > 3) Put this wrapper in a separate package, make it part of comps so it > will get installed by default, but don't depend on it in any packages > so that security sensitive users can simply do > "rpm -e xorg-x11-server-suid-helper" > > I'm not 100% sold on my own idea yet. The whole idea of dropping the suid > bit > is to remove the rather large attack surface the xserver offers. With the > helper for people running kms that attack surface is reduced to a quite > small, > easily audited helper. But for people without kms nothing changes. On x86 > most users will fall in the with kms category, but what about ie ARM? At the moment on ARM most devices that have X use the xorg-x11-drv-modesetting driver which I believe uses the KMS kernel drivers so I'm presuming we'll be OK on that front. The other two that are in use are xorg-x11-drv-armsoc (currently supported via the DRM_EXYNOS module, in theory can support other Mali GPUs) and xorg-x11-drv-omap (DRM_OMAP) which I believe also use the equivalent KMS drivers but I might be wrong there. Moving forward I can't see any new ARM devices not supporting KMS as I doubt they'll get accepted into the mainline kernel without it. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
RFC: what to do with ums when the X server is not suid root ?
Hi All, As indicated here: https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights I'm working on making the X server run as a regular user. I actually have this pretty much working. So now it is time to start looking into some of the corner cases, or rather at the elephant in the room. What about non-kms drivers. We still have the vesa driver around as most prominent example, and this is useful for some oddball cards and for cards which are too new. I would like to not break the vesa driver, while still killing the suid bit on the X server. I'm currently thinking about implementing the following solution: 1) Make the X server a regular binary without any special rights 2) Implement a small suid root wrapper which gets the Xorg name and launches the real Xorg binary. This wrapper will search for kms capable cards and if one is found drop all root rights before executing the real Xorg binary. If no kms capable cards are found it will execute the real Xorg binary with root rights. 3) Put this wrapper in a separate package, make it part of comps so it will get installed by default, but don't depend on it in any packages so that security sensitive users can simply do "rpm -e xorg-x11-server-suid-helper" I'm not 100% sold on my own idea yet. The whole idea of dropping the suid bit is to remove the rather large attack surface the xserver offers. With the helper for people running kms that attack surface is reduced to a quite small, easily audited helper. But for people without kms nothing changes. On x86 most users will fall in the with kms category, but what about ie ARM? Regards, Hans -- 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: Summary/Minutes from today's FESCo Meeting (2014-01-15)
On 01/16/2014 08:12 PM, Adam Williamson wrote:
> So, in the discussion of this, the following was presented as an
> obstacle:
>
> 18:31:13 Requires: foo > 1.0-1.%{release}
> 18:31:22 1.0-1.fc20.copr *satisfies* that
I have no objections against disttag. Hoever I would prefer "fc20-copr". I.e.
not to use dot as separator.
> Well, sure. But as mitr noted in passing - and everyone seemed to ignore
> - that's a terrible conditional in all sorts of ways:
> foo-1.0-1.%(nextrelease) satisfies that conditional too, even though
> it's probably identical to foo-1.0.1.%{release} .
>
> Does anyone have a case where %{release}.copr can cause problems that
> can't *also* be caused just by the same build having been done for
> multiple %{release}s?
>
> In the cited case, I'd use:
>
> Requires: foo >= 1.0-2
>
> or something similar. In general, isn't it pretty much universally
> accepted that you should try *really hard* to avoid the disttag being
> significant to your conditionals because it's just fundamentally
> unreliable to use it?
Well there is no solution. IMHO. If you would come with solution which is
smaller then original disttag you will have
problems with evaluation Obsoletes.
So you will either one problem or other.
Let the maintainer of that package in Copr projects solve it.
--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
