Re: Loopy rpm subpackages dependencies
On Thu, 28 Mar 2019, Tomasz Kłoczko wrote: > Hi, > > Just found that on some minimal system it is not possible to remove some rpm > subpackages. > > * Current state > > # rpm -qa | grep rpm > rpm-libs-4.14.2.1-4.fc30.1.x86_64 > rpm-4.14.2.1-4.fc30.1.x86_64 > python3-rpm-4.14.2.1-4.fc30.1.x86_64 > rpm-build-libs-4.14.2.1-4.fc30.1.x86_64 > rpm-sign-libs-4.14.2.1-4.fc30.1.x86_64 > > python3-rpm is required by dnf so it is really hard to have manageable > system without that part (however in extreme cases it is still possible to > drop completely dnf). You could always use microdnf instead. Michael Young___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Anyone working on Xen on F29
On Fri, 26 Oct 2018, Aaron Gray wrote: > Hi, > > I am trying to get Xen working properly on rawhide / F29 Beta. > > I had one instillation on F29 that worked straight away with :- > > sudo yum groupinstall 'Virtualization' sudo yum install xen > > I cannot seem to reproduce this now though :( > > And am getting the following :- > ~~~ > Loading xen 4.11.0 > error: ../../grub-core/fs/fshelp.c:258:file > `/EFI/fedora/x86_64-efi/module2.mod' not found. > error: ../../grub-core/fs/fshelp.c:258:file > `/EFI/fedora/x86_64-efi/multiboot2.mod' not found. > Loading Linux 4.18.5-300.fc29.x86_64 ... > error: ../../grub-core/script/function.c:109@can't file command `module2'. > Loading initial ramdisk ... > error: ../../grub-core/fs/fshelp.c:258:file > `/EFI/fedora/x86_64-efi/module2.mod' not found. > error: ../../grub-core/script/function.c:109@can't file command `module2'. > ~~~ Grub doesn't get the EFI confguration for xen right. I suggest you try creating the directory /boot/efi/EFI/fedora/x86_64-efi/ if it doesn't exist and copying into it the multiboot2.mod and relocator.mod files from /usr/lib/grub/x86_64-efi (from the grub2-efi-x64-modules package if you don't have it installed already). That should boot with warnings and you can get rid of them by editing /boot/efi/EFI/fedora/grub.cfg and removing the insmod module2 lines. Michael Young___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: DNF and Modularity
On Mon, 24 Sep 2018, Petr Šabata wrote: > On Mon, Sep 24, 2018 at 10:02:39AM +0200, Miroslav Suchý wrote: > > Hi, > > I have to admit that I am a bit puzzled about DNF behavior with modularity. > > > > I have installed repo files with modularity repos, but all of them are > > disabled. I have no module enabled on my system > > (F29 BTW). To be precise: > > output of `dnf module list` > > https://paste.fedoraproject.org/paste/3QvX2xv4OgVVmgckTnEQcQ > > > > And every time I run `dnf upgrade` I get this output: > > > > Problem 1: cannot install the best update candidate for package > > bubblewrap-0.3.0-2.fc29.x86_64 > > - package bubblewrap-0.3.0-2.module_2123+73a9ef6f.x86_64 is disabled > > Problem 2: cannot install the best update candidate for package > > docker-distribution-2.6.2-7.git48294d9.fc28.x86_64 > > - package > > docker-distribution-2.6.2-7.git48294d9.module_1641+02d06da9.x86_64 is > > disabled > > Problem 3: cannot install the best update candidate for package > > eog-3.28.3-1.fc29.x86_64 > > - package eog-3.28.3-1.module_2123+73a9ef6f.x86_64 is disabled > > Problem 4: cannot install the best update candidate for package > > exempi-2.4.5-3.fc29.x86_64 > > - package exempi-2.4.5-3.module_2123+73a9ef6f.x86_64 is disabled > > Problem 5: cannot install the best update candidate for package > > flatpak-runtime-config-27-7.fc29.x86_64 > > - package flatpak-runtime-config-27-7.module_2021+15e5e3e7.x86_64 is > > disabled > > Problem 6: cannot install the best update candidate for package > > gimp-2:2.10.6-2.fc29.x86_64 > > - package gimp-2:2.10.6-2.module_2129+8576126a.x86_64 is disabled > > Problem 7: cannot install the best update candidate for package > > gimp-libs-2:2.10.6-2.fc29.x86_64 > > - package gimp-libs-2:2.10.6-2.module_2129+8576126a.x86_64 is disabled > > Problem 8: cannot install the best update candidate for package > > kubernetes-client-1.10.3-1.fc29.x86_64 > > - package kubernetes-client-1.10.3-1.module_2132+faf1362b.x86_64 is > > disabled > > Problem 9: cannot install the best update candidate for package > > libnghttp2-1.33.0-1.fc29.x86_64 > > - package libnghttp2-1.33.0-1.module_2177+2526c218.x86_64 is disabled > > Problem 10: cannot install the best update candidate for package > > libpeas-1.22.0-9.fc29.x86_64 > > - package libpeas-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled > > Problem 11: cannot install the best update candidate for package > > libpeas-gtk-1.22.0-9.fc29.x86_64 > > - package libpeas-gtk-1.22.0-9.module_2123+73a9ef6f.x86_64 is disabled > > Problem 12: cannot install the best update candidate for package > > libpeas-loader-python3-1.22.0-9.fc29.x86_64 > > - package libpeas-loader-python3-1.22.0-9.module_2123+73a9ef6f.x86_64 is > > disabled > > Problem 13: cannot install the best update candidate for package > > libuv-1:1.22.0-2.fc29.x86_64 > > - package libuv-1:1.23.0-1.module_2177+2526c218.x86_64 is disabled > > Problem 14: cannot install the best update candidate for package > > nghttp2-1.33.0-1.fc29.x86_64 > > - package nghttp2-1.33.0-1.module_2177+2526c218.x86_64 is disabled > > Problem 15: cannot install the best update candidate for package > > nodejs-1:10.11.0-1.fc29.x86_64 > > - package nodejs-1:10.11.0-1.module_2200+adbac02b.x86_64 is disabled > > Problem 16: cannot install the best update candidate for package > > npm-1:6.4.1-1.10.11.0.1.fc29.x86_64 > > - package npm-1:6.4.1-1.10.11.0.1.module_2200+adbac02b.x86_64 is disabled > > Problem 17: cannot install the best update candidate for package > > perl-DB_File-1.842-1.fc29.x86_64 > > - package perl-DB_File-1.842-1.module_2073+eebc5b71.x86_64 is disabled > > Problem 18: cannot install the best update candidate for package > > perl-HTTP-Tiny-0.076-1.fc29.noarch > > - package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch is disabled > > Problem 19: cannot install the best update candidate for package > > perl-Thread-Queue-3.13-1.fc29.noarch > > - package perl-Thread-Queue-3.13-1.module_2073+eebc5b71.noarch is disabled > > > > It does not matter if I pass `--best` option or not. > > Why I - as a user - see this warnings/errors? > > > > Is this an error or a feature? > > Definitely an error. > > Could be another case of > https://bugzilla.redhat.com/show_bug.cgi?id=1629396, but it > should have been fixed last week. Is your repo current? > Could you check for the presence of modular repodata (the > *modules.yaml.gz) file. the dnf upgrade problem looks to me like https://bugzilla.redhat.com/show_bug.cgi?id=1616118 Michael Young___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
Re: Why is Fx 57 in Updates Testing?
On Wed, 11 Oct 2017, Martin Stransky wrote: > On 10/11/2017 03:46 PM, Mátyás Selmeci wrote: > > On 10/11/17 08:32, Martin Stransky wrote: > > > On 10/11/2017 03:17 PM, Gerald B. Cox wrote: > > > > Was this on purpose? Fx 57 is BETA, and I was under the impression that > > > > BETA software was for RAWHIDE. > > > > > > It's going to be stable in one month. Fx 57 release date is 2017-11-14. > > > > > > > Yes, I understand there is an annotation NOT to push Fx 57 to stable - > > > > but > > > > I thought that was the purpose of updates testing... software there is > > > > intended to be tested and pushed to stable. > > > > > > I expect the testing repo is used by experienced users who wish to test > > > software planned for Fedora thus I don't see any problem here. > > > > > > > There are many extensions which aren't yet available for Fx 57 - and > > > > we're > > > > effectively moving up the timetable by putting it in updates testing. > > > > > > Do you think it's better when it suddenly appears on stable at 2017-11-14? > > > I do not. > > > > > > ma. > > > > Will an older version (either 56 or the ESR version, 52) also be included in > > Fedora 27 as a separate package? > > No, we (Red Hat Desktop team) will ship Firefox 57 only as well as Mozilla > does. Of course anyone can create/maintain additional Firefox packages (ESR, > Developer edition...) for Fedora as I mentioned many times before. > > This is also reason why I created this update for testing so early. The problem is that Fedora 27 is still getting updates from updates-testing at the moment (until the final freeze scheduled for 2017-10-17) so anyone running dnf update on F27 will get Firefox 57 at the moment. Michael Young___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: spice-xpi not working in Firefox 52+
On Thu, 16 Mar 2017, Juan Orti Alcaine wrote: > Hi, it looks like the Spice XPI addon no longer works in Firefox 52. > > I guess this is going to be forever, as Firefox 52+ disables the NPAPI > plugins. Do you know any alternative? I manage a RHEV farm and this is going > to be a big deal. > > If there is no other alternative to open the Spice consoles from the browser > we'll have to change all of them to VNC. If you want a short term solution then firefox ESR 52 still supports NPAPI. Michael Young ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Can't upgrade, package system-python-libs not signed
On Tue, 8 Mar 2016, Gregorio . wrote: > I'm new and I'm not an expert. I've Fedora 23 and I tried to upgrade my > system to Fedora 24. > > I used the following command: # dnf system-upgrade download --releasever 24 > > After this command the system downloads a lot of packages, but there is an > error: > > Error: Package system-python-libs-3.5.1-7.fc24.x86_64.rpm is not signed As Fedora 24 is still in the development stage you can get minor issues like this. Adding --nogpgcheck to the dnf line might work (it does for normal dnf usage). > p.s. Another question, is possible to upgrade directly from the rawhide? Yes you can, but it could be particularly unstable now that Fedora 24 has been forked off so it may not be a good idea unless you want something that is only in rawhide. Michael Young -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: gnome-boxes downgrade in F-19
On Tue, 8 Oct 2013, Dan Williams wrote: On Tue, 2013-10-08 at 08:42 -0600, Jerry James wrote: Do you remember when I ranted about lack of communication between provenpackagers and the maintainers of the packages they touch [1]? Here is another case of lack of communication between people touching the same package. On Aug 8, Zeeshan Ali built gnome-boxes-3.8.4-1.fc19 and submitted update FEDORA-2013-14567. On Aug 9, Christophe Fergeau built gnome-boxes-3.8.4-2.fc19. Instead of editing the existing update, Christophe chose to create a competing update, FEDORA-2013-14530. Seems like there's something wrong with Bodhi here, because every time I create an update when there's already an older update pending, Bodhi obsoletes the old one and adds all the bugs from the old one to the new update. Even if somebody else filed the older update and I'm creating the new one. AFAIK, normal procedure is that you *don't* edit the old update at all, but each package NVR should get a new Bodhi update (so Christophe was correct in creating a new competing one) but that Bodhi takes care of obsoleting the old one. I have had this sort of thing happening to me a few times. From what I remember, Bodhi doesn't seems to obsolete packages that are in the pending state for updates-testing, so if you submit a new build within a day or so of the previous one (for example if a security update comes out just after another build) then bodhi may not obsolete the older build automatically. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F20 System Wide Change: No Default Syslog
On Wed, 17 Jul 2013, Alexey I. Froloff wrote: How would /var/log/messages file help in case of a corrupted filesystem/disk? You stand a considerably better chance of reading a text file than a database when it has partial corruption. Of course if the file, filesystem or disk is completely trashed then you a stuck either way. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Wed, 17 Jul 2013, Lennart Poettering wrote: cat /var/log/messages becomes journalctl tail -f /var/log/messages becomes journalctl -f tail -n100 /var/log/messages becomes journalctl -n100 grep foobar /var/log/messages becomes journalctl | grep foobar This isn't complex. You can grep/sed/awk as much as you want. You just do it over the output of journalctl rather than teh file. That's not that big a difference. One thing you have missed is how you edit the log file. There may be cases where you want to strip out log entries, eg. when a process has gone wild and swamped the useful messages with useless ones and you want to keep the useful ones and throw away the useless ones. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Wed, 17 Jul 2013, john.flor...@dart.biz wrote: From: m.a.yo...@durham.ac.uk On Wed, 17 Jul 2013, Lennart Poettering wrote: cat /var/log/messages becomes journalctl tail -f /var/log/messages becomes journalctl -f tail -n100 /var/log/messages becomes journalctl -n100 grep foobar /var/log/messages becomes journalctl | grep foobar This isn't complex. You can grep/sed/awk as much as you want. You just do it over the output of journalctl rather than teh file. That's not that big a difference. One thing you have missed is how you edit the log file. There may be cases where you want to strip out log entries, eg. when a process has gone wild and swamped the useful messages with useless ones and you want to keep the useful ones and throw away the useless ones. I used to do something like this with vim :g/NOISE/d until I could see the detail I wanted when the alternations for grep would have been tremendously long. With journalctl's built-in filtering capabilities I'm glad I don't have to do that anymore; it's way more concise. However, all use cases differ, so if you must, you can: journalctl | vim -. YMMV with other editors though. That isn't a complete solution though because you may want to remove the bad logs completely to free up the space they are taking up. Of course you may have already lost all the interesting logs by this point with journald anyway because they have been overwritten. That leads me to ask another question, how well does journald cope with keeping certain logs long term? The classic syslog way of doing this is to send them to a separate file, then use logrotate to compress them once they have been rotated. Is there any equivalent with journald? Compressing may be necessary due to the quantity of logs required. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Wed, 17 Jul 2013, Jóhann B. Guðmundsson wrote: Maybe we can give another shot of relevance by collecting a list of packages that depend on syslog (or are useless without /var/log/messages or other log files in /var/log) ? I've heard logwatch, logrotate and fail2ban mentioned. Are there others ? yum whatprovides /var/log/* | grep Filename | wc -l 597 Most of those will be packages that log directly to files in /var/log, and so don't care whether journald or rsyslog is used, though they may assume logrotate is present to handle their logs. Michael Young-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F20 System Wide Change: No Default Syslog
On Wed, 17 Jul 2013, Eric Smith wrote: On Wed, Jul 17, 2013 at 8:39 AM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Allowing editing of log files is a pure security risk... So is giving a sysadmin the root password, but we do it. I generally make a copy of a log file and edit the copy, but I'd oppose anything that took away the ability for log files to be edited. Another reason why you might to edit the journal is when you have to keep logs for a precise time for regulatory reasons. This isn't a problem under the classic logging and rotation. Michael Young-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Virtualization on ARM (was: Re: F20 System Wide Change: ARM as primary Architecture)
On Wed, 10 Jul 2013, Richard W.M. Jones wrote: On Tue, Jul 09, 2013 at 11:32:46AM -0400, Jonathan Masters wrote: Excellent proposal. I of course think this would be just awesome! This proposal doesn't address virtualization! I think this is great, BUT I'd also like to see a widely available cheap ARM platform that supports virtualization, AND for which virtualization genuinely works out of the box. Because, otherwise we can't start properly getting libvirt and the rest of the virt stack working. I was intending to update xen on Fedora 20 to the newly released xen-4.3.0. This adds ARM support as a technology preview, though I don't know if this meets your requirements. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: using rpms for non-root installs
On Wed, 30 Jan 2013, Mátyás Selmeci wrote: This may be a long shot, but I am interested in repackaging some RPMs (for example, some of the Globus packages in EPEL, as well as grid software that my group builds) such that the software in them may be installed by unprivileged users, or into a non-standard location such as an NFS share. I'd like to use existing RPMs, preferably binaries, as a starting point to avoid duplicating work. (Naturally a lot of post-install scripting would be needed to fix binaries such that they'd work with the path they were installed into). It depends want you mean by install but you can unpack the files in an rpm package with rpm2cpio eg. cd target/dir ; rpm2cpio some.rpm | cpio -idmv Michael Young-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Out of date (behind stable) build in testing
On Mon, 14 Jan 2013, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Sun, 13 Jan 2013 20:55:16 -0600 Bruno Wolff III br...@wolff.to escribió: On Sun, Jan 13, 2013 at 12:30:19 -0700, Kevin Fenzi ke...@scrye.com wrote: I'll untag it manually. If I had manually untagged it, would that have done the trick? I wasn't sure if that was all that was needed or if there was more too it? (I seemed to remember that testing tags could be changed by packagers.) you wouldnt have permissions to untag it manually. but yes thats whats needed. its likely due to a bug in bodhi with updates not being obsoleted right, or not being unpushed then being deleted. I have seen a problem like this if you submit 2 updates too close together then the second may not obsolete the first. The submitter does seem to be able to unpush problem updates though and they do seem to get obsoleted by subsequent updates. Michael Young-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing Puppet in Fedora/EPEL
On Tue, 23 Oct 2012, Vít Ondruch wrote: Dne 23.10.2012 15:10, Matthew Miller napsal(a): On Tue, Oct 23, 2012 at 01:57:13PM +0200, Vít Ondruch wrote: Lets have puppet-3.x and puppet2 for whoever wants to use old version. But that doesn't help people running puppet 2.6 _now_, and just introduces complication into the packaging. Introducing new package is complication anyway, so what is the point? The problem is that upgrading from 2.6 to 2.7 (and therefore to 3) will almost certainly break things depending on how the update is done, for example resulting in clients that don't work against the server, so you don't want to break lots of puppet installations out there by automatically updating the puppet to version 3 which is what would happen if you changed the version in the puppet package. With a puppet3 package people can choose when they upgrade and do it in a controlled manner. Michael Young-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Tue, 19 Jun 2012, Dennis Jacobfeuerborn wrote: pvgrub peeks into the guest disk so it needs to understand the partition table, the filesystem and the grub config file in the guest. Initially it didn't handle things like ext4, grub2 and EFI but AFAIK these should be fine now. I'm not sure what Amazons host systems use but hopefully they run a relatively modern version of pvgrub. pv-grub is basically a copy of grub1 that is loaded into the guest by the base system, so no software is needed in the guest only the configuration. I don't know what Amazon are using but there are definitely patches available that add ext4 and btrfs support. I am not aware of any grub2 patches. This is no to be confused with pygrub, which is a python script run in the base domain. It looks into the guest file system, parses the configuration, extracts the right kernel and init file, then loads them into the guest with the relevant configuration. The latest versions of this do understand grub2 configuration and EFI. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Important kernel update should not break stuff
On Wed, 13 Jun 2012, Nikola Pajkovsky wrote: imo, kernel maintainers should have released 3.3.8 or 3.4.1, not 3.4.0 for f17 I believe the 3.4.0 kernel package was effectively 3.4.1 anyway. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Repost] What is Error: Protected multilib versions
On Thu, 5 Apr 2012, Richard W.M. Jones wrote: I still get this error several times a week, and I still have no idea what it means or how I'm supposed to respond to it (other than fiddling randomly with packages until it goes away). The latest one: # yum install /usr/sbin/libvirtd [... yum spew deleted ...] Error: Protected multilib versions: libvirt-client-0.9.10-2.fc17.i686 != libvirt-client-0.9.10-3.fc17.x86_64 $ rpm -qa | grep libvirt-client libvirt-client-0.9.10-3.fc17.x86_64 What does the error mean? You can get this when a package wants the older version of (in this case) libvirt-client and tries to pull in the i686 version to resolve the dependency when it doesn't specify a particular arch. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /tmp on tmpfs
On Tue, 3 Apr 2012, Chris Adams wrote: Also, if some user has taken up lots of space in /tmp, you can LART the user and delete the files; that's no different than a user filling up a partition by writing to /tmp (no reboot necessary in either case). That assumes your system is still functional enough to allow you to do that. In a low memory/high swap situation, which this could easily trigger, logging in and clearing the files could be very slow, and the login process could time out before you get logged in. Michael Young -- 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, 2 Apr 2012, Lennart Poettering wrote: On Mon, 02.04.12 16:55, Steve Grubb (sgr...@redhat.com) wrote: What about forensics? Any reboot erases information that might have been needed to see what happened during a break in. /tmp is already volatile and cleaned up in regular intervals. The new clean-up on boot is just one tiny bit of additional clean-up. there is a big difference however with files in /tmp being around for 30 days, and the files being cleaned on a reboot, which might be necessary to get the system in a reliable enough state to do any forensics. This also means a big change in user experience as many will be expecting things in /tmp to remain there for a while before being deleted even if the system is restarted or crashes. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Torvalds:requiring root password for mundane things is moronic
On Wed, 29 Feb 2012, drago01 wrote: On Wed, Feb 29, 2012 at 1:02 PM, Neal Becker ndbeck...@gmail.com wrote: I think he's got a point http://www.osnews.com/story/25659/Torvalds_requiring_root_password_for_mundane_things_is_quot_moronic_quot_ Yeah but last time we tried this in fedora it got flamefested so we had to revert. From what I remember permissions were opened up without making it clear this was happening and without an easy way of putting them back, which made things very difficult if you had good reasons for the permissions being locked down. The flamefest was at least in part because things were done badly, leading to the Fedora introduces security holes type of headline. I think the right way to do it is for things to be secure by default, but with easy tools to relax security where appropriate (which could include options to do this during install). Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Getting grub launching the installer
On Sat, 12 Nov 2011, Sam Varshavchik wrote: For the longest time, I was able to upgrade an existing system by copying over the pxeboot vmlinuz and initrd.img, sticking them into menu.lst, and directing grub to load them. Up until F14 this worked fine. F15's pxeboot/vmlinuz made me stare at a blank screen, and the only available option, apparently, was the three-fingered salute. I wrote it off as an F15 glitch. How long did you wait? I updated a few days ago, but it took perhaps a couple of minutes before it should anything other than a blank screen. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 15 Alpha TC2 Available Now!
On Tue, 15 Feb 2011, Chris Adams wrote: Hmm, also what does this do to PXE booting. IIRC there is a (relatively low) limit on the size of the initrd loaded by pxelinux. Most tftp servers can cope with bigger sizes now, but not necessarily in consistent ways. pxelinux talking to linux tftp should be fine, but expect problems if you use a Solaris tftp server. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Viewing a scratch-build
On Wed, 20 Oct 2010, Paul F. Johnson wrote: Hi, I've followed the instructions on the fedoraproject website to try and view a scratch-build result (go to tasks and select the scratch build), but it's not showing anything for rawhide scratch builds. Is there some sort of magic I need to invoke to get it to show? Go to the koji users page http://koji.fedoraproject.org/koji/users find yourself in the list, select the view tasks button on your row, then change State from active to all (other options like closed probably work as well). Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: upstart in rawhide
On Thu, 14 Oct 2010, Adam Williamson wrote: On Thu, 2010-10-14 at 17:13 +0200, Petr Lautrbach wrote: Hello, systemd will be default init system in Fedora 15 and scripts infrastructure will be adapted to it. There is a plan to leave upstart in Fedora as non-official alternative. Why? It makes perfect sense to me, as there could easily be things that don't work with systemd and submit a bug report then use upstart is a more appropriate answer than don't use rawhide/F15 until it is fixed or try Ubuntu. Also upstart is in the contingency plan for the systemd feature. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, 15 Sep 2010, drago01 wrote: I think the main point here wasn't there are bugs #X, #Y and #Z that can't be fixed in time so we should revert but a we have a bad feeling / are nervous so lets revert ... the later isn't really a technical decision basis and can (and here it did) piss of the one working on said feature. In this case the bad feeling is justified, because there were too many problems too late in the release cycle. It isn't a matter of whether all the known bugs are fixed but whether we can be reasonably confident that there aren't any more critical bugs that haven't been reported yet or have been introduced by the latest updates. Maybe there should be some sort of stability test for core features (eg. no major changes, no more than a certain number of blocker bugs raised) after the alpha phase. The acceptance criteria should have been present from day one (i.e the day the feature was accepted) not shortly before beta (which pretty much limits the time to work to met them). I agree. I was worried when systemd appeared in F14 just before the alpha. Really we should have been much closer to where we are now at the start of the alpha phase, and systemd should have gone in soon after F13 was forked off. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On Wed, 15 Sep 2010, drago01 wrote: On Wed, Sep 15, 2010 at 12:27 PM, M A Young wrote: It isn't a matter of whether all the known bugs are fixed but whether we can be reasonably confident that there aren't any more critical bugs that haven't been reported yet or have been introduced by the latest updates. There is no way to know that ... based on this we should not add anything new because we can't be sure that they aren't any unknown critical bugs. But you can base it on what bugs were raised or still open during the alpha phase. If there were a lot of issues during the alpha phase then that is likely to continue in the beta phase. That was why I was suggesting you count all blocker bugs, not just those that are still open. It doesn't guarantee that there will or won't be be any critical bugs but it does give an objective measure of how stable and well tested the code is. Maybe there should be some sort of stability test for core features (eg. no major changes, no more than a certain number of blocker bugs raised) after the alpha phase. We already have that its called Feature freeze. I don't think that is enough, as the features can stay the same but the code used to achieve this can potentially change completely. My impression is that systemd has changed a great deal during the alpha phase even though I imagine the features it aims to provide have stayed the same. I agree. I was worried when systemd appeared in F14 just before the alpha. Really we should have been much closer to where we are now at the start of the alpha phase, and systemd should have gone in soon after F13 was forked off. IIRC systemd wasn't even written back then. And that is precisely the problem - the code isn't really stable enough yet for Fedora because it has been developed very quickly and so hasn't had a chance to stablize yet. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: If you cannot boot after installing systemd v8...
On Thu, 26 Aug 2010, Lennart Poettering wrote: How about making the postinstall script in systemd-units detect this condition (default.target pointing to a nonexistent file) and fix it up automatically? Note that version 8-2 waiting in bodhi should now handle upgrades from the alpha without problems. Does it cope with the shutdown problem? After I updated systemd to 8 I couldn't shut the computer down, because (if I am remembering correctly) it couldn't find reboot.socket Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: is it still possible to use upstart as the init-system in F-14?
On Wed, 25 Aug 2010, Peter Lemenkov wrote: I would like to know before trying/upgrading F-14 is it still possible to use upstart instead of systemd in F-14? Yes, upstart still works. I tried systemd and couldn't get it to work, so I switched the machine back to upstart. You may need a rescue disk to make the switch if your computer doesn't boot with systemd. I might try systemd again when more of the bugs have been ironed out. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: is it still possible to use upstart as the init-system in F-14?
On Wed, 25 Aug 2010, Rahul Sundaram wrote: On 08/25/2010 05:35 PM, M A Young wrote: Yes, upstart still works. I tried systemd and couldn't get it to work, so I switched the machine back to upstart. You may need a rescue disk to make the switch if your computer doesn't boot with systemd. I might try systemd again when more of the bugs have been ironed out. Do you have any unreported bugs? I tried it again, and basically the boot doesn't ever finish, it just sits there without any useful indication as to what the problem is until I get fed up and use the sysrq keys to reboot it ctrl-alt-del doesn't work). Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git question
On Tue, 24 Aug 2010, Steve Dickson wrote: Also, the kernel that is currently being built from my pnfs-13 branch fails to install with the following error: FATAL: Could not load /lib/modules/2.6.34.5-43.pnfs_all_2.6.35_2010_08_19.fc13.x86_64-pnfs/modules.dep: No such file or directory The extra -pnfs on the 2.6.34.5-43... directory name is the problem. It probably has something to do with how I changed the buildid: I suspect it has nothing to do with the buildid (I use one and don't have the problem). I would check the kernel version file in the source (I don't know offhand what it is called) and see if -pnfs is added there. If it is add a patch to remove it. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Git question
On Tue, 24 Aug 2010, Steve Dickson wrote: On 08/24/2010 10:46 AM, M A Young wrote: On Tue, 24 Aug 2010, Steve Dickson wrote: Also, the kernel that is currently being built from my pnfs-13 branch fails to install with the following error: FATAL: Could not load /lib/modules/2.6.34.5-43.pnfs_all_2.6.35_2010_08_19.fc13.x86_64-pnfs/modules.dep: No such file or directory The extra -pnfs on the 2.6.34.5-43... directory name is the problem. It probably has something to do with how I changed the buildid: I suspect it has nothing to do with the buildid (I use one and don't have the problem). I would check the kernel version file in the source (I don't know offhand what it is called) and see if -pnfs is added there. If it is add a patch to remove it. Does anybody know the name of the file Michael is talking about? I was misremembering a bit. What may be adding that extra bit is any file in the base of the kernel tree of the form localversion* which get sucked in by the base level Makefile. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Kernel 2.6.34 for F13?
On Fri, 20 Aug 2010, Reindl Harald wrote: Will 2.6.34 pushed to stable? My question is because there were also some 2.6.30 builds for F11 which never rolled out and it could possible relax some things in combination with VMware / open-vm-tools https://bugzilla.rpmfusion.org/show_bug.cgi?id=1373 I see this two builds in my test-vm form updates-testing kernel-2.6.33.6-147.2.4.fc13.x86_64 kernel-2.6.34.2-34.fc13.x86_64 At this stage I imagine the only answer you will get is that it might do. As there are 2.6.34 builds in koji the kernel team are clearly investigating the possibility of switching to 2.6.34, and if they can get it to work as well as or better than the current 2.6.33 kernels and it passes QA then they are likely to move to it. As Fedora 13 is going to be supported for another 9 months or so, it is likely that the change will be made at some point. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 'make prep' breaks on private branches.
On Thu, 19 Aug 2010, Roland McGrath wrote: Here is what I'm doing: fedpkg clone kernel fedpkg switch-branch f14 git checkout -b pnfs-all-2.6.35-2010-08-05 Make that 'git checkout --track -b pnfs-blah-blah origin/f14/master'. Or, equivalently, after the fact, do: git config branch.pnfs-blah-blah.remote origin git config branch.pnfs-blah-blah.merge refs/heads/f14/master but don't do a git push without specifying which branch you want to write to, because in this case the default will be the main f14/master branch on the server. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Creating private branches under fedpkg/git
On Wed, 18 Aug 2010, Jesse Keating wrote: However, since git allows you to create local branches at will without any restrictions, one has to ask if it is still necessary to have a remote branch for your work. I did end up creating a branch in the Fedora system because it was the only way I could get koji to build directly from git. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upcoming Fedora 14 Linux Release
On Mon, 16 Aug 2010, Kevin Kofler wrote: ... So I'd suggest to use a currently supported Fedora release (12 or 13) with the unofficial Dom0 kernel RPMs out there (built for F12, I don't know if they work on F13). The kernel seems to work okay on F13 and even F14, though I haven't tested it extensively. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upcoming Fedora 14 Linux Release
On Sun, 15 Aug 2010, Mr. Teo En Ming (Zhang Enming) of Singapore wrote: May I know whether the upcoming F14 release will include support for Xen pv-ops Dom0 kernel? No. The Fedora policy isn't to include dom0 support until it makes it into the upstream kernel. Some pieces have made it into 2.6.36 pre-rc but more are required before dom0 will work. It might be in f15 if 2.6.37 is out in time and if dom0 support is in it, though f16 or later is more likely. Note that in the f14 and rawhide xen package xm and possibly xend are currently broken due to python 2.6-2.7 changes in xmlrpc. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abrt thoughts pre-rfe q?
On Sun, 8 Aug 2010, Matt McCutchen wrote: Users should already be reading the existing information, because abrt provides the link after it makes its changes (adding the user to CC and adding a comment with the how to reproduce text, if it was nonempty). The proposal would just be to reverse the order of the steps so that users can, and hopefully will, avoid adding redundant comments. It would also be good if this could happen before the debuginfo packages are downloaded, which would mean that those with limited bandwidth could contribute more easily if there was an existing bug. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changelog for the latest Fedora kernel release/updates
On Sat, 7 Aug 2010, Mathieu Bridon wrote: The Fedora packages histories are kept in git trees. You can get each one by running: $ fedpkg clone -B $package Note that in order to do so you probably need to be a Fedora Packager. In your case, that would be : $ fedpkg clone -B kernel You will then obtain all the revisions of the spec file / sources / patches, and can view the commit log with : $ git log As an alternative, you can use gitweb: http://pkgs.fedoraproject.org/gitweb/?p=kernel.git Or git clone git://pkgs.fedoraproject.org/kernel which doesn't require authentication. Note that the git repository for the kernel package doesn't go back very far because the automatic migration tools didn't work so it started again from the most recent SRPMS. For more historic changes you can go back to CVS, eg. http://cvs.fedoraproject.org/viewvc/devel/kernel/ Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Creating private branches under fedpkg/git
What is the policy on creating private branches under fedpkg/git? Can it be done by anyone with acl commit or do you need special permissions? My interest is that I had a private branch of the kernel package under CVS which I used to build pvops enabled kernels so that the more adventurous could use a Fedora based Domain-0 kernel with xen. However this branch hasn't been copied across (presumably because of the difficulties in transfering the kernel package) though I could easily continue from a new branch if that is appropriate. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F14 mirror list still pointing at rawhide
I was trying a yum update on F-14 (fedora-release-14-0.7) but was offered a few F-15 packages. I checked https://mirrors.fedoraproject.org/metalink?repo=fedora-14arch=x86_64 and the mirrors it points to are all rawhide rather than the F-14 branch. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 branching and dist-git roll out
On Thu, 29 Jul 2010, Stephen Gallagher wrote: Never mind, turns out this was me trying to use fedpkg 0.5.0 against a checkout made for 0.4.2 (against the test environment) Note that fedpkg 0.5.1 is out now. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On Mon, 26 Jul 2010, Tom spot Callaway wrote: You're going to need to include all applicable license texts, sorry. I have commited a spec file that puts all the COPYING and LICENSE files into a new xen-licenses package (I don't what to include that many files twice). I haven't built it yet as I was going to wait a bit to see what is happening with the python 2.7 merge. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On Wed, 7 Jul 2010, Tom spot Callaway wrote: [xen-maint] xen: xen-doc-4.0.0-2.fc14.x86_64 xen-libs-4.0.0-2.fc14.x86_64 xen-hypervisor-4.0.0-2.fc14.x86_64 I am a co-maintainer of the xen package, and I am trying to work out what the best way to comply with these changes since xen is rather a mess of licenses - I count 25 files or symbolic links called COPYING or LICENSE in the unpacked source and the base level COPYING file talks about license conditions at the head of some files. They all seem to be basically GPL, LGPL or BSD with one case of The Artistic License. Should I include all the COPYING or LICENSE files, one of each type of license (though some of the license files have different md5sums even when they claim to be the same license) or just the bottom level COPYING file? Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Seeking new maintainer for iasl
On Thu, 1 Jul 2010, Jon Ciesla wrote: repoquery --repoid=rawhide-source --archlist=src --whatrequires iasl returns nothing. It looks like we may not need it for anything else, though it may have value to developers for other things. For me it finds 3 packages, iasl-0:20090123-3.fc12.src bochs-0:2.4.5-1.fc14.src xen-0:4.0.0-2.fc14.src Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pidgin obsoleting itself
On Wed, 9 Jun 2010, Peter Lemenkov wrote: 2010/6/9 Michael Schwendt mschwe...@gmail.com: Competing Obsoletes once again. The packager is playing with fire. Not in this case. It seems to me that this is using something that happens to work for yum (and maybe not for other utilities, different yum versions, etc. ) rather than a defined feature to handle this situation. So I agree that the packager is playing with fire and there are probably better ways of achieving this result. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Preupgrade F12-F13 error
On Wed, 12 May 2010, Clovis Tristao wrote: How do I increase size the boot partition, with LVM? My partition: FilesystemSize Used Avail Use% Mounted on /dev/sda1 190M 39M 142M 22% /boot LVM won't help you with a physical partition like that. If the disk space immediately following /dev/sda1 is free you can increase the size of /dev/sda1 (eg. using fdisk) and then use resize2fs to increase the size of the file system. If the rest of the disk is LVM and you have enough spare space you can shrink the LVM area used using pvresize, then the partition containing it, use the free space to create a new LVM partition, use pvmove to move your logical volumes over to the new area, delete the original LVM area, and use the freed space to extend /dev/sda1, then perhaps reverse the process so that LVM uses up all the disk not otherwise allocated. Thus it might be possible to increase the size of /dev/sda1 in some circumstances, but it is probably only worth attempting if you are good linux skills. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
duplicate f13 package announcements
I don't know if this has already been raised but I notice on the package-annou...@lists.fedoraproject.org list that several Fedora 13 packages keep getting announced, for example, by checking the archives I see that fedora-release-13-0.6 has been announced 6 times in March and a further 7 times in February. I suspect there is a glitch in the package management system somewhere. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
On Mon, 1 Feb 2010, drago01 wrote: On Mon, Feb 1, 2010 at 9:30 AM, M A Young m.a.yo...@durham.ac.uk wrote: That doesn't work as nicely as perhaps it should because yum downgrade firefox only downgrades firefox and not xulrunner, and as a result the downgraded firefox refuses to run. You need at least yum downgrade firefox xulrunner yum history list yum history undo number That requires you to remember when you did the update, or do more digging to identify the relevant update batch. I presume it will work, but it isn't quite as simple as you imply. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
On Sun, 31 Jan 2010, Wes Shull wrote: On Sun, Jan 31, 2010 at 1:05 AM, Kevin Kofler kevin.kof...@chello.at wrote: Wes Shull wrote: yum --enablerepo=rawhide update firefox NEVER do that!!! If you'd taken half a minute to check, you would have seen that it sucks in a grand total of sqlite and xulrunner. Yeehaw. At the moment it does for you, though more updates may be required depending on what you have installed, but you also have to think longer term, because the latest Fedora release and rawhide will tend to move apart as time goes on, so when the first Fedora 3.6 security update comes along you may find yourself having to download most of rawhide to update it. I wouldn't go as far as saying that you should never install rawhide packages on a Fedora system, but you have to be prepared to cope with the difficulties that might result as time goes on, so I wouldn't recommend it unless you have the skill to cope with such difficulties. Personally I have a couple of Fedora 12 installs that I put the rawhide Firefox 3.6 on, but those are installs that I will probably switch to rawhide at some point anyway. Michael Young-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How about firefox 3.6 in Fedora 12 ?
On Sat, 30 Jan 2010, Wes Shull wrote: On Sat, Jan 30, 2010 at 1:42 AM, Liu Yu Fei Eric hoveringnowi...@gmail.com wrote: So it doesn't have an official one? I've been running the f13 build out of rawhide for a week now, and it's worked fine for me... not sure about Java though. yum --enablerepo=rawhide update firefox It looks like some upstream support in OpenJDK + IcedTea http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-January/008120.html went live 3 days ago, but it doesn't look like there have been any Fedora builds based on it yet. I would suggest a slight word of caution about mixing Fedora 12 and rawhide packages. At the moment they still seem fairly compatible, but if something major changes you might find yourself having to update most of your OS to rawhide to satisfy all the dependencies. Michael Young-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
