Re: Proposed F19 Feature: Developers Assistant
Jan Zelený píše v St 30. 01. 2013 v 08:22 +0100: > On 29. 1. 2013 at 19:18:32, Miloslav Trmač wrote: > > On Tue, Jan 29, 2013 at 9:14 AM, Jan Zelený wrote: > > > On 28. 1. 2013 at 14:28:06, Bill Nottingham wrote: > > >> Michael Scherer (m...@zarb.org) said: > > >> > Le lundi 28 janvier 2013 à 15:27 +0100, Jan Zelený a écrit : > > >> > > Currently we are working on some proof-of-concept stuff. But as an > > >> > > example, you can imagine a script for creation of C program > > >> > > templates. > > >> > > You will specify directory where it should create the program and > > >> > > (possibly) some specifics, like "I want to use threads" or "I need > > >> > > glib > > >> > > support". > > >> > > > > >> > > On output of that script you will have a template of C program with > > >> > > Makefile and you can start coding right away, no need for preparing > > >> > > the > > >> > > environment first. > > >> > > > >> > Something like https://wiki.ubuntu.com/Quickly ? > > >> > > > >> > Some work have been started by Mathieu bridon and Didier Roche for > > >> > quickly on Fedora a few years ago. Not sure where it went, but this > > >> > would be easier to use it rather than start from scratch. > > >> > > >> Do we know whether our target users for these quick-onroad scripts are > > >> using the commandline vs something like Eclipse? Just curious where the > > >> bang-for-the-buck is. > > > > > > Actually we want to address both. Use cases for Eclipse users will be > > > addressed in second stage of the project, hopefully utilizing whatever we > > > produce. > > > > Eclipse already has some of this, see e.g. > > http://wiki.eclipse.org/CDT/Autotools/User_Guide . > > I thought so, even though I didn't do much research on this front. Thanks for > the link, I'll check it out. From my knowledge every good IDE has its own kind of "developer assistant" so IMHO it would be hard to come up with an universal concept. And not everyone uses Eclipse ... Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Developers Assistant
On 29. 1. 2013 at 19:18:32, Miloslav Trmač wrote: > On Tue, Jan 29, 2013 at 9:14 AM, Jan Zelený wrote: > > On 28. 1. 2013 at 14:28:06, Bill Nottingham wrote: > >> Michael Scherer (m...@zarb.org) said: > >> > Le lundi 28 janvier 2013 à 15:27 +0100, Jan Zelený a écrit : > >> > > Currently we are working on some proof-of-concept stuff. But as an > >> > > example, you can imagine a script for creation of C program > >> > > templates. > >> > > You will specify directory where it should create the program and > >> > > (possibly) some specifics, like "I want to use threads" or "I need > >> > > glib > >> > > support". > >> > > > >> > > On output of that script you will have a template of C program with > >> > > Makefile and you can start coding right away, no need for preparing > >> > > the > >> > > environment first. > >> > > >> > Something like https://wiki.ubuntu.com/Quickly ? > >> > > >> > Some work have been started by Mathieu bridon and Didier Roche for > >> > quickly on Fedora a few years ago. Not sure where it went, but this > >> > would be easier to use it rather than start from scratch. > >> > >> Do we know whether our target users for these quick-onroad scripts are > >> using the commandline vs something like Eclipse? Just curious where the > >> bang-for-the-buck is. > > > > Actually we want to address both. Use cases for Eclipse users will be > > addressed in second stage of the project, hopefully utilizing whatever we > > produce. > > Eclipse already has some of this, see e.g. > http://wiki.eclipse.org/CDT/Autotools/User_Guide . I thought so, even though I didn't do much research on this front. Thanks for the link, I'll check it out. Jan signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Mon, Jan 28, 2013 at 10:27 AM, drago01 wrote: > On Mon, Jan 28, 2013 at 10:14 AM, Sandro Mani wrote: >> >> Can't we simply re-organize the fedoraproject website in such way that the >> download button points to something similar to the current "More options" >> page, maybe with a small description for each desktop like "easy to use" / >> "feature rich and customizable" / "based on the traditional desktop" / etc >> and possibly sorted by popularity, i.e. number of downloads? >> > No. > > People that know about different desktop are able to find them, but showing > a list of spins to new users that cannot make an informed decision would > just confuse them. > Ah, the standard question and the standard answer in the ever recurring thread (no offense!). Let me continue with the typical follow up so we don't break the balance in the galactic symmetry: The Fedora board clarified the vision statement and the user base back in 2009 [1]. Accordingly, Fedora targets: - Voluntary Linux consumer - Computer-friendly - Likely collaborator - General productivity user Well... Users with such characteristics will likely not get "confused" by a list of spin choices. I feel urged to finish with another standard proposal: Why don't we rotate the default desktop spin on each release between the major DEs? Best, Orcan [1] http://fedoraproject.org/wiki/User_base -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
> Firstly, some admins may be bound to mysql because of the certification or similar reason, but it probably won't be a technical reason. It'd be nice if admins work with providers in such cases and push them to add mariadb into set of "supported" options. I believe there won't be technical barrier to do so, so everyone could benefit from that. > Any admins retiring stability and certification probably shouldn't be running fedora anyway... But that's a side issue. As an admin they are welcome to use upstream (if oracle provide a fedora compatible repo) if mysql is removed from fedora... Or just not migrate to Mariadb if both end up packaged. > Second, if mariadb differs more in the future and stops to be "drop-in" replacement, then we'll need an alternative for applications, where mariadb won't be suitable enough. Nevertheless, this is not a current issue right now. > Indeed this is a straw man effectively. > When we're talking about testing, there is a mariadb package built in rawhide already: > https://koji.fedoraproject.org/koji/buildinfo?buildID=380910 > > We're not using obsoletes for now, so in order to install the builds you can do the following (after the packages will by synced into rawhide repo): > It'll be worthwhile typo get this into F18 as others have suggested to test without the risk of rawhide eating their data ;-) For what it's worth the brief interaction with the two Oracle employees in this thread sounds very similar to statements made by Oracle with respect to Hudson and OpenOffice.org with lots of promises on one hand but those mostly being fluff... Of course the history there speaks for itself. >From a pragmatic point of view it would make sense for Oracle to maintain the package within the Fedora Packaging Guidelines with mariadb having suitable provides I see no real benefit in allowing the two to be installed side by side though An admin should be able to switch fairly easily... The use of yum shell could even be avoided if the yum replace plugin at IUS community is brought up to official fedora repositories... If/when Oracle shows an inability to stay within the guidelines it should then be comparatively clean to remove the mysql packages from the official fedora repositories at the next sensible moment. This will certainly be an interesting topic over this development cycle as similar ones were in slightly different communities. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub linuxefi initrdefi
On Jan 29, 2013, at 6:15 PM, Adam Williamson wrote: > > I don't know, but I'm not sure how you have a UEFI install reading the > grub.cfg in /boot/grub2? *sigh* Yet Another Happy Day in UEFI and GRUB Land. The Fedora prebaked grubx64.efi doesn't include all GRUB modules (e.g. lvm, xnu) and it isn't looking for standalone GRUB modules in the location that grub2-install can install them into. And anaconda doesn't call grub2-install on UEFI computers. So I ran 'grub2-install' by itself (i.e. no flags at all), which creates a grubx.64.efi in /EFI/fedora that looks for GRUB modules in /boot/grub2/x86_64-efi, and also installs the modules in that folder. And it looks in /boot/grub2 for grub.cfg. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 01/29/2013 04:59 PM, Eric Smith wrote: > I don't disagree with the "more research and reason" part, but the > current default desktop has only been "our default" for four releases, > F15 through F18. I don't recall any serious "research and reason" > having been involved in the switch that occurred when F15 was being > developed. As far as I can tell, it was just thrust upon us without > much consideration as to whether it was good, bad, or indifferent. Actually a lot of research and reason went into GNOME 3's development [1], and we picked it up because we are an upstream distro [2]. So um, no, there was no "thrusting" going on. Again, you're gonna need better reasons than 'Alan Cox and Linus don't like it' especially because Linus uses it... ~m [1] https://live.gnome.org/GnomeShell/Design#Research.2C_testing_and_validation [2] https://fedoraproject.org/wiki/Staying_close_to_upstream_projects -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network Interface Names in saved firewall rules
On Tue, 29 Jan 2013 13:58:30 -0500, Bill Nottingham wrote: > Tomasz Torcz (to...@pipebreaker.pl) said: >> If I understand right, there is not guarantee >> "em1" would become "eno1" in 100% of cases. Iptables saved config >> would still need to be checked and verified. > > It won't, but having it be the same in the case where it *does* have the > same idea as biosdevname of 'first embedded interface', it could be > useful to have the same name. One way to handle this: when firewall rules are saved through firewalld (or iptables-services), it should also ask NetworkManager to save the network device names involved by their MAC addresses. Except when it knows a MAC address wouldn't be stable (e.g. tun/tap device with a kernel generated MAC address) or when running in a VM. The kernel could help in identifying devices would unstable MAC addresses. Just a documented and supported way to avoid reconfiguring the firewall on Fedora upgrade when network device name policy could potentially change would also help. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
On Tue, 29.01.13 14:17, Adam Williamson (awill...@redhat.com) wrote: > On Tue, 2013-01-29 at 14:06 -0700, Chris Murphy wrote: > > Am 29.01.2013 16:55, schrieb Bryn M. Reeves: > > > Again, unless you have very different storage controllers this will not > > > break. > > > > > > I really don't want or need every FC HBA kernel module, firmware bin file > > > or other junk in my laptop initramfs > > > "just in case" I happen to swap the disk to a laptop with built-in > > > fibre-channel :-) > > > The proposal not seem to be a significant performance enhancer. > > > > This is just what I was going to ask for: numbers. I don't see how we > can make a reasoned decision on a feature whose primary stated basis is > 'performance', when said feature provides zero data on the claimed > performance improvement. > > Per Lennart's mail it seems Chris' attempt is flawed, but at least he > made an attempt. Perhaps the feature proposers could take the time to > provide some numbers, taking Lennart's feedback into account? The onus > would appear to be on them. Full disclosure: I am actually really hoping for Harald's feature to include something that's not on the feature page right now: and that is the strongest form of host-only initrd support -- when the root disk is on a file system and storage that is accessible with compiled-in drivers, then dracut would skip generation of an initrd entirely. I have been running Linux regularly with and without initrd in the F15-F17 cycles (simply since we needed to support both cases with systemd). Then, booting without initrd usually cut off about 20% of the boot time. (I can't give you any up-to-date numbers for that however, since after I reinstalled my machine in the F18 development cycle I chose btrfs as root fs. btrfs is currently compiled as module, which means I cannot boot without initrd. I have now filed this bug so that I can start testing initrd-less boots again: https://bugzilla.redhat.com/show_bug.cgi?id=905611 ) Hey, Harald, any chance we can get the non-initrd-where-not-necessary trick, too? That would be too cool ;-) Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
How about doing a Cinnamon Spin at least for F19? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub linuxefi initrdefi
On Tue, 2013-01-29 at 18:01 -0700, Chris Murphy wrote: > On Jan 29, 2013, at 5:07 PM, Chris Murphy wrote: > > > > I've installed a few kernels with both grubby-8.20-1 and 8.22-1 and the > > problem consistently occurs with both of them. > > > > Do I reopen the bug, or file a new one? > > OK I see the problem, I think. > > For grub.cfg in /boot/grub2/ then grubby uses linuxefi and initrd. > > For grub.cfg in /boot/efi/EFI/fedora then grubby uses linuxefi and initrdefi. > > Shouldn't grubby use the correct command for the platform, regardless of the > location of the grub.cfg? I don't know, but I'm not sure how you have a UEFI install reading the grub.cfg in /boot/grub2? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
On Tue, Jan 29, 2013 at 7:43 PM, Matthew Miller wrote: > On Tue, Jan 29, 2013 at 06:57:29PM -0500, Josh Boyer wrote: >> >> that are built at kernel build time? the issue with building it at >> >> build time was making sure we knew exactly what sourcs we needed to >> >> ship to match all the binaries in the initramfs. the initramfs's we >> >> build and ship as part of teh install tree we know exactly what sources >> >> because they match what is in the release tree rather than what was in >> >> the buildroot at build time. >> > Does the kernel source RPM matching the initrd contain the necessary >> > sources? >> What? No. The kernel source RPM contains kernel sources. It has >> nothing to do with the initramfs. It creates a dummy file with the same >> name by dd'ing from /dev/zero and marks that as %ghost. The actual >> initramfs is built by grubby when the kernel package is installed because >> of the call to new-kernel-pkg. > > I kind of feel like you're just jumping in the middle here. The discussion Er... indeed. I was. I thought you were asking a different question. I misread, so apologies. > was about building these at kernel build time, rather than having grubby do > it. Then the above would cease to be true. If we've got binary bits we can't > track back to the source, I can see why legal would be concerned. Yes. Also, that sounds horrible. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub linuxefi initrdefi
On Jan 29, 2013, at 5:07 PM, Chris Murphy wrote: > > I've installed a few kernels with both grubby-8.20-1 and 8.22-1 and the > problem consistently occurs with both of them. > > Do I reopen the bug, or file a new one? OK I see the problem, I think. For grub.cfg in /boot/grub2/ then grubby uses linuxefi and initrd. For grub.cfg in /boot/efi/EFI/fedora then grubby uses linuxefi and initrdefi. Shouldn't grubby use the correct command for the platform, regardless of the location of the grub.cfg? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 895543] perl: Double-free when loading Digest::SHA object representing the intermediate SHA state from a file [fedora-all]
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=895543 --- Comment #5 from Fedora Update System --- perl-Digest-SHA-5.74-3.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=XBTKHzwbGK&a=cc_unsubscribe -- 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: Proposed F19 Feature: Dracut HostOnly
On Tue, Jan 29, 2013 at 06:57:29PM -0500, Josh Boyer wrote: > >> that are built at kernel build time? the issue with building it at > >> build time was making sure we knew exactly what sourcs we needed to > >> ship to match all the binaries in the initramfs. the initramfs's we > >> build and ship as part of teh install tree we know exactly what sources > >> because they match what is in the release tree rather than what was in > >> the buildroot at build time. > > Does the kernel source RPM matching the initrd contain the necessary > > sources? > What? No. The kernel source RPM contains kernel sources. It has > nothing to do with the initramfs. It creates a dummy file with the same > name by dd'ing from /dev/zero and marks that as %ghost. The actual > initramfs is built by grubby when the kernel package is installed because > of the call to new-kernel-pkg. I kind of feel like you're just jumping in the middle here. The discussion was about building these at kernel build time, rather than having grubby do it. Then the above would cease to be true. If we've got binary bits we can't track back to the source, I can see why legal would be concerned. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
On Tue, Jan 29, 2013 at 05:22:00PM -0600, Dennis Gilmore wrote: > On Tue, 29 Jan 2013 16:32:12 + > Matthew Garrett wrote: > > On Tue, Jan 29, 2013 at 09:53:32AM -0600, Dennis Gilmore wrote: > > > as legal has said we cannot pregenerate initramfses i think this > > > should be a non-starter. > > > > We already ship several pre-generated initramfses. > > > > that are built at kernel build time? the issue with building it at > build time was making sure we knew exactly what sourcs we needed to > ship to match all the binaries in the initramfs. the initramfs's we > build and ship as part of teh install tree we know exactly what sources > because they match what is in the release tree rather than what was in > the buildroot at build time. Yeah ok that case is a problem. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Tue, Jan 29, 2013 at 11:13 PM, Bill Nottingham wrote: > Kay Sievers (k...@vrfy.org) said: >> > Realistically, it's new textual files, replacing old textual files, which >> > are then compiled into a binary file. I'm not sure why there's the >> > intermediate step of a second textual format, but there is. >> >> Because the original text file is a hack and a format specific to the >> PCI/USB IDs, and makes no sense at all for a generic hwdb. > > pci:v0010* > ID_VENDOR_FROM_DATABASE=Allied Telesis, Inc > > It's not like that's that much more of a generic format. :) It is entirely generic. It can carry arbitrary numbers of freely named key/value pairs basically unlimited in their size. Is extensible, uses flexible and extensible string matches like modaliases for kernel modules. Nothing you would find in the PCI/USB IDs hack. So what do you criticize here? >> >> It could go into another package when things have settled down, but >> >> there will be lots of other data in the same database shipped by >> >> systemd itself, like keymaps, power settings whitelists, which we >> >> cannot really and should not move out to a generic package. >> > >> > ... which, again, is not something you want to be updating the main >> > systemd package all the time for. >> >> Which, again, is not needed at all, as mentioned above. :) > > Is it strictly needed? No. > > Is it needlessly making the problem worse? Yes. Worse? If we want an update package, it can drop the files in the same directory the default files are, and they will be used instead. Oh, and there are more copies of the PCI+USB IDs files in individual packages already, just run: find /usr -name pci.ids Maybe we should care about them first. :) > Either you're intending for the lifetime of your OS to be shipping systemd > updates that update the base data set, I don't intend to ship update packages in the context of systemd, we can just update the data in the package like we add patches for other fixes, in case we need an update. In the end PCI+USB IDs are just pretty boring names for humans, not used in the system itself. What makes them so special? It really sounds more like cosmetic care, than a real technical need to update these more often than we will need to update systemd anyway. > or you're intending to be shipping > updated data sets in a separate package. We can just do that, but still could ship the default data in the main package. > Given systemd's churn rate, the > first seems impractical, and if you're doing the second Hmm, check how often hwdata was updated, vs. systemd was updated :) http://pkgs.fedoraproject.org/cgit/hwdata.git/tree/hwdata.spec#n40 http://pkgs.fedoraproject.org/cgit/systemd.git/tree/systemd.spec#n730 > why not split it out to begin with? (Much like the preset files.) Because preset files are for spins, and not generally useful static data. They should be provided by the people doing a spin, but all spins run on the same hardware. :) And because we are not there yet, with introducing rather fragile inter-package dependencies; things should have settled down before we do this. It's all still under development. And because a major part of the data the hwdb will carry in the future will be the equivalent of udev rules, and should not be shipped by a different package, because it it might carry specifics needed for a certain functionality, just like the udev rules do today. If we want to artificially declare the PCI+USB IDs different from the rest of the growing hwdb data, and split that into a different package and the rest not; sure, we can do that when things have stabilized, but so far I'm not really sure if that will give is a significant advantage, considering that updates just can be installed along with the default data. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
On Tue, 29 Jan 2013 18:53:00 -0500 Matthew Miller wrote: > On Tue, Jan 29, 2013 at 05:22:00PM -0600, Dennis Gilmore wrote: > > > We already ship several pre-generated initramfses. > > that are built at kernel build time? the issue with building it at > > build time was making sure we knew exactly what sourcs we needed to > > ship to match all the binaries in the initramfs. the initramfs's we > > build and ship as part of teh install tree we know exactly what > > sources because they match what is in the release tree rather than > > what was in the buildroot at build time. > > Does the kernel source RPM matching the initrd contain the necessary > sources? not for every binary in the initramfs its much more than just the kernel and its modules. Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
On Tue, Jan 29, 2013 at 6:53 PM, Matthew Miller wrote: > On Tue, Jan 29, 2013 at 05:22:00PM -0600, Dennis Gilmore wrote: >> > We already ship several pre-generated initramfses. >> that are built at kernel build time? the issue with building it at >> build time was making sure we knew exactly what sourcs we needed to >> ship to match all the binaries in the initramfs. the initramfs's we >> build and ship as part of teh install tree we know exactly what sources >> because they match what is in the release tree rather than what was in >> the buildroot at build time. > > Does the kernel source RPM matching the initrd contain the necessary > sources? What? No. The kernel source RPM contains kernel sources. It has nothing to do with the initramfs. It creates a dummy file with the same name by dd'ing from /dev/zero and marks that as %ghost. The actual initramfs is built by grubby when the kernel package is installed because of the call to new-kernel-pkg. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub linuxefi initrdefi
On Jan 29, 2013, at 4:52 PM, Chris Murphy wrote: > > On Jan 29, 2013, at 4:33 PM, Adam Williamson wrote: > >> I'd go for grubby. This sounds vaguely familiar, though - try searching >> bugzilla for 'initrdefi' first, to see if there's an existing report. > > https://bugzilla.redhat.com/show_bug.cgi?id=859285 > > Closed as fixed in 8.20-1.fc18. > > At the time of the mass yum update, this is the version of grubby that was > installed; while the update applied 8.22-1.fc18. I don't know if the old or > the new is used in such a case. I've installed a few kernels with both grubby-8.20-1 and 8.22-1 and the problem consistently occurs with both of them. Do I reopen the bug, or file a new one? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
On Tue, Jan 29, 2013 at 05:22:00PM -0600, Dennis Gilmore wrote: > > We already ship several pre-generated initramfses. > that are built at kernel build time? the issue with building it at > build time was making sure we knew exactly what sourcs we needed to > ship to match all the binaries in the initramfs. the initramfs's we > build and ship as part of teh install tree we know exactly what sources > because they match what is in the release tree rather than what was in > the buildroot at build time. Does the kernel source RPM matching the initrd contain the necessary sources? -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub linuxefi initrdefi
On Jan 29, 2013, at 4:33 PM, Adam Williamson wrote: > I'd go for grubby. This sounds vaguely familiar, though - try searching > bugzilla for 'initrdefi' first, to see if there's an existing report. https://bugzilla.redhat.com/show_bug.cgi?id=859285 Closed as fixed in 8.20-1.fc18. At the time of the mass yum update, this is the version of grubby that was installed; while the update applied 8.22-1.fc18. I don't know if the old or the new is used in such a case. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Reading the topic about Cinnamon as Default Desktop. For my view, Cinnamon is nothing more than a heavily tweaked Gnome Shell based on reactive feeling. It only duplicated the effort already covered by Gnome development. Issue like nautilus removal of some functionality could be resolved by creating the adds like it happened with nautilus-terminal. I find incredible when it comes to desktop environment like Gnome a caging fighting style occur. It tells a lot about which individuals really are in order to safely ignore them. From my eyes, Cinnamon is nothing special, unworthy as default desktop in Fedora. Luya -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub linuxefi initrdefi
On Tue, 2013-01-29 at 16:29 -0700, Chris Murphy wrote: > Is it the responsibility of grubby, or the kernel rpm, when writing > out an updated grub.cfg, to include initrdefi? And are these commands > applicable on all (U)EFI? > > > After updating an EFI booting Mac to 3.7.4-204, I get a brief message > from GRUB saying that the kernel must be loaded first, then a kernel > panic. The new menu entry for this kernel uses linuxefi, but it uses > initrd not initrdefi as the other entries do. > > > If I manually edit the grub.cfg to use initrdefi, I don't get this > error or panic. And grub2-mkconfig also produces a grub.cfg using > initrdefi. Therefore it appears the lack of this command causes boot > failure, but I'd like to know what component the bug should be filed > against. I'd go for grubby. This sounds vaguely familiar, though - try searching bugzilla for 'initrdefi' first, to see if there's an existing report. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: grub linuxefi initrdefi
On Tue, Jan 29, 2013 at 6:29 PM, Chris Murphy wrote: > Is it the responsibility of grubby, or the kernel rpm, when writing out an > updated grub.cfg, to include initrdefi? And are these commands applicable on > all (U)EFI? Grubby. All the kernel rpm does is call new-kernel-pkg (which is provided by grubby). josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
grub linuxefi initrdefi
Is it the responsibility of grubby, or the kernel rpm, when writing out an updated grub.cfg, to include initrdefi? And are these commands applicable on all (U)EFI? After updating an EFI booting Mac to 3.7.4-204, I get a brief message from GRUB saying that the kernel must be loaded first, then a kernel panic. The new menu entry for this kernel uses linuxefi, but it uses initrd not initrdefi as the other entries do. If I manually edit the grub.cfg to use initrdefi, I don't get this error or panic. And grub2-mkconfig also produces a grub.cfg using initrdefi. Therefore it appears the lack of this command causes boot failure, but I'd like to know what component the bug should be filed against. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
On Tue, 29 Jan 2013 16:32:12 + Matthew Garrett wrote: > On Tue, Jan 29, 2013 at 09:53:32AM -0600, Dennis Gilmore wrote: > > as legal has said we cannot pregenerate initramfses i think this > > should be a non-starter. > > We already ship several pre-generated initramfses. > that are built at kernel build time? the issue with building it at build time was making sure we knew exactly what sourcs we needed to ship to match all the binaries in the initramfs. the initramfs's we build and ship as part of teh install tree we know exactly what sources because they match what is in the release tree rather than what was in the buildroot at build time. Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: New firstboot
On Tue, 2013-01-29 at 20:20 +0100, Stijn Hoop wrote: > On Tue, 29 Jan 2013 14:07:55 -0500 > john.flor...@dart.biz wrote: > > > > From: Martin Sivak > > > the tool will be started using systemd unit file which can be > > > disabled. It will have to be explicit (even minimal install needs > > > users or root password), but we can figure something out. > > > > In my experience, root password is handled by the installer and > > firstboot is not needed to configure users if puppet is being used to > > configure them. (Also there are many Fedora systems out there having > > only root and the system accounts -- i.e., no real users.) Having to > > disable the firstbooot systemd unit file just to get to a root prompt > > so that puppet can be installed would be a PITA. The whole idea of > > puppet is to avoid having to such things because it can automate them. > > What he said -- forcing a root pw or creating users is going to be a > PITA for us. Please add a way to disable it, preferably using kickstart. You're aware that this is already the case in F18 and all previous releases, right? You can't get out of anaconda without setting a root password. He said root password OR users, not root password AND users. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Tue, 2013-01-29 at 23:52 +0100, Michael Scherer wrote: > > And then we wonder why MATE and Cinnamon got the most press coverage > > in Fedora 18 and why there has been a huge user spike in the last 30 > > days. It hasn't been because of systemd, Gnome 3.6, and Anaconda 18. > > You are on serious drugs if you believe that. > > I am delighted to announce you that Red Hat has a policy of not > tolerating drugs on the work place. So you should be utterly relieved to > know that no people posting here with a @redhat.com email should be > under the influence of any serious hallucinogens. > > And I cannot speak for the others, but I have myself a pretty strict > policy of avoiding drugs and alcohols when posting on mailing lists even > when not being at the work place. I'll drink to that! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
Dear Dan, Le mardi 29 janvier 2013 à 04:13 -0800, Dan Mashal a écrit : > Now I know that we are both biased here, however what it really feels > like here is REDHAT If I may interrupt you, that's written in 2 words, Red Hat. Not wanting to deviate from your discourse with my rambling about the red baseball cap of the founder, may I just request that please respect the official spelling as a true gentleman ? > employees want Gnome 3 and they are giving a bunch of bullshit excuses > on why it should be, referencing various stupid apple to orange > comparisons from 10 years ago. Why don't we take a poll where no Red > Hat employees can vote. Only non Red Hat Fedora employees and the > board itself can make a final decision after considering what FESCO > has to say about it. Again, if i may, from a purely mathematics point of view, either your poll would be significantly different without 5000 people, or you don't. If you think 5000 people can make a significant difference ( and I say 5000, but in practice, more than half of them would not take interest due to them not being on technical side of the things, and I would estimate that more than half of the remaining being on others projects than the linux distribution would not also honor us of their opinion either ), I would dare to say that your sample is pretty small. If we suppose those 5000 persons can make a huge difference in the poll ( huge difference being more than 5%, all voting to gnome 3 ), that mean that a poll would have less than 100 000 users. While that seems a lot for the casual observer, that would be only 5% of the unique visitors to the main website, according to https://fedoraproject.org/wiki/Statistics#fedoraproject.org_unique_visitors ). So if we take a estimation where everybody visiting the website vote, those 5000 people would represent 0.25% of the potential sample based on past measures, and that's almost nothing. And that's a supposition of having 5% of difference to be significant while your thesis is that so many people want something else than gnome 3 than 5% shouldn't really matter. If you don't think these 5000 people make a difference at all ( ie 0.25% of the people who would see the poll, without any slashdot announce or anything ), then why exclude them ? Even if we consider they all ask to their household to answer the poll ( a quite dishonest move IMHO and be assured that I would not do it and firmly encourage others to not do it either), that would maybe go to 1%. Let's say 2% if they ask to their neighbours in exchange of some chocolat cakes ( oh yes, chocolate cake, there is such felony theses days ). On the other hand, based on what happened to Mandriva a few months ( around summer 2012 ) for the name of their new foundation, it doesn't take much to derail a poll, as they would explain if you ask them nicely. And while I focused on the purely mathematical part of your bold proposal, I would add that exclusion of a rather significant part of the community do not seems like a good idea to promote cooperation. You see, my noble friend, that's kinda a condition for team work such as the work we should be doing at the moment, and should be promoted rather than demoted. > Face it. Fedora 15 Gnome 3 cause a major uproar. Anaconda on RHEL6 is > easier to use than Anaconda 18. Almost 3 years later and "oh yeah we > realized we should probably add a real "fallback" mode to Gnome 3. If I may again interrupt, if we count 2 years of existence of gnome shell for public consumtion, and counting the time needed to write and discuss with others people ( since the whole discussion of dropping fallback come from Vincent Untz ), that would be 1.5 years, not 3. > Meanwhile the main people writing code are not the community. > Meanwhile MATE is lighter weight than Gnome 2.3, If i may again interrupt, I think you mean 3.2 or 3.4, not 2.3. > has numerous bug fixes, > will have full support for systems/logind.. > Something even Gnome 3 still has trouble with. So I looked and found ... 1 single bug. https://bugzilla.redhat.com/show_bug.cgi?id=869998 It is here since 4 days. It seems that I may indeed be unable to find more, having naively typed "logind" in the small white box of bugzilla and looked at the 10 bugs found. Likely a shortcoming of the perfidious engine behind the website, and so I would request that you provides the needed information in order to overcome our mutual misunderstanding. > Is it really that scary for you guys to think about something else > besides Gnome 3 and KDE? > > Not enough support? Then step up and quit whining. You know how to > help, Red Hat employees. > > Don't be selfish. This is Fedora not RHEL. This is a community based > distribution not Red Hats playground. Please feel free to correct me > if I'm wrong. > > Everyone loves to dance around the fact about what Fedora is or isn't. > > > This isn't one persons decision and its not 2003. > > Get with the times. Your proj
Re:
On Tue, Jan 29, 2013 at 11:23 PM, Bill Nottingham wrote: > G.Wolfe Woodbury (redwo...@gmail.com) said: >> > The kernel nowadays comes with built-in support for the vast majority of >> > all common storage hardware anyway, because AHCI is pretty universally >> > established. Outside of servers non-AHCI controllers practically don't >> > exist anymore. >> >> This is simply not true. >> >> There are hundreds of thousands of older desktops that are not >> technically servers that have lots of older interfaces. >> >> To say that non-AHCI controllers don't matter is to place a dignificant >> barrier to use or adoption of Linux or Fedora. > > AHCI dates to before when RHEL 5 was released in 2007. We also build > in ATA_PIIX, which covers a large number of generations before that. > > Does hardware exist that's not covered by this? Of course. However, > I'd also bet that those installing Fedora on that hardware are those > that are capable of rebuilding an initramfs if they move an existing > system to such hardware. Right, the common hardware we should cover very well, even with a host-only initramfs. People who are able shuffle disks from one hardware to the other will be able to create a generic initramfs, either before moving things around, or with the rescue system on the new one. We still do not encode any disk location/property/serial number/path into the initramfs, and we will be able to find the disks/rootfs, even when we move the disk(s) around. Because people mentioned that: none of that was true for Windows, which is very picky about any topology or driver change regarding the disk. A simple port change or haredware reconfiguration on Windows often rendered the disk unbootable, even on the same machine. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: New firstboot
On Tue, 2013-01-29 at 15:47 -0500, Simo Sorce wrote: > So far I just skipped firstboot by using tricks, like telling it I was > going to configure a network server and then just canceling. But it > would be nicer if I could simply skip it. Current firstboot does not run if you boot to anything below graphical.target (for old-schoolers - anything below runlevel 5). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Trusted Network Connect (TNC)
Avesh Agarwal (avaga...@redhat.com) said: > >Right now it is done using wpa_supplicant provided cli. > > Just to clarify a little bit further, wpa_supplicant provided cli > takes care of authentication and tnc's end point assessment. Once it > is done, NM or network scripts takes care of setting up networking > as usual. I have not checked if the current support of > wpa_supplicant in NM is enough for this. My concern is with it being something that has to be massaged on the commandline by hand. I'm not sure it should be presented as a 'Feature' to the users if it's not integrated into how the system normally works. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re:
G.Wolfe Woodbury (redwo...@gmail.com) said: > > The kernel nowadays comes with built-in support for the vast majority of > > all common storage hardware anyway, because AHCI is pretty universally > > established. Outside of servers non-AHCI controllers practically don't > > exist anymore. > > This is simply not true. > > There are hundreds of thousands of older desktops that are not > technically servers that have lots of older interfaces. > > To say that non-AHCI controllers don't matter is to place a dignificant > barrier to use or adoption of Linux or Fedora. AHCI dates to before when RHEL 5 was released in 2007. We also build in ATA_PIIX, which covers a large number of generations before that. Does hardware exist that's not covered by this? Of course. However, I'd also bet that those installing Fedora on that hardware are those that are capable of rebuilding an initramfs if they move an existing system to such hardware. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
On Tue, 2013-01-29 at 14:06 -0700, Chris Murphy wrote: > Am 29.01.2013 16:55, schrieb Bryn M. Reeves: > > Again, unless you have very different storage controllers this will not > > break. > > > > I really don't want or need every FC HBA kernel module, firmware bin file > > or other junk in my laptop initramfs > > "just in case" I happen to swap the disk to a laptop with built-in > > fibre-channel :-) > The proposal not seem to be a significant performance enhancer. This is just what I was going to ask for: numbers. I don't see how we can make a reasoned decision on a feature whose primary stated basis is 'performance', when said feature provides zero data on the claimed performance improvement. Per Lennart's mail it seems Chris' attempt is flawed, but at least he made an attempt. Perhaps the feature proposers could take the time to provide some numbers, taking Lennart's feedback into account? The onus would appear to be on them. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 01/28/2013 09:56 AM, inode0 wrote: After four releases it isn't bad to step back and take a look at how things are working out. I hope we can do that with an eye to where we want to go in the future rather than looking to the past. I couldn't have said it better. I'm much more concerned about providing a good experience for Fedora users than about Cinnamon in particular. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
On Jan 29, 2013, at 2:29 PM, Lennart Poettering wrote: > Much of the time is saved in the bootloader, since the initrd imager is > now much shorter the boot loader will require muss less time to read it > into memory. systemd-analyze won't show you this data (unless you run a > git version and use gummiboot as boot loader.) There's less than 1 second improvement from GRUB timeout to login prompt on the VM backed by SSD. There's maybe 4 seconds improvement on bare metal using this same "feel" metric. I haven't used gummiboot, so maybe I'll do some testing in the next cycle. For now, I've had quite enough of "it's a dessert topping and a floor wax" Rube Goldberg method of booting a computer with a UX I could hardly imagine my Doppelgänger inventing. > (And 10s boot, that's bad. Do you have LVM in the loop? No LVM in either case. The 10s result is ext4 no journal single partition, VDI, VirtualBox, on OS X, on SSD. So that's two hits (vbox and xnu). Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Kay Sievers (k...@vrfy.org) said: > > Realistically, it's new textual files, replacing old textual files, which > > are then compiled into a binary file. I'm not sure why there's the > > intermediate step of a second textual format, but there is. > > Because the original text file is a hack and a format specific to the > PCI/USB IDs, and makes no sense at all for a generic hwdb. pci:v0010* ID_VENDOR_FROM_DATABASE=Allied Telesis, Inc It's not like that's that much more of a generic format. :) > >> It could go into another package when things have settled down, but > >> there will be lots of other data in the same database shipped by > >> systemd itself, like keymaps, power settings whitelists, which we > >> cannot really and should not move out to a generic package. > > > > ... which, again, is not something you want to be updating the main > > systemd package all the time for. > > Which, again, is not needed at all, as mentioned above. :) Is it strictly needed? No. Is it needlessly making the problem worse? Yes. Either you're intending for the lifetime of your OS to be shipping systemd updates that update the base data set, or you're intending to be shipping updated data sets in a separate package. Given systemd's churn rate, the first seems impractical, and if you're doing the second, why not split it out to begin with? (Much like the preset files.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 01/29/2013 12:50 AM, Adam Williamson wrote: On Sun, 2013-01-27 at 14:53 +, Jaroslav Reznik wrote: = Features/Cinnamon as Default Desktop = https://fedoraproject.org/wiki/Features/Cinnamon_as_Default_Desktop Feature owner(s): Eric Smith Just some input on a few things that have been raised in this thread: 1. What is 'default'? The 'default' desktop in Fedora is: * What you get when you click on the big 'Download Now!' button at https://fedoraproject.org/get-fedora * What is selected by default in a DVD / network install * What's pictured in all the official screenshots in press stuff, documentation etc * What's documented in our official docs (mostly) 2. Can't we just not have a default? Not really. Others have touched on this, but the websites team really wants the simplicity of a straightforward 'Download' link that gets you a live image, and that pretty much requires a default desktop. We also have to have _something_ that we take pictures of for the docs. We could not select any desktop by default in DVD / network installs, but we tried that for F18 Alpha, IIRC, and I don't recall that anyone really liked it. 3. What does QA test? What do you think about this? If I can presume to speak for QA - in theory, changing the default desktop doesn't have a huge impact on us. Our desktop validation tests are written fairly generically, and already applicable to all desktops. We already provide the infrastructure for testing of multiple desktops: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test and ask users of the major Fedora desktops to provide results. What QA actually commits to testing is the set of 'release blocking desktops', which is currently defined - pretty much entirely for historical reasons - as 'GNOME and KDE'. We require that the GNOME and KDE columns on the test matrix (see above) be filled out and no release blocking bugs in those desktops be known, before a release goes out. The web stuff can easily be address with gnome.fedoraproject.org, kde.fedoraproject.org, lxde.fedoraproject.org,xfce.fedoraproject.org etc. each with an a "Download" button, The QA community makes the criteria each sub community follows the test cases and ensures that their spins passes. If it does it will be skipped that release cycle or simply released when it does ( same as secondary arch ) If somehow this feature got accepted, what we'd do is give Cinnamon the position currently given to 'Desktop' in that matrix, adjust the text "The current set of release-blocking desktops is GNOME and KDE" on the release criteria pages (obviously this feature requires Cinnamon to be added to that set; whether it replaces one or the other, or is just added, would have to be settled), and...that'd be about it. Obviously, we'd then prioritize Cinnamon validation testing. If the proposal involved adding Cinnamon to the set of release blocking desktops, that would add 50% to our desktop validation testing workload (3 'release blocking desktops' rather than 2), which is a chunk of extra work but not impossible. If the proposal involved replacing one of the existing 'release blocking desktops', our workload would be mostly unchanged. QA strictly tests and focuses on the CoreOS + X and each community surrounding each spins cover what ever is added on top of that. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 01/28/2013 09:27 AM, Peter Robinson wrote: The gnome desktop certainly isn't perfect but I see a lot more users using it than most of the rest of the other options. That's selection bias. It's the default, so of course it's going to get more users. That doesn't necessarily mean that they like it more than alternatives. The fact that GNOME is working on a "classic mode" in and of itself demonstrates that someone has finally realized that not all users want a tablet-style interface for their desktop. However, we unfortunately don't have any hard quantitative information about what users want. I based my proposal on having watched several moderately experienced computer users struggle with Gnome Shell and complain that it was more difficult for them to use than what they were accustomed to. I realize that this is only anecdotal evidence, and that there reportedly are other users that found Gnome Shell to be easier to use. I don't believe the "no one uses it so we should change" has much credence I agree, and certainly didn't make that argument in the proposal. but it would be nicer if the gnome team actually initiated a feedback loop with Fedora about some of the issues too. That would be great. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re:
On 01/29/2013 01:18 PM, Lennart Poettering wrote: > > The kernel nowadays comes with built-in support for the vast majority of > all common storage hardware anyway, because AHCI is pretty universally > established. Outside of servers non-AHCI controllers practically don't > exist anymore. This is simply not true. There are hundreds of thousands of older desktops that are not technically servers that have lots of older interfaces. To say that non-AHCI controllers don't matter is to place a dignificant barrier to use or adoption of Linux or Fedora. I suspect that working in a situation where one is not buying or maintaining ones own computer has produced a newrsighted view of what the computing ecoshpere has lurking in it. -- G.Wolfe Woodbury redwo...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: AnacondaNewUI Followup
On Tue, 2013-01-29 at 14:15 +, Jaroslav Reznik wrote: > * Add new firstboot-type questions to the second hub (dependent on the > firstboot work, which is another feature). Per my questions on the 'new firstboot' feature, this is one that hits my radar screen. The key function of firstboot is user creation, which is obviously important, and s-c-users has some specific capabilities in this area. Is there a plan to review all the capabilities of s-c-users and ensure the new anaconda code is a sufficiently complete replacement within the f19 timeframe? Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 01/29/2013 05:25 AM, Dan Mashal wrote: Lets have a poll. A very public one. On the main website. Not somebody's blog. And let's let the users decide what they want. I'll tell you what, last time I checked #1 spin is KDE. I like that idea. It's ultimately up to FESCo to decide, but a poll would give them more information as a basis for the decision. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On 01/28/2013 08:47 AM, Máirín Duffy wrote: I think switching the desktop that has been our default for over 10 years and 18 releases requires just a bit more research and reason than that. ~m I don't disagree with the "more research and reason" part, but the current default desktop has only been "our default" for four releases, F15 through F18. I don't recall any serious "research and reason" having been involved in the switch that occurred when F15 was being developed. As far as I can tell, it was just thrust upon us without much consideration as to whether it was good, bad, or indifferent. My proposal is at least only that, a proposal, and is not being thrust upon anyone without discussion and ultimately a vote. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: GLIBC 2.17
On Mon, 2013-01-28 at 11:02 +0100, Florian Weimer wrote: > > GLIBC 2.17 was released at the end of 2012; we have been closely tracking > > the > > GLIBC 2.17 development code in Fedora Rawhide and addressing any issues as > > they arise. > > The __secure_getenv to secure_getenv renaming need to be reflected in a > few packages (as of Fedora 18): > openssl-1.0.1c-7.fc18.src.rpm Fixed already in rawhide. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
On Tue, 29.01.13 14:06, Chris Murphy (li...@colorremedies.com) wrote: > Am 29.01.2013 16:55, schrieb Bryn M. Reeves: > > Again, unless you have very different storage controllers this will not > > break. > > > > I really don't want or need every FC HBA kernel module, firmware bin file > > or other junk in my laptop initramfs > > "just in case" I happen to swap the disk to a laptop with built-in > > fibre-channel :-) > > > The proposal not seem to be a significant performance enhancer. > > > Fairly stock Fedora 18, on SSD: > > [root@f18v ~]# systemd-analyze > Startup finished in 2185ms (kernel) + 1493ms (initrd) + 5834ms (userspace) = > 9513ms > > After making 91-host-only.conf and running dracut -f. I get a 7.2MB initramfs > instead of 31MB. And: > > [root@f18v ~]# systemd-analyze > Startup finished in 1892ms (kernel) + 769ms (initrd) + 6086ms (userspace) = > 8749ms > > > ---Same test, different CPU, HDD: > > Stock: > > [root@f18s boot]# systemd-analyze > Startup finished in 1180ms (kernel) + 3538ms (initramfs) + 20934ms > (userspace) = 25653ms > > host-only initramfs: > > [root@f18s ~]# systemd-analyze > Startup finished in 1082ms (kernel) + 2914ms (initramfs) + 25410ms > (userspace) = 29407ms > > > Curiously, the userspace figure consistently is longer when the > initramfs is smaller. (Now if someone wants to explain how the kernel > has 1/2 the time on a core2duo+HDD, compared to corei7+SSD, I can > accept that offline.) Much of the time is saved in the bootloader, since the initrd imager is now much shorter the boot loader will require muss less time to read it into memory. systemd-analyze won't show you this data (unless you run a git version and use gummiboot as boot loader.) That userspace is slower without initrd is probably because now some jobs that the initrd already did have to be done by userspace instead. Make sure to drop /.readahead before making these tests, and then reboot at least twice (ignoring the first run) before posting any performance data. Otherwise the readahead logic will skew your results. (And 10s boot, that's bad. Do you have LVM in the loop? LVM is the primary reason why our boots are slow. If you try to analyze your boot times it's best to get LVM out of the equation entirely, as that fucks everything up due to its flawed device discovery logic.) Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
Am 29.01.2013 20:47, schrieb Chris Murphy: > > On Jan 29, 2013, at 12:34 PM, Reindl Harald wrote: > >> >> >> Am 29.01.2013 20:30, schrieb Chris Murphy: >>> >>> On Jan 29, 2013, at 11:56 AM, Reindl Harald wrote: grub2 in fedora is simply broken in this case https://bugzilla.redhat.com/show_bug.cgi?id=882721 >>> >>> So you've built grub2 from recent gnu.org source (Bazaar), and password >>> protection works? Just the Fedora version is broken? >> >> no, but i did not decide switch to grub2 with it >> wobbly configuration with a shell-language at all > > If it's fundamentally broken upstream, then it's not really a Fedora bug. it did work in F16 sometimes later the config-file where i have defined grub-pwd again after a lot of search was silently renamed to rpmsave and the password DISABLED without notice the user that his security is broken so this is a regression and it does not bother me who has made it - it was introduced after it had worked signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Tue, 2013-01-29 at 14:13 +, "Jóhann B. Guðmundsson" wrote: > On 01/29/2013 01:38 PM, Ralf Corsepius wrote: > > On 01/27/2013 03:53 PM, Jaroslav Reznik wrote: > >> = Features/Cinnamon as Default Desktop = > >> https://fedoraproject.org/wiki/Features/Cinnamon_as_Default_Desktop > >> > >> Feature owner(s): Eric Smith > >> > >> This feature proposes that Fedora switch the default desktop > >> interface from > >> Gnome 3 to Cinnamon. Cinnamon provides a desktop interface that is more > >> familiar to Windows and Gnome 2 users than the standard Gnome Shell > >> interface, > >> while being built from Gnome 3 components. > > > > Though I certainly would welcome Fedora to switch away from Gnome3 as > > default desktop, I do not see much sense in switching to Cinnamon, > > because Cinnamon is too similar to Gnome3. > > > > Instead, I'd propose Fedora to switch away from having *any* default > > GUI and offer Fedora users an equal choice between all different major > > DE Fedora ships (e.g. Gnome3, Cinnamon, MATE, KDE. xfce ...) > > That's the only right and correct way forward and then this "default" > *DE dispute can finally be put to rest... I mentioned this idea in my post yesterday. I don't think it's really practical to 'not have a default', for a few reasons listed there, which you don't seem to have addressed. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
Am 29.01.2013 16:55, schrieb Bryn M. Reeves: > Again, unless you have very different storage controllers this will not break. > > I really don't want or need every FC HBA kernel module, firmware bin file or > other junk in my laptop initramfs > "just in case" I happen to swap the disk to a laptop with built-in > fibre-channel :-) The proposal not seem to be a significant performance enhancer. Fairly stock Fedora 18, on SSD: [root@f18v ~]# systemd-analyze Startup finished in 2185ms (kernel) + 1493ms (initrd) + 5834ms (userspace) = 9513ms After making 91-host-only.conf and running dracut -f. I get a 7.2MB initramfs instead of 31MB. And: [root@f18v ~]# systemd-analyze Startup finished in 1892ms (kernel) + 769ms (initrd) + 6086ms (userspace) = 8749ms ---Same test, different CPU, HDD: Stock: [root@f18s boot]# systemd-analyze Startup finished in 1180ms (kernel) + 3538ms (initramfs) + 20934ms (userspace) = 25653ms host-only initramfs: [root@f18s ~]# systemd-analyze Startup finished in 1082ms (kernel) + 2914ms (initramfs) + 25410ms (userspace) = 29407ms Curiously, the userspace figure consistently is longer when the initramfs is smaller. (Now if someone wants to explain how the kernel has 1/2 the time on a core2duo+HDD, compared to corei7+SSD, I can accept that offline.) Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: kworker is using up a lot of CPU
On Jan 29, 2013, at 11:44 AM, Eberhard Schruefer wrote: > I'm seeing kworker using up around 80% CPU time constantly and the laptop is > running hot. > This is in cases when you expect the system to be idle? i.e. no disk access, no active processes running, or network activity? Or is there something going on, like a file copy, but you just don't expect kworker to be consuming 80%? If the latter, I have a similar case with two (U)EFI laptops; I haven't narrowed it down to network access or disk access. But if neither are occurring, then I do get idle and no kworker process CPU % is significant. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Tue, Jan 29, 2013 at 9:06 PM, Bill Nottingham wrote: > Kay Sievers (k...@vrfy.org) said: >> The hwdb is drop-in directory based, which means: >> - additionally installed data overwrites shipped data >> - stuff with the same file name in /etc/ disables stuff in /usr/lib/ >> >> Users can just install update packages, or add their own files, which >> will not conflict with the default shipped data. > > That's really not what we need, though - we have standing requests > in That Other OS for regular updates of the hardware database as used > by the tools, and having to spin systemd for this is way overkill. Sure, create an RPM with non-conflicting files that are in /etc, or sort numerically *after* the default files. >> > 1) Duplicates the data. >> > 1a) Will the two databases be kept in sync? How will that happen? >> >> No. In the long run the old textual files will no longer be used. It >> was a really bad idea from the start to parse several megabytes of >> ever-growing text files for every query submitted; it was showing up >> as CPU spikes in all sort of profiles. That model of implementing >> low-level operating system tools should just not be continued in the >> future. The systemd hwdb data can be queried almost for free. > > Realistically, it's new textual files, replacing old textual files, which > are then compiled into a binary file. I'm not sure why there's the > intermediate step of a second textual format, but there is. Because the original text file is a hack and a format specific to the PCI/USB IDs, and makes no sense at all for a generic hwdb. >> > 2) Breaks the hwdata-vs-code separation that was created earlier. >> > What were the reasons of the separation, and why are they no longer >> > applicable now? >> >> It's just not needed because of the /usr/lib/ etc/ and drop-in >> directory overwrite logic, that works for all other default vs. >> custom/update settings. > > That method implies the administrator wants to do the update without > touching the code - what we have now is the *distributor* wants to > do the update without touching the code. And for that case, packaging > it seperately is simpler. Sure, there can be am any update packages as one wants, it will all work without any conflict with the original files. >> It could go into another package when things have settled down, but >> there will be lots of other data in the same database shipped by >> systemd itself, like keymaps, power settings whitelists, which we >> cannot really and should not move out to a generic package. > > ... which, again, is not something you want to be updating the main > systemd package all the time for. Which, again, is not needed at all, as mentioned above. :) Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: New firstboot
On Tue, 2013-01-29 at 14:28 -0500, john.flor...@dart.biz wrote: > Stijn Hoop wrote on 01/29/2013 14:20:50: > > > On Tue, 29 Jan 2013 14:07:55 -0500 > > john.flor...@dart.biz wrote: > > > > > > From: Martin Sivak > > > > the tool will be started using systemd unit file which can be > > > > disabled. It will have to be explicit (even minimal install > needs > > > > users or root password), but we can figure something out. > > > > > > In my experience, root password is handled by the installer and > > > firstboot is not needed to configure users if puppet is being used > to > > > configure them. (Also there are many Fedora systems out there > having > > > only root and the system accounts -- i.e., no real users.) Having > to > > > disable the firstbooot systemd unit file just to get to a root > prompt > > > so that puppet can be installed would be a PITA. The whole idea > of > > > puppet is to avoid having to such things because it can automate > them. > > > > What he said -- forcing a root pw or creating users is going to be a > > PITA for us. Please add a way to disable it, preferably using > kickstart. > > > > --Stijn > > I agree that it should be possible to easily disable firstboot in the > kickstart, but I also believe that one should be able to easily > sidestep firstboot after a regular install. I don't have the time to > create a kickstart for every conceivable use we have of Fedora here > (although that would clearly be my preference because then puppet > would be built in and start itself as "our firstboot and every > boot"). Presently I give users the Fedora image and then direct them > to a document that explains how to install and start puppet which does > the rest of the setup for them. It works very smoothly this way, but > only if there are very few steps between finish the install and > starting puppet. When I install a freeipa server I do not want firstboot because I am not going to create local users anyway. I am going to install freeipa and then create users in LDAP. So far I just skipped firstboot by using tricks, like telling it I was going to configure a network server and then just canceling. But it would be nicer if I could simply skip it. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
point of style (was Re: Proposed F19 Feature: New firstboot)
On 01/29/2013 12:31 PM, Chris Murphy wrote: On Jan 29, 2013, at 5:43 AM, Alec Leamas wrote: Please don't top-post [1] [1] http://fedoraproject.org/wiki/Mailing_list_guidelines#If_You_Are_Replying_to_a_Message It's amusing that it doesn't explain why. It just says don't do it. Top posting fails worse than bottom posting when what's quoted is poorly trimmed bottom posting. The lack of trim is common in both styles. But if done aggressively, I don't see the problem, e.g. had I top posted in this case, it would not be a real problem (vs an imaginary one). There's an old saying that 'punctuality is the courtesy of the kings'. Nowadays, careful editing of correspondence seems to have become as precious as the courtesy of the kings. It is hard to follow a message that has lots of boilerplate quoted or cut-and-paste material, with interesting, relevant content hidden at the end. In extreme, it makes a mockery of the common recommendation for bottom-posting --- if the quoted material is dumped indiscriminately in front of the new content, it would actually be less hard to read if it was top-posted, especially on the mobile devices that more of us use nowadays. In other words, literate persons are expected to weave the trimmed quotes and their responses into a coherent message --- that's the true meaning of "bottom-posting". In contrast, 'top-posting' implies giving up on trimming and editing for context. The point here is that careful editing makes huge difference to the reader. Sure, it takes time and effort --- as Seneca said, "I apologize for this very long letter but I was out of time" --- but the goal of writing is to communicate, so if it is worth doing at all, it is worth doing well. Please forgive this older colleague for droning on. I thought it could strengthen or inspire someone's resolve to keep up the style, and so would not be impolite to send it to the list even though most postings here are usefully edited. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Trusted Network Connect (TNC)
On 01/29/2013 03:16 PM, Avesh Agarwal wrote: On 01/29/2013 03:11 PM, Bill Nottingham wrote: Avesh Agarwal (avaga...@redhat.com) said: Is this intended to be integrated into NetworkManager? There is no such plan with this feature as right now the focus is to get the functionality right, but this is something that may be done in future fedora releases. Given that NM is the networking stack by default, and the traditional network scripts have no support for wpa_supplicant... how is this supposed to work out of the box, then? Bill Right now it is done using wpa_supplicant provided cli. Just to clarify a little bit further, wpa_supplicant provided cli takes care of authentication and tnc's end point assessment. Once it is done, NM or network scripts takes care of setting up networking as usual. I have not checked if the current support of wpa_supplicant in NM is enough for this. -- Thanks Avesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: High Availability Container Resources
>> > = Features/ High Availability Container Resources = >> > https://fedoraproject.org/wiki/Features/High_Availability_Container_Resources >> > >> > Feature owner(s): David Vossel >> > >> > The Container Resources feature allows the HA stack (Pacemaker + >> > Corosync) >> > residing on a host machine to extend management of resources into >> > virtual >> > guest instances (KVM/LXC). >> >> Is this about LXC or libvirt-lxc? These two are entirely different >> projects, sharing no code, which makes me wonder which project is >> meant >> here? > > Yep, I left that vague and should have used the term "linux containers" > instead of LXC. I'm going to update the page to reflect this. > > This feature architecturally doesn't care which project manages/initiates the > container. All we care about is that the container has it's own isolated > network namespace that is reachable from the host (or whatever node is > remotely managing the resources within the container) I intentionally chose > to use tcp/tls as the first transport we will support to avoid locking this > feature into use with any specific virt technology. > > With that said, I'm likely going to be focusing my test cases on libvirt-lxc > just because it seems like it has better fedora support. The LXC project > appears to be moving all over the place. Part of the project is really to > identify good use-cases for linux containers in an HA environment. The kvm > use-case is fairly straight forward and well understood though. I'll update > the page to list the linux container use-case as a possible risk. Please also keep in mind that LXC usually refers to a specific project, either the original "lxc" code or "libvirt-lxc". We have either Container Solutions in Fedora, like OpenVZ. You may be able to reach a broader base by making your solution work on that too (and of course, I'd be more than happy to help to trim any issues you may find) -- E Mare, Libertas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Trusted Network Connect (TNC)
On 01/29/2013 03:11 PM, Bill Nottingham wrote: Avesh Agarwal (avaga...@redhat.com) said: Is this intended to be integrated into NetworkManager? There is no such plan with this feature as right now the focus is to get the functionality right, but this is something that may be done in future fedora releases. Given that NM is the networking stack by default, and the traditional network scripts have no support for wpa_supplicant... how is this supposed to work out of the box, then? Bill Right now it is done using wpa_supplicant provided cli. -- Thanks Avesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Trusted Network Connect (TNC)
Avesh Agarwal (avaga...@redhat.com) said: > >Is this intended to be integrated into NetworkManager? > > There is no such plan with this feature as right now the focus is to > get the functionality right, but this is something that may be done > in future fedora releases. Given that NM is the networking stack by default, and the traditional network scripts have no support for wpa_supplicant... how is this supposed to work out of the box, then? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Trusted Network Connect (TNC)
On 01/29/2013 03:01 PM, Bill Nottingham wrote: Jaroslav Reznik (jrez...@redhat.com) said: = Features/Trusted Network Connect (TNC) = https://fedoraproject.org/wiki/Features/Trusted_Network_Connect_%28TNC%29 Feature owner(s): Avesh Agarwal This feature provides Trusted Network Connect(TNC) framework that can be used to assess and verify clients' posture (or integrity measurements or configuration) and its compliance to a predefined policy with existing network access control (NAC) solutions. Is this intended to be integrated into NetworkManager? Bill There is no such plan with this feature as right now the focus is to get the functionality right, but this is something that may be done in future fedora releases. -- Thanks Avesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Add LVM Thin provisioning support to the yum-fs-snapshot plugin
On Jan 29, 2013, at 12:44 PM, Bill Nottingham wrote: > > Is this actually useful if anaconda doesn't set up the system to use the > thinp pool to begin with? (Because it doesn't.) And should it? Last time I looked thinp LVs were considered experimental, I guess that was last May. Has this changed? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Kay Sievers (k...@vrfy.org) said: > The hwdb is drop-in directory based, which means: > - additionally installed data overwrites shipped data > - stuff with the same file name in /etc/ disables stuff in /usr/lib/ > > Users can just install update packages, or add their own files, which > will not conflict with the default shipped data. That's really not what we need, though - we have standing requests in That Other OS for regular updates of the hardware database as used by the tools, and having to spin systemd for this is way overkill. > > 1) Duplicates the data. > > 1a) Will the two databases be kept in sync? How will that happen? > > No. In the long run the old textual files will no longer be used. It > was a really bad idea from the start to parse several megabytes of > ever-growing text files for every query submitted; it was showing up > as CPU spikes in all sort of profiles. That model of implementing > low-level operating system tools should just not be continued in the > future. The systemd hwdb data can be queried almost for free. Realistically, it's new textual files, replacing old textual files, which are then compiled into a binary file. I'm not sure why there's the intermediate step of a second textual format, but there is. > > 2) Breaks the hwdata-vs-code separation that was created earlier. > > What were the reasons of the separation, and why are they no longer > > applicable now? > > It's just not needed because of the /usr/lib/ etc/ and drop-in > directory overwrite logic, that works for all other default vs. > custom/update settings. That method implies the administrator wants to do the update without touching the code - what we have now is the *distributor* wants to do the update without touching the code. And for that case, packaging it seperately is simpler. > It could go into another package when things have settled down, but > there will be lots of other data in the same database shipped by > systemd itself, like keymaps, power settings whitelists, which we > cannot really and should not move out to a generic package. ... which, again, is not something you want to be updating the main systemd package all the time for. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Trusted Network Connect (TNC)
Jaroslav Reznik (jrez...@redhat.com) said: > = Features/Trusted Network Connect (TNC) = > https://fedoraproject.org/wiki/Features/Trusted_Network_Connect_%28TNC%29 > > Feature owner(s): Avesh Agarwal > > This feature provides Trusted Network Connect(TNC) framework that can be used > to assess and verify clients' posture (or integrity measurements or > configuration) and its compliance to a predefined policy with existing > network > access control (NAC) solutions. Is this intended to be integrated into NetworkManager? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Tue, Jan 29, 2013 at 8:07 PM, Miloslav Trmač wrote: > On Sun, Jan 27, 2013 at 2:54 PM, Jaroslav Reznik wrote: >> = Features/SystemdHardwareDatabase = >> https://fedoraproject.org/wiki/Features/SystemdHardwareDatabase >> >> Feature owner(s): Kay Sievers >> >> The udevd service has a long history of managing kernel devices. Besides >> generating events when devices are discovered or removed it maintains a >> dynamic, stateless database of all available devices including meta data >> about >> them. With Fedora 19 we want to substantially enhance the metadata that udev >> keeps for each device, by augmenting it from a userspace database of non- >> essential information, that is indexed by device identification data such as >> PCI/USB vendor/product IDs. > > Some years ago all hardware data was moved out of various separate > packages into the "hwdata" package (even if it meant moving it out of > the original upstream source). The feature page doesn't even mention > the hwdata package. AFAICS this The hwdb is drop-in directory based, which means: - additionally installed data overwrites shipped data - stuff with the same file name in /etc/ disables stuff in /usr/lib/ Users can just install update packages, or add their own files, which will not conflict with the default shipped data. > 1) Duplicates the data. > 1a) Will the two databases be kept in sync? How will that happen? No. In the long run the old textual files will no longer be used. It was a really bad idea from the start to parse several megabytes of ever-growing text files for every query submitted; it was showing up as CPU spikes in all sort of profiles. That model of implementing low-level operating system tools should just not be continued in the future. The systemd hwdb data can be queried almost for free. > 1b) What is the long-term goal? Will one of the two go away? If > so, how and when? Phase out hwdata, as soon as things have stabilized enough, the remaining users have been converted, and people get used to the new data source. > 2) Breaks the hwdata-vs-code separation that was created earlier. > What were the reasons of the separation, and why are they no longer > applicable now? It's just not needed because of the /usr/lib/ etc/ and drop-in directory overwrite logic, that works for all other default vs. custom/update settings. It could go into another package when things have settled down, but there will be lots of other data in the same database shipped by systemd itself, like keymaps, power settings whitelists, which we cannot really and should not move out to a generic package. So all that theoretic code vs. data separation will not really mean much in the end, the hwdb will be much more than what hwdata was. It will take over quite a lot of what udev rules do today, and these should live in the main package. We will see, I think it's too early at the moment to introduce rather needless packaging complexities and dependencies for something that is still under development. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
Am 29.01.2013 20:30, schrieb Chris Murphy: > > On Jan 29, 2013, at 11:56 AM, Reindl Harald wrote: >> >> grub2 in fedora is simply broken in this case >> https://bugzilla.redhat.com/show_bug.cgi?id=882721 > > So you've built grub2 from recent gnu.org source (Bazaar), and password > protection works? Just the Fedora version is broken? no, but i did not decide switch to grub2 with it wobbly configuration with a shell-language at all signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 905112] Update to metacpan.org instead of search.cpan.org
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=905112 --- Comment #3 from Daniel Berrange --- Ah, I did not realize this was a part of the formatl packaging spec too. I'll look at raising that for discussion first, so guess this BZ can wait until that's resolved. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=FN1cQzSMYl&a=cc_unsubscribe -- 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: Proposed F19 Feature: systemd features
On Tue, 2013-01-29 at 14:30 -0500, Bill Nottingham wrote: > This is interesting, in that it's a feature that's occasionally requested > by various users and administrators. However, this is rather limited in > that only systemd stuff is using it now, and it's tied to the journal API. Actually, we're using it in GNOME too: http://git.gnome.org/browse/gnome-session/commit/?id=9ec4deede968ad55d18340109c5aa9f6416de13d -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Tue, 29.01.13 14:30, Bill Nottingham (nott...@redhat.com) wrote: > Jaroslav Reznik (jrez...@redhat.com) said: > > = Features/SystemdMessageCatalog = > > https://fedoraproject.org/wiki/Features/SystemdMessageCatalog > > > > Feature owner(s): Lennart Poettering > > > > Logging is essential for finding and tracking down system problems. Just > > finding > > and tracking them down however is seldom enough to actually get them fixed. > > With Journal Message Catalogs we want to link helpful meta information > > directly to many log messages applications generate, keyed off an ID > > identifying the type of message. This localized meta information can help > > the > > user to fix the problem, refer him to additional documentation, or even > > inform > > him where to get further help. > > This is interesting, in that it's a feature that's occasionally requested > by various users and administrators. However, this is rather limited in > that only systemd stuff is using it now, and it's tied to the journal API. > > Do we know 1) if anything else is going to start tagging messages in this > way (the kernel, other programs, etc.) I know that at least gnome-session started to tag some of its messages with a message ID. This is a relatively new feature, we haven't really began to advertise that this is now available too much. In fact, posting this as Fedora feature is our first step to make this more broadly known, and maybe get more people to use this. > 2) if it's possible to set the > MESSAGE_ID in some other structured way? Well there is no other structured API in our basic stack I was aware of, so no, you have to use the journal API for this. That said, libvirt actually uses structured logging to the journal now, but does not use our API for that, since they had some special needs. The local protocol is currently not documented, but is considered stable (I really should document it in the wiki, too), so they just issue the log messages on their own. At the moment systemd itself already generates quite a few messages already that have MESSAGE_IDs attached and message catalog entries. However, this is is far from complete, and we should improve the catalog entries and add more message IDS. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
Am 29.01.2013 19:48, schrieb Chris Murphy: > > On Jan 29, 2013, at 9:44 AM, Matthew Miller wrote: > >> (I'm not sure if the new installer >> even has an option for password-protecting grub2, offhand.) > > It doesn't. And this seems to be an area of confusion on the two grub lists > for users and distro developers alike, looking to implement it. So I'm not > certain that it's strictly an installer limitation. grub2 in fedora is simply broken in this case https://bugzilla.redhat.com/show_bug.cgi?id=882721 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 905112] Update to metacpan.org instead of search.cpan.org
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=905112 --- Comment #2 from Steven Roberts --- now putting on my co-maintainer hat for cpanspec... cpanspec aims to make spec files that follwot the fedora perl packaging guidelines. So, I think your best first stop would be with the PERL SIG to get the standards changed. I checked and the guideliens still say you should use search.cpan.org: https://fedoraproject.org/wiki/Packaging:Perl#URL_tag -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=UGTtVSnBgq&a=cc_unsubscribe -- 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: Proposed F19 Feature: Dracut HostOnly
On Jan 29, 2013, at 12:34 PM, Reindl Harald wrote: > > > Am 29.01.2013 20:30, schrieb Chris Murphy: >> >> On Jan 29, 2013, at 11:56 AM, Reindl Harald wrote: >>> >>> grub2 in fedora is simply broken in this case >>> https://bugzilla.redhat.com/show_bug.cgi?id=882721 >> >> So you've built grub2 from recent gnu.org source (Bazaar), and password >> protection works? Just the Fedora version is broken? > > no, but i did not decide switch to grub2 with it > wobbly configuration with a shell-language at all If it's fundamentally broken upstream, then it's not really a Fedora bug. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 905112] Update to metacpan.org instead of search.cpan.org
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=905112 --- Comment #1 from Steven Roberts --- I might have picked a nicer quote if you are trying to win support, but eh, that's besides the point :). I hadn't heard of metacpan.org before this. doesn't show up in any google search I have run before. searched for info on it directly and looks like it was launched about 1.5 years ago. above is speaking as a cpanspec user... -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=wlXmS7vyEx&a=cc_unsubscribe -- 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: Proposed F19 Feature: High Availability Container Resources
- Original Message - > From: "Lennart Poettering" > To: devel@lists.fedoraproject.org > Cc: devel-annou...@lists.fedoraproject.org, "David Vossel" > > Sent: Monday, January 28, 2013 4:10:00 PM > Subject: Re: Proposed F19 Feature: High Availability Container Resources > > On Sun, 27.01.13 17:32, Jaroslav Reznik (jrez...@redhat.com) wrote: > > > = Features/ High Availability Container Resources = > > https://fedoraproject.org/wiki/Features/High_Availability_Container_Resources > > > > Feature owner(s): David Vossel > > > > The Container Resources feature allows the HA stack (Pacemaker + > > Corosync) > > residing on a host machine to extend management of resources into > > virtual > > guest instances (KVM/LXC). > > Is this about LXC or libvirt-lxc? These two are entirely different > projects, sharing no code, which makes me wonder which project is > meant > here? Yep, I left that vague and should have used the term "linux containers" instead of LXC. I'm going to update the page to reflect this. This feature architecturally doesn't care which project manages/initiates the container. All we care about is that the container has it's own isolated network namespace that is reachable from the host (or whatever node is remotely managing the resources within the container) I intentionally chose to use tcp/tls as the first transport we will support to avoid locking this feature into use with any specific virt technology. With that said, I'm likely going to be focusing my test cases on libvirt-lxc just because it seems like it has better fedora support. The LXC project appears to be moving all over the place. Part of the project is really to identify good use-cases for linux containers in an HA environment. The kvm use-case is fairly straight forward and well understood though. I'll update the page to list the linux container use-case as a possible risk. -- Vossel > Lennart (Lennart, sorry, you're getting this response twice.) > -- > Lennart Poettering - Red Hat, Inc. > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Add LVM Thin provisioning support to the yum-fs-snapshot plugin
Jaroslav Reznik (jrez...@redhat.com) said: > = Features/YumFsSnapshotThinpSupport = > https://fedoraproject.org/wiki/Features/YumFsSnapshotThinpSupport > > Feature owner(s): Ondrej Kozina , Mike Snitzer > > > For the purposes of system rollback: Provide the ability to create a snapshot > of all thinly provisioned LVM2 volumes associated with FS mount points that > are relevant to a yum transaction. > > == Detailed description == > Yum's fs-snapshot plugin already has support for LVM2's old snapshots. LVM2's > new thinp snapshots offer much more performance and ease administration. It > is > desirable to have the life-cycle of snapshots that are created by yum's fs- > snapshot plugin be managed by the snapper utility. As such it could be that > the yum fs-snapshot plugin is extend to provide a wrapper around snapper for > the creation of thinp based snapshots. Is this actually useful if anaconda doesn't set up the system to use the thinp pool to begin with? (Because it doesn't.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: -> step backwards
Am 29.01.2013 16:55, schrieb Bryn M. Reeves: > Again, unless you have very different storage controllers this will not break. > > I really don't want or need every FC HBA kernel module, firmware bin file or > other junk in my laptop initramfs > "just in case" I happen to swap the disk to a laptop with built-in > fibre-channel :-) so make the one-liner and be happy as i do but do not make people need to know such details and call it improvement [root@srv-rhsoft:~]$ cat /etc/dracut.conf.d/91-host-only.conf hostonly="yes" signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Enterprise / distributed two-factor authentication
Jaroslav Reznik (jrez...@redhat.com) said: > = Features/EnterpriseTwoFactorAuthentication = > https://fedoraproject.org/wiki/Features/EnterpriseTwoFactorAuthentication > > Feature owner(s): Daniel Pocock > > Provide a flexible solution for two-factor authentication on a distributed > basis, suitable for enterprise and SSO. > > == Detailed description == > Most OTP solutions for two-factor authentication require some kind of storage > backend for counters or other volatile data. Early implementations work with > flat files on a single host. dynalogin was created to bring stability and > flexibility, storing counters in just about any type of database. Other > solutions such as totp-cgi have similar goals (although it only mentions > Postgres support, whereas dynalogin can use MySQL thanks to UNIXODBC). > dynalogin has been successfully integrated with the SimpleID provider for > OpenID authentication. I'd really prefer this be retitled in a way that more clearly defines what it is (i.e., Add SimpleIDandDynalogin2FA). As you can see from the responses, the definition of what is 'Enterprise' lies in the beholder. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
Jaroslav Reznik (jrez...@redhat.com) said: > = Features/DracutHostOnly = > https://fedoraproject.org/wiki/Features/DracutHostOnly > > Feature owner(s): Harald Hoyer > > Only create "host-only" initramfs images. A generic fallback image should be > installed by anaconda on installation/update and never ever be removed. > > == Detailed description == > Current initramfs images contain most of the kernel drivers to boot from any > hardware. This results in a very big initramfs, which takes a long time to > load on system start and a long time to create on kernel updates. Switching > to > host-only will improve the situation. To cope with hardware change, a boot > entry "Rescue System" should be installed with a full fledged initramfs also > containing debug tools. This boot entry can then be used to recover from > hardware changes and also from unforseen software failure after updates. Do we actually have agreement on the anaconda/lorax side for the changes required here? What happens if the updated system (due to userspace, SELinux policy, what have you) moves beyond something that can be properly rescued? Will there be a fedup module to regenerate the rescue image on OS upgrade? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: PreUpgrade Assistant
On 01/29/2013 01:05 PM, Phil Knirsch wrote: On 01/29/2013 05:57 PM, Rahul Sundaram wrote: Hi On Tue, Jan 29, 2013 at 11:37 AM, Jaroslav Reznik mailto:jrez...@redhat.com>> wrote: = Features/PreUpgrade Assistant = https://fedoraproject.org/wiki/Features/PreUpgrade_Assistant Feature owner(s): Nils Philippsen mailto:n...@redhat.com>>, Phil Knirsch mailto:pknir...@redhat.com>> The PreUgrade assistant is a tool to help people upgrade from one release to another and be sure to track important manual configuration changes they performed. Don't confuse users unnecessarily. Call this fedup-assistant or something else entirely. Rahul Yep, thats actually what we have in mind, just need to discuss and coordinate that with Will Woods and the anaconda team. Just wanted to make sure folks know about this planed "extension" of fedup. Thanks & regards, Phil It appears that some work has already been done on this by wwoods in the fedup repo. I have been helping him out a bit with the UI. https://github.com/wgwoods/fedup There is a prototype GUI in there that steps the user though process of preparing for the upgrade. Presently the GUI allows the user to choose where to install from (Online Repos, Optical Media or USB Media), Shows them the release notes, etc. It is mostly fairly similar in concept to the old preupgrade GUI. cheers, ryanlerch -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Tue, 29.01.13 20:07, Miloslav Trmač (m...@volny.cz) wrote: > On Sun, Jan 27, 2013 at 2:54 PM, Jaroslav Reznik wrote: > > = Features/SystemdHardwareDatabase = > > https://fedoraproject.org/wiki/Features/SystemdHardwareDatabase > > > > Feature owner(s): Kay Sievers > > > > The udevd service has a long history of managing kernel devices. Besides > > generating events when devices are discovered or removed it maintains a > > dynamic, stateless database of all available devices including meta data > > about > > them. With Fedora 19 we want to substantially enhance the metadata that udev > > keeps for each device, by augmenting it from a userspace database of non- > > essential information, that is indexed by device identification data such as > > PCI/USB vendor/product IDs. > > Some years ago all hardware data was moved out of various separate > packages into the "hwdata" package (even if it meant moving it out of > the original upstream source). The feature page doesn't even mention > the hwdata package. AFAICS this > > 1) Duplicates the data. > 1a) Will the two databases be kept in sync? How will that happen? The databases are kept in the systemd RPM in a generic source format (that is not the in the classic hwdb format) and are compiled into an indexed database at package installation. To update the various hardware databases one needs to rebuild the systemd RPM hence. Currently, the USB, PCI, OUI, IAB, ACPI, Bluetooth database are included. > 1b) What is the long-term goal? Will one of the two go away? If > so, how and when? Upstream lsusb has been updated to use libudev APIs to check the index database already. Something similar can be done by all other tools too. For devices that are discovered all matching database entries are attached to the respective udev devices anyway, and libudev also supports an API to lookup data for non-present hardware too. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Jaroslav Reznik (jrez...@redhat.com) said: > = Features/SystemdMessageCatalog = > https://fedoraproject.org/wiki/Features/SystemdMessageCatalog > > Feature owner(s): Lennart Poettering > > Logging is essential for finding and tracking down system problems. Just > finding > and tracking them down however is seldom enough to actually get them fixed. > With Journal Message Catalogs we want to link helpful meta information > directly to many log messages applications generate, keyed off an ID > identifying the type of message. This localized meta information can help the > user to fix the problem, refer him to additional documentation, or even > inform > him where to get further help. This is interesting, in that it's a feature that's occasionally requested by various users and administrators. However, this is rather limited in that only systemd stuff is using it now, and it's tied to the journal API. Do we know 1) if anything else is going to start tagging messages in this way (the kernel, other programs, etc.) 2) if it's possible to set the MESSAGE_ID in some other structured way? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
On Jan 29, 2013, at 11:56 AM, Reindl Harald wrote: > > grub2 in fedora is simply broken in this case > https://bugzilla.redhat.com/show_bug.cgi?id=882721 So you've built grub2 from recent gnu.org source (Bazaar), and password protection works? Just the Fedora version is broken? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: New firstboot
Stijn Hoop wrote on 01/29/2013 14:20:50: > On Tue, 29 Jan 2013 14:07:55 -0500 > john.flor...@dart.biz wrote: > > > > From: Martin Sivak > > > the tool will be started using systemd unit file which can be > > > disabled. It will have to be explicit (even minimal install needs > > > users or root password), but we can figure something out. > > > > In my experience, root password is handled by the installer and > > firstboot is not needed to configure users if puppet is being used to > > configure them. (Also there are many Fedora systems out there having > > only root and the system accounts -- i.e., no real users.) Having to > > disable the firstbooot systemd unit file just to get to a root prompt > > so that puppet can be installed would be a PITA. The whole idea of > > puppet is to avoid having to such things because it can automate them. > > What he said -- forcing a root pw or creating users is going to be a > PITA for us. Please add a way to disable it, preferably using kickstart. > > --Stijn I agree that it should be possible to easily disable firstboot in the kickstart, but I also believe that one should be able to easily sidestep firstboot after a regular install. I don't have the time to create a kickstart for every conceivable use we have of Fedora here (although that would clearly be my preference because then puppet would be built in and start itself as "our firstboot and every boot"). Presently I give users the Fedora image and then direct them to a document that explains how to install and start puppet which does the rest of the setup for them. It works very smoothly this way, but only if there are very few steps between finish the install and starting puppet. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
Miloslav Trmač (m...@volny.cz) said: > Some years ago all hardware data was moved out of various separate > packages into the "hwdata" package (even if it meant moving it out of > the original upstream source). The feature page doesn't even mention > the hwdata package. AFAICS this > > 1) Duplicates the data. > 1a) Will the two databases be kept in sync? How will that happen? It pulls from upstream at build time, from reading the code. > 2) Breaks the hwdata-vs-code separation that was created earlier. > What were the reasons of the separation, and why are they no longer > applicable now? It would be useful to be able to update this without updating systemd... is there any reason the perl generator for this can't be moved to hwdata itself and have *that* pull the upstream versions on build? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Tue, 29.01.13 04:13, Dan Mashal (dan.mas...@gmail.com) wrote: > There could be different "flavors" of Gnome. Now I know that we are both > biased here, however what it really feels like here is REDHAT > employees want Gnome 3 and they are giving a bunch of bullshit excuses on You know, Red Hat engineers are community members, too. Much like in the broader community there are RH engineers who are pro-GNOME and others who are anti-GNOME, or some who are pro-systemd and others who are anti-systemd. And these engineers tend to express their views pretty freely on a mailing list like this too. Hence it's not fair to assume RH as a single entity was trying to influence more here than others, and it's not fair to imply that not allowing RH folks to say their opinion would provide a fairer, closer-to-the-truth picture of opinions on GNOME either. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: New firstboot
On Tue, 29 Jan 2013 14:07:55 -0500 john.flor...@dart.biz wrote: > > From: Martin Sivak > > the tool will be started using systemd unit file which can be > > disabled. It will have to be explicit (even minimal install needs > > users or root password), but we can figure something out. > > In my experience, root password is handled by the installer and > firstboot is not needed to configure users if puppet is being used to > configure them. (Also there are many Fedora systems out there having > only root and the system accounts -- i.e., no real users.) Having to > disable the firstbooot systemd unit file just to get to a root prompt > so that puppet can be installed would be a PITA. The whole idea of > puppet is to avoid having to such things because it can automate them. What he said -- forcing a root pw or creating users is going to be a PITA for us. Please add a way to disable it, preferably using kickstart. --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
On Tue, 2013-01-29 at 09:53 -0600, Dennis Gilmore wrote: > as legal has said we cannot pregenerate initramfses Really? Why? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, Jan 29, 2013 at 12:46:29PM -0500, Bill Nottingham wrote: > It might be worth considering that we keep the one special case and > change the 'eno' prefix in udev to 'em'... this will help some. Yes! Very much! Not only will this practically easy things, it shifts the perception from "And we're changin' it all up again!" to "It's a refinement of the previous way". -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: New firstboot
> From: Martin Sivak > the tool will be started using systemd unit file which can be > disabled. It will have to be explicit (even minimal install needs > users or root password), but we can figure something out. In my experience, root password is handled by the installer and firstboot is not needed to configure users if puppet is being used to configure them. (Also there are many Fedora systems out there having only root and the system accounts -- i.e., no real users.) Having to disable the firstbooot systemd unit file just to get to a root prompt so that puppet can be installed would be a PITA. The whole idea of puppet is to avoid having to such things because it can automate them. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd features
On Sun, Jan 27, 2013 at 2:54 PM, Jaroslav Reznik wrote: > = Features/SystemdHardwareDatabase = > https://fedoraproject.org/wiki/Features/SystemdHardwareDatabase > > Feature owner(s): Kay Sievers > > The udevd service has a long history of managing kernel devices. Besides > generating events when devices are discovered or removed it maintains a > dynamic, stateless database of all available devices including meta data about > them. With Fedora 19 we want to substantially enhance the metadata that udev > keeps for each device, by augmenting it from a userspace database of non- > essential information, that is indexed by device identification data such as > PCI/USB vendor/product IDs. Some years ago all hardware data was moved out of various separate packages into the "hwdata" package (even if it meant moving it out of the original upstream source). The feature page doesn't even mention the hwdata package. AFAICS this 1) Duplicates the data. 1a) Will the two databases be kept in sync? How will that happen? 1b) What is the long-term goal? Will one of the two go away? If so, how and when? 2) Breaks the hwdata-vs-code separation that was created earlier. What were the reasons of the separation, and why are they no longer applicable now? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: AnacondaNewUI Followup
Jaroslav Reznik (jrez...@redhat.com) said: > * Make system-config-kickstart work again. The removal of > iw/GroupSelector.py from anaconda caused it to break. (#859928) Is this via replacing s-c-ks with anaconda itself, pulling the package selection spoke into s-c-ks, or...? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, 2013-01-29 at 18:38 +, Matthew Garrett wrote: > On Tue, Jan 29, 2013 at 12:32:30PM -0600, Dan Williams wrote: > > > Except then you run into phones or WWAN cards that show up as Ethernet > > devices, but aren't really Ethernet but just IP-in-8023-frames because > > that was easier to do on Windows. That one is quite fun, and there's no > > good way to catch them all. We're obviously behind by marking them > > FLAG_WWAN in the kernel, which has to be done by device IDs, becasue > > some devices use standard cdc-ether or cdc-eem and you can't reliably > > tell them apart from some random D-Link DUB100. > > Sure, but that's a fundamentally unsolvable problem - if my primary > network connection is via a USB device there's a reasonable chance that > it'll be called usb0 anyway. The name isn't providing extra information > here. Actually usbnet uses this logic: usb%d = default eth%d = FLAG_ETHER && !FLAG_POINTTOPOINT && !(dev_addr[0] & 0x02) wlan%d = FLAG_WLAN wwan%d = FLAG_WWAN so it's really a crapshoot depending on kernel version and which devices have been flagged explicitly. Some classes of device will get usb0 and some with get eth0 and there's no really clear line about which ones are actually really ethernet and which are pseduo-ethernet. Also, 'ipeth' (iPhone USB ethernet tethering) uses "eth%d". Go figure. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] please review: Ticket 433 - multiple bugs in start-dirsrv, stop-dirsrv, restart-dirsrv scripts
https://fedorahosted.org/389/ticket/433 https://fedorahosted.org/389/attachment/ticket/433/0001-Ticket-433-multiple-bugs-in-start-dirsrv-stop-dirsrv.patch -- Mark Reynolds Red Hat, Inc mreyno...@redhat.com -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Proposed F19 Feature: Dracut HostOnly
On Tue, 29 Jan 2013 11:48:01 -0700 Chris Murphy wrote: > > On Jan 29, 2013, at 9:44 AM, Matthew Miller > wrote: > > > (I'm not sure if the new installer > > even has an option for password-protecting grub2, offhand.) > > It doesn't. And this seems to be an area of confusion on the two grub > lists for users and distro developers alike, looking to implement it. > So I'm not certain that it's strictly an installer limitation. > > Chris Murphy > Not sure about the installer, but the one in kickstart is broken (and has been broken since GRUB2): https://bugzilla.redhat.com/show_bug.cgi?id=840160 It should be fixable though I've not yet found the time to dig into it. I only ran into this last week since I (apparently) skipped F17 / GRUB2. --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
Tomasz Torcz (to...@pipebreaker.pl) said: > > It might be worth considering that we keep the one special case and > > change the 'eno' prefix in udev to 'em'... this will help some. > > This could be dangerous. If I understand right, there is not guarantee > "em1" would become "eno1" in 100% of cases. Iptables saved config would > still need to be checked and verified. It won't, but having it be the same in the case where it *does* have the same idea as biosdevname of 'first embedded interface', it could be useful to have the same name. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
On Tue, 2013-01-29 at 13:45 -0500, Daniel J Walsh wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 01/29/2013 01:34 PM, Simo Sorce wrote: > > On Tue, 2013-01-29 at 13:28 -0500, Daniel J Walsh wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > >> > >> On 01/29/2013 11:20 AM, John Reiser wrote: > >> A generic fallback image should be installed by anaconda on > >> installation/update and never ever be removed. > >>> > Also, fallback has interesting security properties… > >>> > >>> > >>> "Rescue mode" forces a SELinux relabel at the next boot, and relabel > >>> can take a very long time. > >>> > >>> How does "fallback mode" handle this, particularly if there have been > >>> updates to SELinux policy after the fallback was created? > >>> > >> The reason for this is we do not know what files were created on the > >> system while SELinux was disabled (Policy Not Loaded). If you know you > >> did not created files on the system you could remove the /.autorelabel > >> file and boot without a relabel. > > > > Can we have a relabel mode that just searches only files changed after a > > specific date ? If we stored the time of last "good" shutdown somewhere it > > would mean we might be able to relabel only a minor subset of files, saving > > a lot of time ? > > > > Simo. > > > Well you would still need to search everywhere on the file system. for those > files. If the filesystem gave an easy way to find the latest fds that have > been changed, then ... > > I guess we could compare any file created after /.autorelabel, and then get > the relabel to be > > find / -newer /.autorelabel -print0 | restorecon -f - -0 Yeah that may be an idea, if you can insure .autorelabel is the first file that gets created. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, Jan 29, 2013 at 12:46:29PM -0500, Bill Nottingham wrote: > Miloslav Trmač (m...@volny.cz) said: > > >> That's always the hope, and then we meet the cold reality, where someone > > >> just patched 'em1' into everything and hoped that was good enough. But > > >> sure, 'damn the torpedoes' is a viable approach too. I guess I was just > > >> kind of hoping F19 would be a release without yet more churn in the core > > >> system where we could try and stabilize things a bit. > > >> > > > I agree. The scope says no impact, but who knows how many packages depend > > > on > > > hardcoded names. > > > > It's not only "em1" mistakenly hard-coded in applications; it's user's > > saved configuration, scripts etc., where often there is no practical > > alternative to "hard-coding". > > I would assume that it would only be for new installs, not for upgrades. Upgrades will retain biosdevname package, so names shouldn't change. > It might be worth considering that we keep the one special case and > change the 'eno' prefix in udev to 'em'... this will help some. This could be dangerous. If I understand right, there is not guarantee "em1" would become "eno1" in 100% of cases. Iptables saved config would still need to be checked and verified. -- Tomasz Torcz Morality must always be based on practicality. xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, Jan 29, 2013 at 06:29:35PM +, Matthew Garrett wrote: > > What is "The ethernet device"? It's the device that speaks ethernet and > which isn't wireless or a bridge. The correct way to identify it is to > look for devices that speak ethernet and which aren't wireless or > bridges. I can pretty much guarantee that I would not implement this correctly the first time. If there were an official tool for doing this, it would take the edge off the rename churning that's been going on for the last few years. I've hit too many renaming-related bugs to get excited about yet another attempt. On 90% of computers, eth0 is it, and all of this complicated stuff just makes it worse. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
On Jan 29, 2013, at 9:44 AM, Matthew Miller wrote: > (I'm not sure if the new installer > even has an option for password-protecting grub2, offhand.) It doesn't. And this seems to be an area of confusion on the two grub lists for users and distro developers alike, looking to implement it. So I'm not certain that it's strictly an installer limitation. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: New firstboot
On 2013-01-29 19:35, Chris Murphy wrote: On Jan 29, 2013, at 10:39 AM, "Jóhann B. Guðmundsson" wrote something about learning to read like the rest of the world. Indeed, I did learn, like most of the rest of the world today, to simply reply. And I learned to occasionally establish context with paraphrasing, and the occasional quote, when needed. Wholesale hand duplication of someone's letter to me, while replying to them inline, or at the bottom, would have been ridiculous. For many hundreds of years, all over the world, readers had good enough short term memory that merely receiving a reply was sufficient for effective communication, even among multiple parties. In effect, for most of human history, most of the world historically top posts. What has encouraged bottom posting and in-line response, is the perverted email client automatic quoting feature, when replying; not that bottom posting is any more or less, sensible than top posting. Chris Murphy It's all my fault, I know, but still: the subject of this thread is about firstboot. I dropped a short note about the agreements and guidelines we have on this list, hopefully seen as a friendly reminder - I had no other intent. If someone wants to start a new thread about the guidelines for making a reply on fedora-devel, please do. But I suggest that we close this threadlet instead of hijacking the subject to discuss something enterily different. --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/29/2013 01:34 PM, Simo Sorce wrote: > On Tue, 2013-01-29 at 13:28 -0500, Daniel J Walsh wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> On 01/29/2013 11:20 AM, John Reiser wrote: >> A generic fallback image should be installed by anaconda on >> installation/update and never ever be removed. >>> Also, fallback has interesting security properties… >>> >>> >>> "Rescue mode" forces a SELinux relabel at the next boot, and relabel >>> can take a very long time. >>> >>> How does "fallback mode" handle this, particularly if there have been >>> updates to SELinux policy after the fallback was created? >>> >> The reason for this is we do not know what files were created on the >> system while SELinux was disabled (Policy Not Loaded). If you know you >> did not created files on the system you could remove the /.autorelabel >> file and boot without a relabel. > > Can we have a relabel mode that just searches only files changed after a > specific date ? If we stored the time of last "good" shutdown somewhere it > would mean we might be able to relabel only a minor subset of files, saving > a lot of time ? > > Simo. > Well you would still need to search everywhere on the file system. for those files. If the filesystem gave an easy way to find the latest fds that have been changed, then ... I guess we could compare any file created after /.autorelabel, and then get the relabel to be find / -newer /.autorelabel -print0 | restorecon -f - -0 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEIGNcACgkQrlYvE4MpobOm0QCgmD0eaIy8arEliV2EEOg68iPE rjkAoKGTL1IhvVkqDM2phKbPqiyq+r+1 =zoBy -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
kworker is using up a lot of CPU
Hello, I did send the following message to the users-list but did not get a reply. Therefore I try here again. Meanwhile I found that somebody else filed a bug on bugzilla.kernel.org (*Bug* 53071* *Problems with gpe13 interrupt storm) about it. Is there something else I can do? Thanks. Eberhard Original post at the users list: I installed F18 on a Samsung NP700Z7C-S04 laptop. It is dual boot with WIN 8 and has UEFI enabled, but secure boot is disabled. I'm seeing kworker using up around 80% CPU time constantly and the laptop is running hot. I found several similar reports on other lists. Suggestions found there like having acpi=noirq and others didn't help. There is a closed bugzilla (Bug 840862) suggesting to do the following to find the cause of the problem: echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event cat /sys/kernel/debug/tracing/trace_pipe > out.txt In out.txt I find CPU:3 [LOST 12401 EVENTS] -0 [003] d.h. 1010.943940: workqueue_queue_work: work struct=880328a55910 function=acpi_os_execute_deferred workqueue=88032d856b40 req_cpu=0 cpu=0 -0 [003] d.h. 1010.943969: workqueue_queue_work: work struct=880328a55ad0 function=acpi_os_execute_deferred workqueue=88032d856b40 req_cpu=0 cpu=0 -0 [003] d.h. 1010.944000: workqueue_queue_work: work struct=880328a553d0 function=acpi_os_execute_deferred workqueue=88032d856b40 req_cpu=0 cpu=0 The acpi_os_execute_deferred message is showing up endlessly. Also suggested in the bugzilla is doing cat /proc/2/stack [] kthreadd+0x1e5/0x1f0 [] ret_from_fork+0x7c/0xb0 [] 0x What to do with this information? I'm running kernel 3.7.4-204.fc18.x86_64 (the earlier F18 kernels showed the same behaviour). Any help would be appreciated. Should I sent this to another list? Thanks. Eberhard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Dracut HostOnly
On Jan 29, 2013, at 6:09 AM, Jaroslav Reznik wrote: > A generic fallback image should be > installed by anaconda on installation/update and never ever be removed. FYI, this will require change/supplementing grub2, possibly with a 4x_custom file, or rescue specific, in /etc/grub.d. Without such addition, grub2-mkconfig will create a grub.cfg without the rescue entry. And grubby quickly messes up existing grub2 grub.cfgs by progressively deleting entries, so it may need to be looked at to make sure it doesn't delete either container entries, or the rescue entries themselves. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Tucan security issue unfixed
Hi I have retired this package in devel branch and rel-eng has blocked it. However EPEL branch is still active and I am not touching it. Someone handling EPEL should look into that. It is dangerous to let it remain in the repo IMO Rahul On Thu, Jan 24, 2013 at 1:10 AM, Rahul Sundaram wrote: > Hi > > https://bugzilla.redhat.com/show_bug.cgi?id=782999 > > This problem has been reported a while back and the maintainer seems > inactive. In any case, upstream seems dead as well ( > https://code.google.com/p/tucan/source/list). Can we remove this package? > > Rahul > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
