Re: Intel MIPI IPU6 cameras support
On 9/9/22 13:50, Leigh Scott wrote: Also note that you will also need to create a kmod package for the also out of tree v4l2-loopback kernel driver. The closed-source userspace bits Intel provide only work with gstreamer. So the way this is used on other distros is with a little helper process which runs a gstreamer-pipeline from the camera and then injects the resulting frames back into the kernel through v4l2-loopback so that e.g. firefox sees a good old /dev/video0 device. Regards, Hans v4l2loopback-kmod already exists. Thanks for the tips and advice, guys! I guess I should have explained myself better -- my current goal is, of course, to make things work for me. And as the next step I was thinking about a Copr repo, i.e. an equivalent of PPA/AUR. Then RPMFusion. I haven't really started the work so I was trying to avoid effort duplication and starting from zero in case somebody has already made some progress. Thanks! -- Vratislav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Intel MIPI IPU6 cameras support
Hello, I got a new Dell XPS laptop with the "amazing" [1] Intel MIPI IPU6 webcam. There are upstream repos with drivers [2] and user-space stuff and Ubuntu [3] and Arch [4] have user repositories with everything required packaged. I found nothing available for Fedora so before I go and spend a couple nights trying to make things work on Fedora I want to make sure that, by any chance, someone is not already working on this to avoid duplicate efforts. And I have to add a disclaimer right away: I have no idea when I will find enough time to do the work. [1] https://www.phoronix.com/news/Greg-KH-No-ADL-Webcam-Laptop [2] https://github.com/intel/ipu6-drivers [3] https://launchpad.net/~oem-solutions-group/+archive/ubuntu/intel-ipu6 [4] https://aur.archlinux.org/packages/intel-ipu6-dkms-git Thanks. -- Vratislav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: dnf makecache memory usage increase
On 8/1/22 13:43, Dusty Mabe wrote: Seems like this bug is relatedhttps://bugzilla.redhat.com/show_bug.cgi?id=1907030 We are hitting this issue in Fedora CoreOS CI on VMs with 1G of RAM. This also affects the Fedora 36 Cloud Base image provided as Vagrant box: $ vagrant init fedora/36-cloud-base $ vagrant up $ vagrant ssh -c "sudo dnf install openssl-devel" Fedora 36 - x86_64 3.3 MB/s | 81 MB 00:24 Fedora 36 openh264 (From Cisco) - x86_64 710 B/s | 2.5 kB 00:03 Fedora Modular 36 - x86_64 2.2 MB/s | 2.4 MB 00:01 Fedora 36 - x86_64 - Updates 3.6 MB/s | 24 MB 00:06 Connection to 192.168.121.178 closed by remote host. Connection to 192.168.121.178 closed. because it defaults to Memory: 512 M. And it is absolutely not Aarch64-specific. I've updated the aforementioned bug with the above reproducer. -- Vratislav Podzimek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Attempting to contact unresponsive maintainers - ggillies, vpodzime
Hi, I don't really know how I got to this list. I do have my new email address in FAS and I haven't gotten any questions about the AADG recently. Regards, Vratislav On 03/05/2018 09:10 PM, Kevin Fenzi wrote: > Greetings, we've been told that the email addresses for these package > maintainers are no longer valid. I'm starting the unresponsive > maintainer policy to find out if they are still interested in > maintaining their packages (and if so, have them update their email > addresses in FAS). > > If they're not interested in maintaining or we can't locate them in 1 > week, I'll have FESCo orphan the packages so that others can take them > over. > > If you have a way to contact these maintainers, please let them know > that we'd appreciate knowing what to do with their packages. Thanks! > > ggillies: > > rpms/rubygem-amq-protocol > rpms/rubygem-eventmachine > rpms/rubygem-em-worker > rpms/rubygem-sigdump > > vpodzime: > > Fedora Documentation/anaconda-addon-development-guide > > kevin > > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Anaconda LVM RAID
On Tue, 2017-02-21 at 12:32 -0700, Chris Murphy wrote: > On Tue, Feb 21, 2017 at 6:34 AM, Vratislav Podzimek <vpodz...@redhat.com> > wrote: > > > > On Wed, 2017-02-01 at 12:25 -0700, Chris Murphy wrote: > > > > > > Actually, I've got a concern about this feature. > > > > > > I'm not sure what gnome-shell depends on for monitoring mdadm arrays, > > > but I know it will put up a notification if an mdadm member becomes > > > faulty; because I've seen this notification. Maybe it's getting this > > > information from udisksd? In any case, I'm wondering whether the user > > > will still be notified of device failures in gnome-shell with this > > > change? > > I'm not seeing any code taking care of MD RAID device monitoring in > > udisks2. So it has to be somewhere else. Any ideas where to look? gvfs > > maybe? > > I'm not sure. With Fedora 25 this notification functionality is not > happening. I'm not sure what or when the regression happens, or even > if it's flawed testing. I did this in a virt-manager VM, and removing > the virtual block device, booting I get no notification. If I boot > with both devices and inside the VM I do: > > # echo 1 > /sys/block/sdb/device/delete > > I see complaints in kernel messages indicating the array is now > degraded, and udisks does pick up this fact: > > [ 80.911812] localhost.localdomain udisksd[1393]: Unable to resolve > /sys/devices/virtual/block/md127/md/dev-sdb2/block symlink > [ 80.912156] localhost.localdomain udisksd[1393]: Unable to resolve > /sys/devices/virtual/block/md127/md/dev-sdb2/block symlink > [ 80.912284] localhost.localdomain udisksd[1393]: Unable to resolve > /sys/devices/virtual/block/md126/md/dev-sdb1/block symlink > [ 80.912414] localhost.localdomain udisksd[1393]: Unable to resolve > /sys/devices/virtual/block/md126/md/dev-sdb1/block symlink Yeah, but that's not really figuring out that RAID is degraded. These are just error messages generated by udisksd still thinking the RAID is okay. So no signal emitted by udisksd here. > > But still no notification in GNOME Shell. I don't know if there's > something GNOME Shell is expecting to get additionally from udisksd, > if so it might actually be a storaged regression. In that case the > solution might need to be abstracted from GNOME Shell in storaged > anyway, because why reinvent this particular wheel in the DE? We have > degradedness notifications needed for mdadm, LVM, and Btrfs (and even > ZFS if we're asking for unicorns). Yeah, this needs some unified, generic solution. My suggestion was to use journal for this with some special key-value pair indicating that the message is actually a storage failure. That should be easy to do now that we have structured logging. And it could benefit from all the existing mechanisms developed for logging (outside of VM, log gathering,...). > > I guess I need to try this with Fedora 24 and see if it might be a > storaged regression. That's very unlikely. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Anaconda LVM RAID
On Tue, 2017-02-21 at 14:29 -0700, Chris Murphy wrote: > Tested Fedora 24 and Fedora 23, there's no notification with either > one of those. I have no idea if this is a VM thing. Or if it's a > regression. > > Maybe the notification was depending on smartd rather than mdadm. > Kinda need someone who knows more about how GNOME Shell handles faulty > devices - how it's intended to work at least. SMART-signaled failures are propagated/signaled by udisksd. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Anaconda LVM RAID
On Tue, 2017-02-21 at 07:52 -0600, Chris Adams wrote: > Once upon a time, Vratislav Podzimek <vpodz...@redhat.com> said: > > > > On Tue, 2017-02-07 at 14:50 -0700, Chris Murphy wrote: > > > > > > My opinion of the change is limited to whether gnome-shell will still > > > notify the user of device failures; if not, or if unknown then I think > > > the change should be rejected as lack of device failure notifications > > > in the DE is a regression that outweighs the benefit. It's > > Any idea how this is working right now? AFAICT, there's no mechanism for > > this other than > > a) running 'mdadm --monitor' or > > b) watching journal for log messages of particular format > > > > We could implement a similar thing for LVM RAID. > > Well, all the world is not GNOME or any DE for that matter; mdadm has > the mdmonitor service (enabled by default I believe) that will send > email about MD RAID failures. This is perfectly function for a server, > so should have some functionally equivalent replacement for LVM RAID. Sure thing, could you please file an RFE/bug report at https://bugzilla.redhat.com/enter_bug.cgi?product=LVM%20and%20device-mapper Thanks! -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Anaconda LVM RAID
On Tue, 2017-01-31 at 14:28 -0500, Matthew Miller wrote: > I would like the "User Experience" section to be fleshed-out a bit > more. Currently it says "There should be no visible change for > non-expert users. Expert users could make use of the new LVM RAID's > features." > > I think, though, there's plenty of middle ground here: users who are > not experts in LVM RAID yet would like to have data redundancy and need > to manage that. Sure, for them we need some nice overview of common 'mdadm' commands and their 'lvm' equivalents. CC'ing LVM guys here. > > The Documentation section mentions the installation guide, which is > great, but what about documentation for replacing disks or adding to > the set? ditto -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Anaconda LVM RAID
On Tue, 2017-01-31 at 15:52 -0400, Robert Marcano wrote: > On 01/31/2017 03:44 PM, Chris Adams wrote: > > > > > > Also: does this apply to /boot partition RAID 1? IIRC that didn't work > > with LVM RAID at one time. > > > > This is important, that mdraid is still available in anaconda and not > entirely replaced by LVM RAID. Not only /boot partition but UEFI boot > partition on mdraid 1 That's not going to happen. This change is only concerning the scenario when user chooses to have LVM on top of RAID (IOW, sets a RAID level for their VG). -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Anaconda LVM RAID
On Tue, 2017-01-31 at 13:44 -0600, Chris Adams wrote: > Once upon a time, Matthew Miller <mat...@fedoraproject.org> said: > > > > I would like the "User Experience" section to be fleshed-out a bit > > more. Currently it says "There should be no visible change for > > non-expert users. Expert users could make use of the new LVM RAID's > > features." > > At a minimum, it would be nice to have a list of common tasks, > especially in a comparison format (e.g. "Replace a failed drive" with > MD and LVM commands). Maybe this already exists somewhere and could > just be referenced. I'm not aware of any such document. CC'ing LVM guys to correct me if I'm wrong. > > I think one thing that's a bit of an annoyance is that LVM RAID is done > at the LV layer, so you have to remember to set it up for every LV you > create, vs. MD RAID where the whole VG will have RAID (this can be > useful in some situations, but probably not the common case). This > should be pointed out in the release notes IMHO. It's a good idea to mention this in the release notes, thanks! However, a linear LV can be simply converted to a RAID LV later so at least it's not that fatal. > > Also: does this apply to /boot partition RAID 1? IIRC that didn't work > with LVM RAID at one time. /boot on LVM is not supported right now so this is not concerning /boot at all. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Anaconda LVM RAID
On Tue, 2017-01-31 at 07:05 -0800, Andrew Lutomirski wrote: > > > On Jan 31, 2017 6:34 AM, "Chris Adams" <li...@cmadams.net> wrote: > Once upon a time, Jan Kurik <jku...@redhat.com> said: > > LVM RAID provides same functionality as MD > > RAID (it shares the same kernel code) with better flexibility and > > additional features expected in future. > > How do LVM RAID volumes get tested? There's a regular cron job for > testing MD RAID volumes, but I'm not aware of something like that for > LVM RAID. > > For that matter, how do you administer it? For MD RAID, there's mdadm. Does > LVM RAID have a fully-featured equivalent? Yes, it's administered with the LVM commands as described in 'man lvmraid'. I understand that some guide comparing the common 'mdadm' commands with 'lvm' commands could be useful though (CC'ing LVM guys). -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Anaconda LVM RAID
On Wed, 2017-02-01 at 12:25 -0700, Chris Murphy wrote: > Actually, I've got a concern about this feature. > > I'm not sure what gnome-shell depends on for monitoring mdadm arrays, > but I know it will put up a notification if an mdadm member becomes > faulty; because I've seen this notification. Maybe it's getting this > information from udisksd? In any case, I'm wondering whether the user > will still be notified of device failures in gnome-shell with this > change? I'm not seeing any code taking care of MD RAID device monitoring in udisks2. So it has to be somewhere else. Any ideas where to look? gvfs maybe? -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Anaconda LVM RAID
On Tue, 2017-01-31 at 08:33 -0600, Chris Adams wrote: > Once upon a time, Jan Kurik <jku...@redhat.com> said: > > > > LVM RAID provides same functionality as MD > > RAID (it shares the same kernel code) with better flexibility and > > additional features expected in future. > > How do LVM RAID volumes get tested? There's a regular cron job for > testing MD RAID volumes, but I'm not aware of something like that for > LVM RAID. Already answered by Chris Murphy I believe. There's no cron job for LVM RAID specifically right now, but it should be easy to add it. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F26 Self Contained Change: Anaconda LVM RAID
On Tue, 2017-02-07 at 14:50 -0700, Chris Murphy wrote: > My opinion of the change is limited to whether gnome-shell will still > notify the user of device failures; if not, or if unknown then I think > the change should be rejected as lack of device failure notifications > in the DE is a regression that outweighs the benefit. It's Any idea how this is working right now? AFAICT, there's no mechanism for this other than a) running 'mdadm --monitor' or b) watching journal for log messages of particular format We could implement a similar thing for LVM RAID. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora 24 Beta 1.2 compose check report
On Thu, 2016-04-28 at 12:27 -0700, Adam Williamson wrote: > > > > > ID: 14947 Test: x86_64 universal install_mirrorlist_graphical > > URL: https://openqa.fedoraproject.org/tests/14947 > This is a concerning one, somehow anaconda managed to crash? The logs > include an anaconda coredump. The same test passed for every other > recent image, so it's some kind of transient bug, but a crash is still > a crash. I tried to generate the backtrace from the coredump and here is its part (the coredump has >200 MiB): http://paste.fedoraproject.org/360944/14619164/ I cannot really tell what happened based on the bt, though. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
python-ntplib license change
With the new upstream release python-ntplib-0.3.3 the license was changed from LGPLv2+ to the MIT license. The only package that requires python-ntplib seems to be anaconda which is not affected by the change, but I'm rather letting you guys know. Thanks, -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: libblockdev reaches the 1.0 milestone!
On Tue, 2015-05-26 at 03:56 +0200, Dennis Jacobfeuerborn wrote: On 21.05.2015 20:08, Vratislav Podzimek wrote: A year ago, I started working on a new storage library for low-level operations with various types of block devices -- *libblockdev*. Today, I'm happy to announce that the library reached the **1.0** milestone which means that it covers all the functionality that has been stated in the initial goals and it's going to keep the API stable. Read the blog post I wrote for more information: http://blog-vpodzime.rhcloud.com/?p=61 This looks very interesting. I don't see any function to deal with plain old block devices though just LVM, MD Raid, etc. Is this correct or am I missing something? Do you mean disk partitions? Those are not covered yet in libblockdev (are part of the plan for version 2.0), but there's libparted providing such functionality. Sorry for such late reply, my filters put your email into a folder I check only once in a while. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
libblockdev reaches the 1.0 milestone!
A year ago, I started working on a new storage library for low-level operations with various types of block devices -- *libblockdev*. Today, I'm happy to announce that the library reached the **1.0** milestone which means that it covers all the functionality that has been stated in the initial goals and it's going to keep the API stable. Read the blog post I wrote for more information: http://blog-vpodzime.rhcloud.com/?p=61 -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Anaconda goes Python 3
Hello everybody, as many of you probably know, Anaconda has been slowly moving to Python 3 in recent months. Originally targeting Fedora 22 we postponed the switch to Fedora 23 [1], but we would like to start as soon as possible. Actually, even before Fedora 22 is released, because from our previous experience we know that it's never early enough to start with testing big changes. For these reasons, we are using a separate development branch [2] and a Copr repository [3] to create Rawhide and F22 composes that use Python 3 Anaconda and all its dependencies. Of course, the Rawhide composes suffer from the fact, that the majority of revealed issues are because of instability of Rawhide instead of Python 3 related issues so we use Fedora 22 images, to search for issues lurking somewhere in the dark waiting for Fedora 23 to be declared GO and then revealing themselves. To our surprise, we have troubles finding new issues in the Python 3 version of the Fedora 22 composes, so we would be really grateful if any of you guys could help us narrowing down the rest. The F22 composes are at https://m4rtink.fedorapeople.org/anaconda/images/python3/f22/ so feel free to download and test them. Please report the issues to our GH project pages [4] and if you have a patch, please submit a PR against our development branch [2]. If you want to read some more about the background and details of the Anaconda's switch to Python 3, read the blog post. [1] Thanks a lot in advance to all the early testers! We really appreciate your test early instead of complain later approach! [1] https://blog-vpodzime.rhcloud.com/?p=55 [2] https://github.com/M4rtinK/anaconda/tree/master-python3 [3] https://copr.fedoraproject.org/coprs/bkabrda/py3anaconda/ -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Blacklisting of Indian xkb layouts
On Wed, 2014-12-10 at 02:24 -0500, Anish Patil wrote: Hi, We have xkb layouts and m17n input methods to type Indian languages and both gets installed on GNOME by default. So it always creates confusion for uses that which are input methods and xkb layouts. However with xkb layouts one can't write conjuncts or complex characters. So it would be nice to have include m17n based input methods only, we discussed it over IRC and its log can be found on https://fedorahosted.org/i18n/ticket/36 Please let us know if anyone has better thoughts. I'd just like to mention that Anaconda doesn't use input methods so far so we would need to keep the xkb layouts available and installed to the installation images. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Best way to use zram in Fedora 21?
On Wed, 2014-11-26 at 16:27 -0500, Corey Sheldon wrote: Juan no needinst.zram=on on install on first boot modprobe zram ; systemctl start zramvoila I use the default one in f21b no issues For now. But the anaconda's zram.service is tailored to provide zram swap for the installation process. Future changes in it may make it unusable for general purpose usage on an installed system. So packaging something general-purpose it definitely the right way to go. Reindl's scripts look good to me, I'd just suggest adding a configuration option for setting the maximum RAM for the zram swap being created. It doesn't make much sense to use it on systems with e.g. 32 GiB of RAM. That's by the way one of the tweaks the anaconda's version of the scripts+service has (hardcoded, though). -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Best way to use zram in Fedora 21?
On Wed, 2014-11-26 at 23:46 +0100, Nicolas Chauvet wrote: 2014-11-26 22:27 GMT+01:00 Corey Sheldon sheldon.co...@gmail.com: Juan no needinst.zram=on on install on first boot modprobe zram ; systemctl start zramvoila I use the default one in f21b no issues Corey, Why this service is part of anaconda-core ? and not with the base systemd or else ? Because it is not a general-purpose service. It is a tailored version of service+scripts for use in the installation process. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: timedatex replacing systemd-timedated for NTP packages
On Tue, 2014-11-25 at 18:26 +0100, Lennart Poettering wrote: On Tue, 25.11.14 11:08, Michael Catanzaro (mcatanz...@gnome.org) wrote: On Tue, 2014-11-25 at 17:15 +0100, Lennart Poettering wrote: I am sorry, but timedated is really not the place to control NTP *server* software. It's simply, desktopy stuff, for controlling NTP clients. Of course, but the desktopy NTP client in Fedora Workstation is chrony, as you know full well. Unless that changes, we need timedatex. Even if we decide to drop chrony, we still need timedatex to ensure NTP is not broken for users who upgrade from F21 to F22. (Unless you have another plan for handling such an upgrade?) Drop the NTP checkbox. Enable chrony by default. Done. That would be quite a big security issue. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: blivet-gui announcement
On Sat, 2014-09-06 at 00:34 +1000, Ankur Sinha wrote: On Fri, 2014-09-05 at 11:05 +0200, Vratislav Podzimek wrote: P.S. Do you know about any other mailing lists or individuals that may be interested in this announcement? Feel free to forward the message and spread the word! Hi Vratislav! Could you perhaps write up a post for the fedoramagazine[1]? You can either post it yourself[2], or send it to the marketing ML[3], *or* send it me (or any other marketing team member) and I can post it on your behalf :) [1] http://fedoramagazine.org/ [2] http://fedoraproject.org/wiki/Magazine/Howtopost [3] https://admin.fedoraproject.org/mailman/listinfo/marketing Will do, tomorrow. Or is too late now? Thanks, -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
blivet-gui announcement
Good news, everyone! We (me and CC'd Vojtech Trefny) would like to introduce you the next generation tool for storage management -- the **blivet-gui** tool [1]_. It is a GUI tool based on the blivet python library (originally Anaconda's storage management and configuration tool) inspired by GParted and other storage management tools. Why not use GParted you ask? The reason we came up with blivet-gui is that none of the existing storage management tools supports all storage technologies supported in modern Linux distributions. Anaconda does support them all so it's only logical to take Anaconda's storage backend, combine it with a nice, intuitive and in general user-friendly frontend and build a standalone application for storage management. The GUI of blivet-gui is heavily based on GParted's UI to minimize the surprise which is very important in such a critical task as storage management is. If you know how to work with GParted, you'll almost instantly know how to work with blivet-gui. All requested changes are just enqueued first and then processed/committed to disk by the Apply button just like in GParted. However, with blivet-gui those actions may be something like the following sequence: create 10GB partition sda1, create a LUKS device on top of it and use the LUKS device as a PV for a VG called ``dataVG`` with a single LV ``data`` occupying half of the VG space and with XFS on top of the LV, not only partitioning and file system operations like GParted does. Having troubles writing partitioning part of a kickstart file for automated installation? Run blivet-gui with the ``--kickstart`` option and export the partitioning portion of a kickstart file instead of committing changes to disk. On top of the features described above, the blivet-gui is embedable so any application using any toolkit with the XEmbed protocol support (Gtk, Qt,...) may use blivet-gui as a part of its GUI. The application only started its history few months ago, is under heavy development now and will get new features in the next months (RAID, BTRFS), but even now it is a very nice and useful tool. Suggestions, feature requests, bug reports and of course PATCHES ARE WELCOME! It is quite a simple Gtk application written in Python which makes it an easy target for everybody who misses something in the other storage management tools. Don't like Gtk? Text mode would be really, really useful too! Don't feel like adding new features and diving deep in blivet to implement them? The code always needs refactorization and cleanup! I think everybody can submit patches for blivet-gui and I'm really looking forward to see the hundreds of patches from all those people that hate every storage management GUIs and tools that have every existed. Let's spend some time on pushing the Linux storage management further instead of just complaining! .. [1] http://blog.vojtechtrefny.cz/blivet-gui P.S. Do you know about any other mailing lists or individuals that may be interested in this announcement? Feel free to forward the message and spread the word! -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: blivet-gui announcement
On Fri, 2014-09-05 at 09:04 -0400, Bastien Nocera wrote: - Original Message - Good news, everyone! We (me and CC'd Vojtech Trefny) would like to introduce you the next generation tool for storage management -- the **blivet-gui** tool [1]_. It is a GUI tool based on the blivet python library (originally Anaconda's storage management and configuration tool) inspired by GParted and other storage management tools. Why not use GParted you ask? Actually my question is why not gnome-disk-utility? :) Because it doesn't work well with LVM, RAID, BTRFS and a combination of them. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Mon, 2014-03-17 at 14:52 -0700, Adam Williamson wrote: On Mon, 2014-03-17 at 13:10 +0100, Vratislav Podzimek wrote: And to sum it up a bit -- I think this feature doesn't complicate things for users who want to ignore it or who don't understand it. If you think it does, please tell me about it and I'll do my best to fix it. On the other hand, if somebody wants to care about security policies, they have an easy and comfortable choice. Unfortunately, I don't think this is quite right. As I understand it, it's fairly well established that if people see a UI element, they - or, at least, an appreciable amount of them - will want to interact with it, or at least understand it. *Some* people may follow this thought process: Path 1 -- Oh, hey, there's this thing here. Hum. I don't understand it at all. Well, I guess I'll just ignore it and carry on. which is what you're assuming, and would give an okay outcome. However, I think it's fairly well known that quite a lot of people will follow this one: Path 2 -- Oh, hey, there's this thing here. Hum. I don't understand it at all. Well, crap. I'm installing an OS. That's a pretty major operation. I think I'd better understand everything that's going on before I carry on. clickety Huh. content...policy...profile? What is all this stuff about? What does it mean? What should I do? This one goes one of about three ways. If we're really lucky: Well, I guess I'd better go read the docs. reads docs That was a clear, short and cogent explanation! I learned something, an now I can continue! If we're less lucky: I guess I'll go Google around and see if I find something useful. Jeez, why does this have to be so complicated? If we're less lucky: Man, screw this crap, if I have to go read an encyclopaedia just to get it installed, I'll go do something else. And finally, some people will probably follow this one: Path 3 -- Oh, hey, there's this thing here. Hum. I don't understand it at all. Well, what the hell, I'm a smart cookie, I'll just power through. clickety Hum. Content...policy...profile? I don't really know what any of those things are. But reading is hard. I'll just make some sensible-looking guesses! clickety I suspect you can figure out the possible outcomes of path 3. ;) Well, I still believe that if we had good content in the SSG, sensible-looking guesses and the addon was able to show rules defined by profiles (which is a planned feature for the next release), it would be quite an easy choice for the user. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Sun, 2014-03-16 at 22:05 -0400, Bill Nottingham wrote: Vratislav Podzimek (vpodz...@redhat.com) said: Thanks for your feedback, it definitely is constructive! I've recorded a video preview demostrating the feature's functionality. Hope that answers at least some of your and others' questions. https://vimeo.com/89243587 So, having watched the video, I think I'm pretty clearly against this from a interactive install standpoint, given what is presented. Here's what I see in that video. I'm not a UI/UX professional, so additional review from someone more along those lines would be great (and info on where I'm barking up the wrong tree - can always learn more.) INTEGRATION === Current toplevel is localization, software, and system. 'Security policy' doesn't fit as a toplevel along with that. If we wanted it as an additional item under 'System', des that mean it can't be done as an addon? I can be part of the System category. It hasn't been from the beginning because there was no System category when this project was started. INITIAL SCREEN == - You've got three active items: 1 - 'Change content' (button) 2 - 'Apply security policy' (toggle) 3 - 'Select profile' (button) If someone isn't familar with the specific terminology in use here, you're using three separate nouns here which all can be similar in meaning (policy, profile, content). If the user isn't familiar with all three terms, all three of these items could be seen as doing the same thing! That's not good. If I were to whiteboard some proposed improvements of the screen you have (note: not saying this is the way to go vs. a full rework), it would be something like: Apply a security policy [ YES | NO ] (1) Policy 1 | (if we want details on the selected description 1 | policy, they go here on selection) | Policy 2 | description 2 | ... | - [ Choose another policy source ... ] (2) (1) If 'no' is selected, rest of screen is inactive (2) If this is still desired There would be no 'select profile' button - it would be selected by just selecting the profile, similar to other anaconda actions. URL SCREEN == - Why is 'Use SCAP Security Guide' (presumably a predefined URL) a selection, if it is not the normal source of the choices in the initial screen? If we're shipping with predefined content sources, it should be reflected on the initial screen; if we're not using that predefined data, I'm not sure why it's an option here. Choosing SSG doesn't result in using a predefined URL, it results in using content that is a part of the compose, setting various parameters. - 'Enter data stream content or archive URL here'. Again, too jargon-y. Is there a reason 'Enter URL to security policy' isn't good enough? (Or whatever terminology is used in the software spoke.) Good point. However, we would need at least a tooltip on which security policy formats are supported. PROFILE DETAILS === It's best when describing details (if we want to do so) that we don't use different terminology or concepts than what is used in the rest of the installer, if at all possible. In your example, we have: - 'logical volume' This only shows up in custom partitioning, and even then not very foregrounded (unless I'm missing something). - 'mount options' Not used anywhere. - 'package', 'list of installed packages', 'list of excluded packages' Packages are not exposed in the installer UI as user-interactable objects - the only place they show up (outside of error messages) is as part of the installation progress bar. I take all those terms as commonly known or, in case of logical volume, something that can be simply ignored if not understood. Above and beyond that: - We should not be showing things as warnings. If the policy says a password must meet certain parameters, and we let the user later set it up in a way that violates that without additional warnings or automatic remediation, that's a bug. I agree, but before this is fixed (a change in the anaconda installer needed), displaying a warning is better than nothing to me. - The error situation is even worse. It's really bad form to show them an error in spoke A *that they inherently have to know how to fix in spoke B*. Otherwise, you're giving them an easy way to break their system that they won't know how to get out
Re: F21 Self Contained Change: Security Policy In The Installer
On Thu, 2014-03-13 at 13:38 -0400, David Malcolm wrote: On Thu, 2014-03-13 at 15:27 +0100, Vratislav Podzimek wrote: On Thu, 2014-03-13 at 09:00 -0400, Jan Lieskovsky wrote: There are many known tips and tricks how to make a system more secure, often depending on the use case for the system. With the OSCAP Anaconda Addon [1] and the SCAP Security Guide [2] projects, we may allow users choosing a security policy for their newly installed system. What is the proposed default configuration/policy? FWIW WRT to scap-security-guide content there's only one (common) profile at the moment. But it depends on the target group / volume / spin we would like this to be by default part of -- once this is clear in that case the profile can be adjusted / modified to prefer / select by default just rules intended for the target group of that system So, let me be more specific: If I install using the most default setup possible (not touching the policy spoke), will the installed system be affected by the policy / different from what is packaged in the RPMs? No (by default AFAICT). But since there will be oscap-anaconda-addon present in the compose / distro (if this proposal got approved), the user *before* / *in the moment* of the install will have chance to select which profile the installed system should be compliant to / in conformance with once installed. But should their preference be not to change / configure anything, they will still have chance to ignore the proposed Security Profile anaconda field, and use vanilla Fedora installation (as there wouldn't be the proposed enhancement present at all). Vrata, pls correct me if / where appropriate. The current behaviour of the addon is to *not* select any profile by default. So unless the user visits the spoke and chooses some profile (and doesn't toggle the Apply security policy switch), no changes will be done to the installed system. So it's opt in solution, not an opt out one. Will the spoke's label have some text like No security profile selected or somesuch when that's the case? Presumably the Begin Installation is insensitive until the Security Profile spoke is happy, like how other spokes work? I like the overall idea, but I'm slightly nervous about the UI. How, if at all, do security policies affect the UI in the *other* spokes? (sorry, I wasn't able to view your videos on this box, just the screenshots). For example, if you have a security profile which mandates that /tmp be on a separate partition or logical volume, does this affect the UI in the partitioning spoke? Similarly, if the profile forbids package telnet from being installed, does this show up somehow in the Software Selection spoke? (e.g. what if the user tries to manually select telnet within that spoke?). Likewise, does the Profile's password complexity requirements affect the password UI? Or is it a case of: review the issues listed in the Security Profile spoke, and figure out how do I fix this?, switch to the appropriate spoke, try to fix it, see if the Security Profile spoke is now happy, else repeat. That seems suboptimal, though what you've got may well be good enough for a first iteration (and I'm not volunteering to hack on it, so feel free to ignore me ;) ). Hope this is constructive; as I said, I like the proposal. Thanks for your feedback, it definitely is constructive! I've recorded a video preview demostrating the feature's functionality. Hope that answers at least some of your and others' questions. https://vimeo.com/89243587 -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Thu, 2014-03-13 at 09:00 -0400, Jan Lieskovsky wrote: There are many known tips and tricks how to make a system more secure, often depending on the use case for the system. With the OSCAP Anaconda Addon [1] and the SCAP Security Guide [2] projects, we may allow users choosing a security policy for their newly installed system. What is the proposed default configuration/policy? FWIW WRT to scap-security-guide content there's only one (common) profile at the moment. But it depends on the target group / volume / spin we would like this to be by default part of -- once this is clear in that case the profile can be adjusted / modified to prefer / select by default just rules intended for the target group of that system So, let me be more specific: If I install using the most default setup possible (not touching the policy spoke), will the installed system be affected by the policy / different from what is packaged in the RPMs? No (by default AFAICT). But since there will be oscap-anaconda-addon present in the compose / distro (if this proposal got approved), the user *before* / *in the moment* of the install will have chance to select which profile the installed system should be compliant to / in conformance with once installed. But should their preference be not to change / configure anything, they will still have chance to ignore the proposed Security Profile anaconda field, and use vanilla Fedora installation (as there wouldn't be the proposed enhancement present at all). Vrata, pls correct me if / where appropriate. The current behaviour of the addon is to *not* select any profile by default. So unless the user visits the spoke and chooses some profile (and doesn't toggle the Apply security policy switch), no changes will be done to the installed system. So it's opt in solution, not an opt out one. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Security Policy In The Installer
On Thu, 2014-03-13 at 14:45 -0400, Jan Lieskovsky wrote: On Thu, Mar 13, 2014 at 01:40:53PM -0400, Jan Lieskovsky wrote: Of course, in the case they wouldn't like to configure any security policy and use just vanilla Fedora installation, the can ignore the security section, configure just those sections as configured (required to be configured) now (e.g. INSTALLATION SOURCE, SOFTWARE SELECTION etc.), and click the Begin Installation button. In that case no security profile would be applied. The demos seem to cover the case where there's already data provided from the Kickstart file. What options are presented to the user if there's no oscap entry in Kickstart? Is the user expected to provide a path to download a policy? Yes, there are two ways how to provide the policy - either via kickstart or via GUI by entering the HTTP / FTP URI [*] of the policy (in RPM package format) and clicking the Fetch data button. The SCAP Security Guide content is loaded automatically (if available) and even when user clicks the Change content button, there is again the Use SCAP Security Guide button that gives them SSG back. Otherwise fetching data stream collection (XML), archive (zip or tarball) or RPM is supported so far. Other protocols and format types may be added in the future based on user feedback and requests. I can remember seeing some video from Vratislav demonstrating the 'fetch security policy in RPM format remotely' scenario too, but you are right it's not illustrated in those demos (yet). Vratislav, can you add demo video of this use case too? The RPM support is demonstrated in the following video preview: http://vpodzime.fedorapeople.org/oaa-0.4-changes.webm However, I see that a new commented video preview would explain a lot of common questions appearing in this discussion, so I'll record one tomorrow and post it here and on the feature page. Thanks for the useful and constructive feedback, guys! -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
On Wed, 2014-02-26 at 11:46 -0800, Adam Williamson wrote: On Wed, 2014-02-26 at 11:17 +0100, Karel Zak wrote: Don't try to be smart to everyone, it does not work. IMHO all you need is to support one or a very few scenarios (complete scenarios without customization) and a way how to switch from installer to manual partitioning by parted/fdisk/mdadm/mkfs/etc. The anaconda partitioning UI will never be smart enough for advanced users and it also does not make sense to duplicate effort, we *already have* tools to create all the unusual crazy disk layouts. We don't, really. Well, we do, but it really is tools plural, and some of them don't have GUIs at all. blivet and its anaconda GUI really is one of the most advanced partitioning tools in existence. There's no one-stop graphical tool that does everything blivet/anaconda does, AFAIK. gparted can't do anywhere near the LVM, RAID and btrfs stuff that blivet does: it really only does *partitions*. Just to let you know -- a guy from Prague Technical University is working on a bachelor thesis [1] focused on starting the development of a GUI partitioning/LVM/RAID/BTRFS tool based on blivet that should be embedable into other applications, Anaconda included. We've kind of boxed ourselves into a corner of unreasonably high expectations here now, though - we either commit to continuing to support all the functionality custom part currently supports, or we say reduce it and screw the complainers, but there *will* be complainers. There already are quite vociferous complainers for the very small amount of simplification that was done between oldUI custom part and newUI custom part. Possibly the most viable long-term option, and I think one the devs are gradually working towards, is to make the blivet GUI an independent component. That would mean it wouldn't kill your whole anaconda run if it crashed (you could just start over and try again), and you could use it from outside of anaconda (say, to pre-partition). And it'd maybe encourage other projects to adopt and contribute to it, which would definitely help take the load off - I've said it before but I'll say it again, it is kinda absurd that we have, what, about the equivalent of 1.5 full-time developers trying to maintain this extremely capable and complex partitioning backend *and* frontend. Another let you know -- I'm now starting to work on blivet for most of my work hours, so it will hopefully soon be equivalent of 2.5 full-time developers. Also, we have already discussed splitting out the Custom partitioning GUI into a separate tool with dlehman. I can soon (in March) jump on it and I believe it should be feasible. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
On Thu, 2014-02-27 at 09:17 +0100, Vratislav Podzimek wrote: On Wed, 2014-02-26 at 11:46 -0800, Adam Williamson wrote: On Wed, 2014-02-26 at 11:17 +0100, Karel Zak wrote: Don't try to be smart to everyone, it does not work. IMHO all you need is to support one or a very few scenarios (complete scenarios without customization) and a way how to switch from installer to manual partitioning by parted/fdisk/mdadm/mkfs/etc. The anaconda partitioning UI will never be smart enough for advanced users and it also does not make sense to duplicate effort, we *already have* tools to create all the unusual crazy disk layouts. We don't, really. Well, we do, but it really is tools plural, and some of them don't have GUIs at all. blivet and its anaconda GUI really is one of the most advanced partitioning tools in existence. There's no one-stop graphical tool that does everything blivet/anaconda does, AFAIK. gparted can't do anywhere near the LVM, RAID and btrfs stuff that blivet does: it really only does *partitions*. Just to let you know -- a guy from Prague Technical University is working on a bachelor thesis [1] focused on starting the development of a GUI partitioning/LVM/RAID/BTRFS tool based on blivet that should be embedable into other applications, Anaconda included. The omitted link: [1] https://thesis-managementsystem.rhcloud.com/topic/show/180/a-tool-for-storage-configuration-on-gnulinux-os -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 20 release day FedUp bug: post-mortem
On Sun, 2014-01-05 at 01:15 +0100, Kevin Kofler wrote: Adam Williamson wrote: So, um, you think that because we've done three big changes in the past that means we won't ever do another again? I'm not quite sure how that logic works. We've already broken the distro 3 times, that's 3 times too many! I surely hope we will never do such a broken improvement again! I really hope we will, that's how big steps in innovation happen in this fast-moving world. And we don't want to be limping behind, do we? -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Anaconda Addon Development Guide almost finished, needs review
For a few last months I've been line after line putting together the Anaconda Addon Development Guide [1] -- a short and straightforward guide describing how an addon for the Anaconda installer can be implemented, tested, deployed and packaged. I believe it is now almost finished, but it needs review and probably a lot of tweaks based on the feedback, I'll hopefully get, before I'll propose it as a part of the official Fedora project documentation. So comments, suggestions, issue reports or patches [2] are more than welcomed! [1] http://vpodzime.fedorapeople.org/anaconda-addon-development-guide/ [2] https://github.com/vpodzime/anaconda-addon-development-guide -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: anaconda / initial-setup / gnome-initial-setup: can we do this better?
On Mon, 2013-10-14 at 13:51 +0100, David Woodhouse wrote: On Mon, 2013-07-15 at 22:26 +0100, David Woodhouse wrote: On Wed, 2013-05-22 at 05:18 -0400, Martin Sivak wrote: One thing that doesn't seem to have been covered in the discussion — what about third-party firstboot modules? For an install on a corporate machine we have a firstboot module which asks for the Active Directory credentials, joins the Samba domain, obtains SSL certificates for VPN and WPA2-enterprise wifi and provisions those in NetworkManager, adds a local user with the appropriate username, provisions accounts in Evolution-EWS and pidgin-sipe, etc. With firstboot gone, what form should our plugin take? Firstboot stays available in RHEL for this reason (legacy plugins). Fedora modules will probably have to be updated. At least that was the plan. It is very easy to write a new module with the new API. Ping vpodzime, he has a development guide. Thanks. Delayed response... I've finally got everything else working nicely on Fedora 19 and I'm looking at this. I see firstboot is still available, but it doesn't seem to *work*. First it wants python-ethtool to be installed but didn't have the appropriate dependency, and then it's still using pygtk while my own code has been updated to pygobject and gtk3. (Which was done because some other code I was *importing* had been upgraded, so I couldn't mix the two. I don't think you get far with pygtk these days, do you?) So I'm guessing that it's probably not worth looking at firstboot any harder, and I should proceed straight to using initial-setup. In the absence of the promised documentation for initial-setup, I ended up using firstboot anyway. I backported my code to pygtk2 again, and filed a bug for the missing dependencies in the packaging. The bug has now been closed on the basis that firstboot is deprecated and replaced by initial-setup, but I *still* don't see any sign of the long-promised documentation. Or even any example 'skeleton' of a standalone module to start from. Is there any prospect of that happening any time soon, please? Sorry, I'd replied in the bugreport [1] before I saw this thread going on. [1] https://bugzilla.redhat.com/show_bug.cgi?id=984932 -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dracut HostOnly or ConfigurationOnly?
On Thu, 2013-09-05 at 10:17 -0500, Michael Catanzaro wrote: On Thu, 2013-09-05 at 14:25 +, Jóhann B. Guðmundsson wrote: On 09/05/2013 02:10 PM, Vratislav Podzimek wrote: 2) regenerate the initrd at the end of the installation This is what should be done both for live and regular installs. JBG The LUKS password issue is pretty serious. Anyone know if there is a bug report for this? https://bugzilla.redhat.com/show_bug.cgi?id=994180 -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dracut HostOnly or ConfigurationOnly?
On Thu, 2013-09-05 at 15:52 +, Jóhann B. Guðmundsson wrote: On 09/05/2013 02:44 PM, Harald Hoyer wrote: I concur and say: 1) write out keyboard configuration before packages are installed 1b) write out language configuration before packages are installed Had we narrowed it down to only keyboard/language configuration since I vaguely recall coming across other type of bugs that required initramfs re-genartion straight after install to fix. That's why I think re-generating initrd would be a better and more solid solution, hopefully effective for a long time. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Dracut HostOnly or ConfigurationOnly?
Hello, everybody, I'd like to know your opinion on one issue we have hit on live installations due to the DracutHostOnly feature [1]. Long story short: 1) Anaconda installs the kernel package 2) installation of the kernel package triggers dracut to generate initrd 3) dracut now generates so called host-only initrd, which, among the other things, means, that it contains only one keymap -- the one that was set in /etc/vconsole.conf at the time dracut was triggered to run 4) Anaconda configures the installed system based on the values set during the installation. The actual result is that if users type in their LUKS password with a keyboard layout different from 'us', let's say 'gb' they cannot type the password again on boot, because the initrd has only the 'us' keymap (set by default in the configuration file), even if there is 'vconsole.keymap=gb' as a boot option. There are two basic approaches how to fix this on the installer side: 1) write out keyboard configuration before packages are installed 2) regenerate the initrd at the end of the installation Both these solutions are not ideal from my point of view. And even if one of them is accepted and applied, there would still be the problem with systems, that have an initrd that blocks functionality of boot options (maybe there are more than vconsole.keymap, I don't know). So, is it a right thing to do to generate 3 MB smaller initrd's (the summed up size of all keymaps) not supporting some boot options? Does HostOnly mean the initrd works only with a specific host or that it works only with a specific configuration of a specific host? I understand having firmware for hardware that does not exist in the system might be useless, but not supporting boot with a different configuration options seems to me as a different thing. [1] https://bugzilla.redhat.com/show_bug.cgi?id=994180 -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: installer final touches matters
On Sun, 2013-01-20 at 13:15 +0300, Muayyad AlSadi wrote: hi, the fedora's new installer got many innovative features but it's missing many critical easy to fix final touches from user experiance point of view let me mention some I've tried fedora 18 live cd, I was offered to choose LVM, standard or BTRFS and later went through partitioning process and when I'm done the begin installation button was disabled leaving the user without any clue or error message I've done all steps in a proper way (I've prepared a partition for / and swap ..etc.) I know what was the problem (as a fedora developer, I know that live installation is just blind copying of an already made filesystem which you can't change its type from ext4 to BTRFS) This is no longer the way live installation works. We now use rsync to place all files to the hard drive so the problem lies somewhere else. Could you please search bugzilla for a similar bugreport and if there is none such, file a new bug? Also any additional info (steps to reproduce, logs from /tmp and e.g. the output of the lsblk command) would be appreciated. Thanks, -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: prefered way of configuring X11 keyboard layouts in F18
On Mon, 2012-12-03 at 09:20 +0200, Panu Matilainen wrote: On 12/02/2012 10:57 PM, Miloslav Trmač wrote: On Sun, Dec 2, 2012 at 12:38 AM, Sérgio Basto ser...@serjux.com wrote: system-config-keyboard should do this: 1. Get the old settings: cat /etc/sysconfig/keyboard 2. Set the new settings: su -c 'localectl set-x11-keymap layout [model] [variant] [options]' 3. Remove the old configuration file: su -c 'rm /etc/sysconfig/keyboard' or at least warning that we should do something new like this . http://pkgs.fedoraproject.org/cgit/systemd.git/commit/?h=f18id=0969ad24898347919865e9298fa01e19cec98649 already attempts to do some kind of automatic conversion. If that is insufficient, please file bugs against systemd. It seems that the virtual console layout is migrated ok, but the x11 part is not. This is what I get on my two upgraded F18 boxes: [root@turre ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: fi X11 Layout: n/a [root@turre ~]# The n/a part is the problem as it falls back to US keyboard. localectl manual says both set-keymap and set-x11-keymap apply to both the keymaps unless --no-convert is specified, but that doesn't seem to happen in practise: [root@turre ~]# localectl set-keymap fi [root@turre ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: fi X11 Layout: n/a [root@turre ~]# localectl set-x11-keymap fi [root@turre ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: fi-latin1 X11 Layout: fi [root@turre ~]# localectl set-keymap fi [root@turre ~]# localectl System Locale: LANG=en_US.UTF-8 VC Keymap: fi X11 Layout: fi X11 Model: pc105 X11 Options: terminate:ctrl_alt_bksp It's a bit bizarre: set-keymap doesn't seem to find fi as the closest matching keyboard for x11 (it probably should), set-x11-keymap considers fi-latin1 to be the closest matching keymap for fi, but in this specific order its possible to get both set to fi. Only it now adds additional model + options there, whatever the reason. - Panu - The conversion (as systemd-localed calls it) works really poorly also for the Czech keymaps/layouts. 'cz' X11 layout is converted to 'cz-lat2' which works like 'us' until you hit the Pause Break key. This is really unfortunate especially when people set their LUKS password in Anaconda with the 'cz' X11 layout activated and then they are supposed to enter it again with the 'cz-lat2' keymap during boot. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Fri, 2012-11-09 at 12:27 +0100, Miloslav Trmač wrote: On Thu, Nov 8, 2012 at 9:40 PM, David Lehman dleh...@redhat.com wrote: On Thu, 2012-11-08 at 17:20 +, Jóhann B. Guðmundsson wrote: On 11/08/2012 05:14 PM, Stephen John Smoogen wrote: On 8 November 2012 10:06, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 11/08/2012 04:37 PM, Matthew Garrett wrote: On Thu, Nov 08, 2012 at 04:32:29PM +, Jóhann B. Guðmundsson wrote: Or if I rephrase why could not the community continue to use Anaconda in it's form that it existed in F17 until the new installer was *completly* done? Because nobody in the community did the work to make the F17 Anaconda work in F18? This also touches on Who's responsible for an feature Just recently FESCO decided *for* Kay that he was responsible to ensure the migration related docs and what not kept working for the name change of configuration files that takes place in systemd ( which was not even a feature ) Applying the same logic here the Anaconda developers themselves would have been responsible keeping the old code working until the new one was ready to completely replace it. Your problem is that you are assuming a lot of things without actually doing any legwork to find out what anaconda does. Anaconda does a lot of probing of hardware which changes when kernels change. Anaconda requires changes when dracut changes APIs. Every release requires changes in what is blacklisted and what is not blacklisted. It requires dealing with the usual multiple changes in python apis and such. It has other changes due to EFI or secure boot or other features. None of them are trivial and doing them in parallel is usually not possible. Not that your response is relate to who's responsible for making those changes, but is that not a fundamental flaw in the installer and it's design? No. It is an inevitable consequence of the feature set demanded of the Fedora OS installer. If thing A must be able to set up and configure thing B and thing B changes in ways directly related to said configuration, how can you reasonably expect thing A to continue to be able to configure thing B without corresponding changes? Magic? Well, perhaps thing B shouldn't have been changed incompatibly in the first place. I realize that's an ideal that is impossible to achieve, but we are rather cavalier about changing interfaces without adequate notification. I've been told that the F18 Anaconda work was for some time done on a single rawhide snapshot; after ~2 months the snapshot was updated - and it took weeks to get Anaconda working again against the new one. That sounds rather bad. Yes, anaconda is special, but it is not _that_ special; if updating for core platform changes (without any major known change happening in the mean time) requires weeks of work on anaconda, there will be other software that will require weeks of work to update. I'm afraid anaconda _is that_ special. AFAICT there is no other piece of code that directly interacts with dracut, systemd, Network Manager, gtk3 (and GObject introspection) and many other components that change quite often. If there is such code, I'd be happy to look at how its developers handle such changes and take a lecture from them. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On Tue, 2012-10-30 at 19:32 +0100, Gianluca Sforna wrote: On Tue, Oct 30, 2012 at 7:12 PM, Adam Williamson awill...@redhat.com wrote: I'd recommend asking dcantrell, as he has some good points on this topic. I broadly agree with him that it might well be more or less impossible to smoothly handle a major rewrite of anaconda in our current development process. CCing to make sure he sees this. If you are saying that 6 months are a too short time for something like this I think I can understand it. 6 months are a too short time. And it was less than 6 months. As can be seen from the F18 release schedule [1], originally it was about 3 months between the day F17 was released and the day new Anaconda was expected to work (F18 Alpha release). We of course didn't start the work on May 29, but since there were significant changes in F17 too at least part of the team had to fix bugs and make F17 releasable. Also Alpha is not supposed to be 100% feature complete, but it seemed to me that not everybody was taking this into account. [1] http://fedoraproject.org/wiki/Releases/18/Schedule -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On Wed, 2012-10-31 at 10:33 +0100, drago01 wrote: On Wed, Oct 31, 2012 at 10:27 AM, Vratislav Podzimek vpodz...@redhat.com wrote: On Tue, 2012-10-30 at 19:32 +0100, Gianluca Sforna wrote: On Tue, Oct 30, 2012 at 7:12 PM, Adam Williamson awill...@redhat.com wrote: I'd recommend asking dcantrell, as he has some good points on this topic. I broadly agree with him that it might well be more or less impossible to smoothly handle a major rewrite of anaconda in our current development process. CCing to make sure he sees this. If you are saying that 6 months are a too short time for something like this I think I can understand it. 6 months are a too short time. And it was less than 6 months. As can be seen from the F18 release schedule [1], originally it was about 3 months between the day F17 was released and the day new Anaconda was expected to work (F18 Alpha release). Sure in that case you shouldn't have propose it for F18 to begin with but take your time and introduce it in F19. There is no need for this rush. I don't see any advantage in that, because it would end up the same as with F17 and F18. We don't do only changes we want to do and we come up with. As many other packages change these changes have to be reflected in Anaconda [1]. And that's the work that has to be done no matter we want/need to focus on the redesign/rewrite or not. [1] just to see what I'm talking about -- http://msivak.fedorapeople.org/anaconda-openhouse/#%285%29 -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On Wed, 2012-10-31 at 10:05 +, Jóhann B. Guðmundsson wrote: On 10/31/2012 09:50 AM, Gianluca Sforna wrote: However, I think anaconda developers knew that 6 months were too short since the beginning. If this was abundantly clear to FESCo and other interested parties, I think we could even accept a one time 9/12 months release cycle instead, without raising all this fuss for each week of delay. Oh they knew all right [1]... There is no such thing as new anaconda. It supports so many features, that we are able to rewrite only parts at a time. And even at this pace it usually takes one or two Fedora releases to stabilize the rewritten part. Pay very much attention to this... we are able to rewrite only parts at a time. That's true and believe me that UI *is only a part* of the Anaconda installer. and two Fedora releases to stabilize the rewritten part. And that's something that happens to many more packages/features in Fedora. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: highly anecdotal comments on LVM in Fedora
On Thu, 2012-10-25 at 21:04 -0400, Matthew Miller wrote: I used to be annoyed by the long device names generated by LVM and didn't see myself as needing the complexity on a desktop. Over the years, I've found it to be more and more useful to be able to revisit partitioning choices without a whole song-and-dance. So, when I was installing F18 TC3 on my new laptop, I thought I'd try setting up a custom partitioning scheme with LVM. It took me a bit to find where I could do that (I needed to check I don't need help, I think), but then when I tried anaconda crashed, and then the thing to autofile a bug crashed. S, I rebooted and did it again without LVM and it didn't crash. Have you filed a bug that bug reporting in anaconda failed? I'm not aware of any such (unresolved) bug. Thanks, -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: change of names of configuration files
On Thu, 2012-10-25 at 23:50 -0400, Bill Nottingham wrote: Of course, in checking the code, anaconda for the moment is writing *both* files with identical data. Exactly. And the reason is that there are still tools working with the /etc/sysconfig/* files. Or aren't there? Believe me I'd be more than happy to remove the lines of code writing the old configuration files once they are really deprecated and not used by any tool. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: change of names of configuration files
On Thu, 2012-10-25 at 15:39 +0200, Marcela Mašláňová wrote: Hi devels, I'd like to ask for your opinion, especially those from anaconda, system-config-* and localization. The last commit in systemd [1] changed names of configuration files. Does someone else than systemd tools using them? Fedora 18 is (or will be soon) in freeze, so it would be better solve it now. Situation with anaconda is simple here -- we just need to *be told* what files we should write the configuration to. I'm sorry, but I cannot (and won't) follow all systemd changes. The similar case is that systemd now don't default VConsole font to latarcyrheb-sun16 (see rhbz#869233). -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plans for anaconda LVM/RAID support
On Thu, 2012-10-25 at 12:04 -0700, John Reiser wrote: On 10/25/2012 09:55 AM, Ken Dreyer wrote: On Thu, Oct 25, 2012 at 10:53 AM, Matthew Miller [snip] It is often useful in enterprise settings to do non-kickstart installs while prototyping. *And*, people running Fedora in those settings probably *are* prototyping. So, this seems like an important use case to me. I agree with this. It's also quite a simplification to say that kickstart only involves writing a single text file :) I see a couple other things here. Anaconda doesn't inter-operate well. The interactive graphical part has no provision for writing the kickstart file so far, so that is cumbersome to adapt: I need multiple passes. (How do I invoke anaconda with a partial kickstart file, use interactive features, then write the revised kickstart state, and stop? There should be a syntax-and-semantics-aware kickstart editor.) And, if what I want is guided generation of a kickstart file, then that should be an ordinary app (with root privileges to discover any existing configuration, but inhibiting all partition creating and formatting), not a stand-alone installer. The best thing (from my point of view) of the Anaconda rewrite is that this is finally possible and will be available. Anaconda itself now stores almost nothing in non-kickstart structures and from the configuration screens to the progress one basically kickstart is passed (as an in-memory structure, not in textual form). Checking if argv[0] is system-config-kickstart (or whichever name) and exporting kickstart instead of actual installation is an easy step. So you will be able to pass Anaconda a partial kickstart add some stuff interactively in the GUI (and in a bit farer future also in the TUI) and quit it generating new, partial or complete, kickstart. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: Illuminated keyboard turns off with kernel 3.6.1 upgrade
On Mon, 2012-10-15 at 19:48 -0400, Gerry Reno wrote: I just upgraded my F17 kernel to 3.6.1 and when I reboot then my Logitech illuminated keyboard is not lit until I touch a key and then it goes right back off. Kind of defeats the purpose of having an illuminated keyboard. Anyone know why this might happen after this particular kernel upgrade? I have no idea, but probably the best thing to do is file a bug and provide as much related information as you can. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installer unable to detect Geforce GTX 460 v2
On Mon, 2012-05-14 at 18:01 -0700, Luya Tshimbalanga wrote: I added sshd as a boot parameter after highlighting Install/Upgrade Fedora from F17 DVD. There are still a black screen after initialization. I attempt to get ssh information using my laptop and received a denied connection. Did I miss something? 'sshd' boot parameter should be working. Please try 'sshd=1' and if that works or if none of them works, please file a bug that both should be working. Of course you have to know the IP address of the machine, that could be a tricky part when using DHCP. If you can use a static IP address, add 'ip=IP_ADDRESS' to the command line options. And also don't forget to add 'root@' to your ssh command, if you are connecting as the non-root user. So something like: $ ssh root@IP_ADDRESS This way it works for me with Fedora 17 Beta DVD. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installer unable to detect Geforce GTX 460 v2
On Sat, 2012-05-12 at 13:38 -0700, Luya Tshimbalanga wrote: I have submitted a bug report[1] related to nouveau driver. The installer is unable to detect Nvidia Geforce GTX 460 v2 [2] which is different from the original Nvidia Geforce GTX 460, forcing the use of vesa driver. As a result, the screen is black so I cannot provide a xorg.log report let alone smolt hardware profile. I believe it should be possible to swith to tty2 (with Ctrl+Alt+F2) and use scp or some other tool to retrieve logs. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs (was: Re: Summary/Minutes for today's FESCo meeting (2012-04-02))
On Mon, 2012-04-02 at 20:58 +0100, Richard W.M. Jones wrote: On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote: * #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52) Actually I think this is a good feature, but ... The feature page is wrong about The user experience should barely change. This is mostly a low-level change that has little visibility to the user. tmpfs is different in a number of important ways: - it's very limited in space compared to a real disk This is the reason why I refused having /tmp as tmpfs (or even as a separate partition) few months ago. Has anybody tried to use e.g. Brasero with it? Well, if you are burning a DVD, Brasero needs about 4 GB on /tmp -- not enough space in RAM or wasting a lot of disk space on having such big /tmp partition that is most of the time unused. Yes, you can tell Brasero to use some other space, but it obviously relies on volatility of the /tmp and doesn't clean after itself. I'm quite sure this is not only the case of Brasero. -- Vratislav Podzimek vpodz...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
On Fri, 2012-04-06 at 14:58 +0200, Ralf Corsepius wrote: On 04/06/2012 01:47 PM, Marcela Mašláňová wrote: On 04/06/2012 11:14 AM, Vratislav Podzimek wrote: On Mon, 2012-04-02 at 20:58 +0100, Richard W.M. Jones wrote: On Mon, Apr 02, 2012 at 08:32:56PM +0200, Miloslav Trmač wrote: * #834 F18 Feature: /tmp on tmpfs - http://fedoraproject.org/wiki/Features/tmp-on-tmpfs (mitr, 17:40:06) * AGREED: tmp-on-tmpfs is accepted (+5 -3) (mitr, 18:12:52) Actually I think this is a good feature, but ... The feature page is wrong about The user experience should barely change. This is mostly a low-level change that has little visibility to the user. tmpfs is different in a number of important ways: - it's very limited in space compared to a real disk This is the reason why I refused having /tmp as tmpfs (or even as a separate partition) few months ago. Has anybody tried to use e.g. Brasero with it? Well, if you are burning a DVD, Brasero needs about 4 GB on /tmp -- not enough space in RAM or wasting a lot of disk space on having such big /tmp partition that is most of the time unused. Yes, you can tell Brasero to use some other space, but it obviously relies on volatility of the /tmp and doesn't clean after itself. I'm quite sure this is not only the case of Brasero. We should file bugs on those issues and add them to some tracker bug, which will be created for tmpfs related issues. That a lost fight, because one of /tmp's primary purposes is to temporarily store almost arbitrarily huge amounts of data, instead of storing them in memory. This is the key overlooked fact. -- Vratislav Podzimek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Multimedia SIG
On Sat, 2012-01-14 at 14:44 -0500, Trever Fischer wrote: Greetings from FUDCon, in Blacksburg, VA. I know that only a handful of people might recognize me on devel@, but something that's been rolling around in my head for a little while is to start a Multimedia SIG in fedora. I know there exists the audio and music SIGs, but they focus more towards providing a platform on fedora for users to *create* audio content. Something that I feel is missing is a general purpose SIG that aims to make sure that multimedia use, enjoyment, and consumption on Fedora is taken care of very handsomely. This includes focusing on topics such as sorting out all the mess behind MP3 support (i.e. doing more than simply telling a user with 3k mp3s in a collection use ogg), managing photos, improving support for flash (obviously without explicitly saying fedora supports flash), doing fun stuff with streaming, making sure pulseaudio always works, etc. +1 to this idea. I know it's difficult to stay in bounds of 100% legality, freedom and openness, but there are many things that could be done (without crossing these bounds) to make dealing with media issues easier for users. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
On Wed, 2011-11-09 at 18:48 -0800, Adam Williamson wrote: On Thu, 2011-11-10 at 10:29 +0800, Mathieu Bridon wrote: On Wed, 2011-11-09 at 21:20 -0500, Simo Sorce wrote: On Wed, 2011-11-09 at 17:46 -0800, Adam Williamson wrote: I'm currently going through and bumping several packages whose Rawhide builds have got behind their F16 builds. I've come across several packages where git merge hit 'conflicts' for no readily apparently reason in this case. I haven't looked deeply enough to tell, but in general merges are a very bad tool and should be avoid IMHO. It would be much more sane to git cherry-pick the changes you need and keep the branches separate and have their own history. Merges makes it really painful to follow history later. I agree. Once branches have started to diverge, merging them makes the history harder to follow because the branches keep diverging, merging back, diverging again, merging,... However, it is sometimes possible to never diverge. In the example of gnome-power-manager, the master and f16 branches seem to contain the exact same changes, in the same order. In such a case, it would have made sense to always keep merging the branches rather than cherry-picking, so that they would never have diverged. And that would have avoided the conflict Adam is seeing. thanks both of you; I hadn't really thought about the consequences of merging vs. cherry-picking, I think I'd just cargo-culted from somewhere the idea of using git merge instead of manually re-doing changes without considering cherry-picking instead. so I guess in general it's both a better idea and more likely to work to use cherry-pick instead of merge, unless the two branches are really expected to be identical? Isn't it better to use 'git rebase'? E.g. on master use 'git rebase f16'. As I understand it, it would do the same as cherry-picking commit after commit in these cases. -- Vratislav Podzimek Anaconda Rider Red Hat, Inc. | Brno, Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
On Thu, 2011-11-10 at 10:52 +0100, Fabian Deutsch wrote: Am Donnerstag, den 10.11.2011, 10:36 +0100 schrieb Vratislav Podzimek: On Wed, 2011-11-09 at 18:48 -0800, Adam Williamson wrote: On Thu, 2011-11-10 at 10:29 +0800, Mathieu Bridon wrote: On Wed, 2011-11-09 at 21:20 -0500, Simo Sorce wrote: On Wed, 2011-11-09 at 17:46 -0800, Adam Williamson wrote: I'm currently going through and bumping several packages whose Rawhide builds have got behind their F16 builds. I've come across several packages where git merge hit 'conflicts' for no readily apparently reason in this case. I haven't looked deeply enough to tell, but in general merges are a very bad tool and should be avoid IMHO. It would be much more sane to git cherry-pick the changes you need and keep the branches separate and have their own history. Merges makes it really painful to follow history later. I agree. Once branches have started to diverge, merging them makes the history harder to follow because the branches keep diverging, merging back, diverging again, merging,... However, it is sometimes possible to never diverge. In the example of gnome-power-manager, the master and f16 branches seem to contain the exact same changes, in the same order. In such a case, it would have made sense to always keep merging the branches rather than cherry-picking, so that they would never have diverged. And that would have avoided the conflict Adam is seeing. thanks both of you; I hadn't really thought about the consequences of merging vs. cherry-picking, I think I'd just cargo-culted from somewhere the idea of using git merge instead of manually re-doing changes without considering cherry-picking instead. so I guess in general it's both a better idea and more likely to work to use cherry-pick instead of merge, unless the two branches are really expected to be identical? Isn't it better to use 'git rebase'? E.g. on master use 'git rebase f16'. As I understand it, it would do the same as cherry-picking commit after commit in these cases. Someone might correct me, but rebasing introduces problems for co-maintainers, if upstream (maintainer) decides to rebase some branch. See http://man.he.net/man1/git-rebase Yes, but I don't see any problem in a situation like this: A--B--C*master A--B--C--D--E *f16 I would expect the result to look like: A--B--C--D--E *master A--B--C--D--E *f16 -- Vratislav Podzimek Anaconda Rider Red Hat, Inc. | Brno, Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building cpufreq modules into F16 kernel is it right or wrong?
On Mon, 2011-10-17 at 22:40 +0300, alekc...@googlemail.com wrote: Frequency scaling have negative effects for me so I need to have it disabled in BIOS. What negative effects does frequency scaling have for you when using governor performance? -- Vratislav Podzimek I think that this is not BIOS option broken but broken kernel with built-in cpufreq modules. If hardware supports disabling frequency scaling then should be possibility to do this. BIOS have such possibility, Fedora kernels before F16 also makes it possible to use or not to use scaling. But with F16+ kernels this becomes impossible. Adam Jackson wrote: On Mon, 2011-10-17 at 21:54 +0300, alekc...@googlemail.com wrote: But this assumption was wrong for my system which have BIOS option for disabling CPU frequency scaling (SpeedStep). If SpeedStep is enabled in BIOS then kernel uses acpi-cpufreq built-in module but if I will disable frequency scaling in BIOS kernel still loads cpufreq module but p4-clockmod instead of acpi-cpufreq. Why would you choose broken BIOS options? - ajax -- Alexey Kurov nuc...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: what if native systemd service is slower than old sysvinit script?
On Thu, 2011-09-15 at 17:06 +, Jóhann B. Guðmundsson wrote: On 09/15/2011 04:11 PM, Michal Schmidt wrote: On 09/15/2011 05:54 PM, Ralf Corsepius wrote: On 09/15/2011 09:42 AM, Jóhann B. Guðmundsson wrote: On 09/15/2011 05:25 AM, Ralf Corsepius wrote: Anyway, some more figures: On the same machine, bootup times when booting from a (slow) external (IDE) USB2 HD: - Fedora 15/i386: ca. 135 secs. - Ubuntu 11.04/i386: ca. 70 secs. [Here bootup time: Wirst watch measured time from grub prompt to login screen] It shows the effect of slow disks (60secs w/ internal HD vs. 2.15 minutes w/ USB HD), but raises questions on why Ubuntu appears to be so much faster in this configuration. Could you run systemd-analyze plotbootup.svg and post it somewhere online See: http://corsepiu.fedorapeople.org/scratch/bootup-20110915.1.svg From the long delay before swap.target is reached it seems that your defined swap partition never comes up and systemd times out waiting on it. If you dont use any lvm, raid and encrypted devices, you can safely turn off all fedora-* services ( Anaconda (F16) finally offers desktop users an easy way to opt out from lvm without being partitioning experts ) #cd /lib/systemd/system #for i in fedora-*; do ln -s /dev/null /etc/systemd/system/$i;done We throw in udev-settle since it gets pulled in by the storage setup #ln -s /dev/null /etc/systemd/system/udev-settle.service If you want speed not eye candy you can disable plymouth #cd /lib/systemd/system #for i in plymouth-*; do ln -s /dev/null /etc/systemd/system/$i;done Then proceeding disabling all the service you dont use. #for i in service1 service2 service3 etc... ; do systemctl disable $i ;done Harald Hoyer made a nice guide on this topic: http://www.harald-hoyer.de/personal/blog/fedora-15-boot-optimization -- Vratislav Podzimek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need Little IT advice Here...
On Fri, 2011-08-12 at 00:05 -0700, T.C. Hollingsworth wrote: On Thu, Aug 11, 2011 at 8:58 PM, Manuel Escudero jmlev...@gmail.com wrote: Hi, I was Wondering if there was a tool for Linux in general that let me undo the system changes at reboot or something like that, For example: I want to set a standard configuration in a machine and then let that machine to be used by many users, but as soon as the user Log Out (preferably in that moment) Why not keep a known good home directory on hand, and replace it on logout? With KDE it's as easy as: cat /home/kioskuser/.kde/shutdown/reset-home.sh #!/bin/sh rm -rf $HOME/* cp -pr /usr/local/share/kioskuser-home/* $HOME ^D chmod +x /home/kioskuser/.kde/shutdown/reset-home.sh Other desktops should have similar functionality. Looking at this, btrfs' snapshots come to my mind. I think it could be easy to use for this case (just a simple init script [or sytemd unit file]). See https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Snapshots for more details. Vratislav Podzimek I want the machine to undo all the possible changes the user may have done while he/she was using it. I've seen this behavior on Windows Machines in Schools and Offices, and I know it has something to do about a server controlling all the individual computers but I want to apply that behavior to a Single Linux computer without having the server in the middle... If there's not a General Linux Tool I would like to Know wich distro and desktop enviroment are the best choice to get this done, using what tools, P.S. it's like... Having a customized LiveCD Behavior but with the system installed, so if I need to do changes, I can ensure I can do them without many problems, and then Lock the system again... Hope somebody knows, Thanks! -- Manuel Escudero Linux User #509052 Twitter: @Jmlevick Blogger: Blog Xenode PGP/GnuPG: E2F5 12FA E1C3 FA58 CF15 8481 B77B 00CA C1E1 0FA7 Xenode Systems - xenodesystems.com - Conéctate a Tu Mundo -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boot.fedoraproject.org (bfo)
On Wed, 2011-08-10 at 18:26 +0200, Rudolf Kastl wrote: Hello, A bit of (hopefully) constructive feedback. It might help with testing and adoption of fedora if the rcs and alpha releases are made available in the bfo setup. Actually within the experimental folder there is only a tc1 of f15 currently. Potential ideas for bfo: * keep the experimental option more up to date in the future. * while simple to install make the lkrn available in a ready to use rpm Last time i tried an install via bfo it didnt really select mirrors close to me. (i think for the install it didnt use a mirrorlist but instead a hardcoded repo by default) Is this still the case? AFAIK, mirrors are choosed by MirrorManager running on mirrors.fedoraproject.org which is used by yum and it's repos' configuration. It's quite easy to find out which repos' urls are used during the installation. But I doubt there are any different from urls used everywhere else. Vratislav Podzimek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boot.fedoraproject.org (bfo)
On Thu, 2011-08-11 at 06:46 -0700, John Reiser wrote: On 08/11/2011 05:26 AM, Vratislav Podzimek wrote: On Wed, 2011-08-10 at 18:26 +0200, Rudolf Kastl wrote: Last time i tried an install via bfo it didnt really select mirrors close to me. (i think for the install it didnt use a mirrorlist but instead a hardcoded repo by default) Is this still the case? AFAIK, mirrors are choosed by MirrorManager running on mirrors.fedoraproject.org which is used by yum and it's repos' configuration. It's quite easy to find out which repos' urls are used during the installation. Anaconda itself does not disclose the identity of any mirrors it uses, and after the install there is no record of which mirrors were used. Please specify exactly what you use to identify the specific mirrors. What I meant is that you can get repos' configuration (at least for default repos) during installation: 1) switch to shell (with Ctlr+F2) 2) ls /etc/anaconda.repos.d/ 3) cat SOME_REPO_CONFIG_FILE When I use this for 'fedora.repo' file I can see following line: mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releaseverarch=$basearch which reveals the fact that yum (ran during the installation) will use MirrorManager running on mirrors.fedoraproject.org (which is the same as in an already installed system). But I doubt there are any different from urls used everywhere else. The tail of the path (the filename and last few directory names) is certainly the same, but each mirror is free to place the tree arbitrarily in its filesystem, and many do. As I mentioned before, the MirrorManager is responsible for returning the right mirrorlist already sorted out from the best mirror to the worst one (see [1] if you are interested). You can test it by entering mirrorlist URL into your web browser. So I really doubt it's somehow specific for the bfo. Vratislav Podzimek [1] https://fedorahosted.org/mirrormanager/wiki -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15: most services sysvinit only?
On Wed, 2011-06-15 at 09:54 +0200, Michał Piotrowski wrote: Hi, 2011/6/15 Petr Pisar ppi...@redhat.com: On 2011-06-15, Tomasz Torcz to...@pipebreaker.pl wrote: On Wed, Jun 15, 2011 at 02:14:28AM +0200, Reindl Harald wrote: playing with F15 on a test-vm seems for me most services are not suing systemd, th eonly widely used is apache and fpr dovecot i am not sure That's because maintainers largely ignored systemd integration furing F14 and F15 devel cycles. See bugs linked from: https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability There are few maintainers and upstream who responded quickly, though. Beacuse specification how to do it was released one week before F15. This of course did not prevent the part of developers in delivering systemd services for F15. What is the purpose of this discussion? The main point is: let's make it better in F16+ releases!. Vrata Podzimek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning cnetworkmanager
I'm not sure nmcli does everything cnetworkmanager did -- e.g. Can you create new (wireless) connection with nmcli? On Wed, 2011-06-01 at 08:51 -0600, Kevin Fenzi wrote: I've just orphaned cnetworkmanager. Upstream is pretty dead, and nmcli does everything cnetworkmanager did and more. Also, it may not work at all in f15+ due to NM changes. There's 2 open bugs on it: 709356Fedora new cnetworkmanager D-Bus error, ServiceName property 583043Fedora assignedUnicodeEncodeError in networkmanager/util.py line 125 If someone would like to take it and run with it, great. ;) kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: anaconda-15.31-1.fc15 - Update the requirements for memory..
It might be better to send these to anaconda-devel-l...@redhat.com Vrata Podzimek On Sat, 2011-05-07 at 18:53 +0200, Reindl Harald wrote: Am 07.05.2011 18:48, schrieb Kevin Higgins: From what I can figure out it looks like lorax-0.4.4-1.fc15 uses and needs more memory I can run Fedora 15 in full shell on our slowest 1.5 Ghz laptop with 256mb memory and it runs faster than f14, I do an install with 512MB than take out stick. The live cd as of May6 that I made using the repo.../development/15/i386/os/ only, does a full install without problems, it doesn't seem to use lorax for the install. But if we make the minimum 768 for anaconda than I will no longer be able to even do a livecd install to these machines, that we have since 2004, installed Fedora on them and than given them away to needy families in our area. Is there a way to have anaconda have a minimum requirements for install and a separate minimum requirements for a live install? These systems are donated to us we refurbish them and then they go back out loaded with Fedora to students and families in need. not only that there are many servers out there with i686 CPUs and low memory which running without any problems - so the os-installer should have minimum requirements it would be a bead thing if a voip-server runs perfectly with 256 MB RAM but you are unable to install the os until you stripped down unneded stuff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
