Re: update means only runlevel 1
On Fri, Jan 29, 2010 at 3:11 PM, darrell pfeifer wrote: > i did an update this morning that took my machine from current rawhide > to a few koji updates. included were dracut, udev and i memory serves > me right, a minor initscript cleanup. > > now i can't get any farther than runlevell 1. going to even runlevel 3 hangs. > > any suggestions of what might be broken? > > (sorry for the brevity, typing on an inconvenient box) > > darrell > Could this be it: https://bugzilla.redhat.com/show_bug.cgi?id=560031 ? tom -- Tom London -- 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, Aug 25, 2010 at 4:45 PM, M A Young wrote: > 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 > -- This sounds like a previously discussed issue with "upgrading a system to systemd". Referring to Lennart's HEADS UP: Heya, just a little heads up for when you upgrade a rawhide system that is a few weeks old to current rawhide: since we changed the way how some of the default symlinks of systemd are created you will end up with an installation that lacks many of the necessary symlinks -- but only if you upgrade from a systemd version from older rawhide to current rawhide. It's really only a problem in this case. It is not a problem with fresh F14 installations, and it is not a problem with upgrades from F13. The fix is easy: after upgrading just run this command as root and the missing links should be created: # systemctl enable ge...@.service prefdm.service getty.target rc-local.service remote-fs.target And that should make things work again. Sorry for the late heads-up. Lennart Could this fix your boot hang? tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Nautilus misbehaving
On Sun, Aug 29, 2010 at 9:49 AM, Paul F. Johnson wrote: > Hi, > > After the recent rawhide to nautilus 2.90.1-1.fc15.i686, it's stopped > working claiming that I don't have Settings schema > 'org.gnome.desktop.lockdown' installed. > > What is this and how do I fix the problem? > > TTFN > > Paul Not sure about your problem, but here is where that schema comes from: [...@tlondon ~]$ rpm -qif /usr/share/glib-2.0/schemas/org.gnome.desktop.lockdown.gschema.xml Name: gsettings-desktop-schemasRelocations: (not relocatable) Version : 0.0.1 Vendor: Fedora Project Release : 2.fc15Build Date: Tue 24 Aug 2010 01:59:22 PM PDT Install Date: Wed 25 Aug 2010 06:20:01 AM PDT Build Host: x86-03.phx2.fedoraproject.org Group : System Environment/Libraries Source RPM: gsettings-desktop-schemas-0.0.1-2.fc15.src.rpm Size: 49344License: LGPLv2+ Signature : (none) Packager: Fedora Project URL : http://bugzilla.gnome.org/enter_bug.cgi?product=gsettings-desktop-schemas Summary : A collection of GSettings schemas Description : gsettings-desktop-schemas contains a collection of GSettings schemas for settings shared by various components of a desktop. [...@tlondon ~]$ Nautilus appears not to be starting on login for me; I need to start it manually via 'nautilus --no-default-window&'. BZ'ed here: https://bugzilla.redhat.com/show_bug.cgi?id=627639 tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Nautilus still no go in rawhide
On Sat, Sep 25, 2010 at 9:16 AM, Paul F. Johnson wrote: > Hi, > > What is going on with Nautilus? It's not been usable for quite a while > now. Most recently, I've had it working by starting it from a terminal > window but now even that has stopped working and is giving me the > following > > Gtk-Message: Failed to load module "pk-gtk-module": libpk-gtk-module.so: > cannot open shared object file: No such file or directory > Gtk-Message: Failed to load module "gail-gnome": libgail-gnome.so: > cannot open shared object file: No such file or directory > > (nautilus:11408): GLib-GObject-WARNING **: gsignal.c:1152: unable to > lookup signal "select" of unloaded type `GtkMenuItem' > > (nautilus:11408): GLib-GObject-CRITICAL **: g_signal_add_emission_hook: > assertion `signal_id > 0' failed > > (nautilus:11408): GLib-GObject-WARNING **: gsignal.c:1152: unable to > lookup signal "deselect" of unloaded type `GtkMenuItem' > > (nautilus:11408): GLib-GObject-CRITICAL **: g_signal_add_emission_hook: > assertion `signal_id > 0' failed > Initializing nautilus-gdu extension > > (nautilus:11408): GLib-GObject-CRITICAL **: g_object_ref: assertion > `G_IS_OBJECT (object)' failed > Segmentation fault (core dumped) > > (this is the same if I use nautilus -n [then double click on a drive > icon] or nautilus with no arguments) > > Any ideas on what is going on? > > I last updated the machine last night and things seem to have gone wrong > since about Tuesday (last update on koji). > > I did think it was related to the gir rebuilds, but that doesn't seem to > be the case. > > HELP > > TTFN > > Paul > > P.S. I have both .so files installed... > -- > Vertraue mir, ich weiss, was ich mache... > I've been running rawhide nautilus for a while (currently nautilus-2.90.1-4.gitf3bbee7.fc15.x86_64), and although there are some 'rough edges', it works well enough for me. Here are some things I've noticed: 1. Nautilus no longer displays the desktop; believe I got some indication that this was part of the move to a newer desktop 2. Nautilus no longer 'auto mounts' removable drives (e.g., thumb drives, hard drives, etc.). However, the device does appear in 'Places', and it mounts if you select it there. 3. Nautilus segfaults trying to open the device's root folder after selecting in 'Places': https://bugzilla.redhat.com/show_bug.cgi?id=636543 . But the device is mounted properly tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Nautilus still no go in rawhide
On Sat, Sep 25, 2010 at 11:19 AM, Owen Taylor wrote: > On Sat, 2010-09-25 at 09:31 -0700, Tom London wrote: >> 1. Nautilus no longer displays the desktop; believe I got some >> indication that this was part of the move to a newer desktop > > Since you aren't actually running the newer desktop (GNOME Shell is > temporarily not working in Rawhide, we'll get it fixed this week, and > the file management isn't fully there yet in any case), you can showing > the desktop back on with: > > gconftool -s -t bool /apps/nautilus/preferences/show_desktop true > > Of course, that once you've set that key you'll no longer get the > default experience. > > (See: > > http://mail.gnome.org/archives/desktop-devel-list/2010-September/msg00033.html > > for some discussion of the desktop situation) > >> 2. Nautilus no longer 'auto mounts' removable drives (e.g., thumb >> drives, hard drives, etc.). However, the device does appear in >> 'Places', and it mounts if you select it there. > > This is a fairly long-standing bug related to turning off "show_desktop" > - the automounting is part of the Nautilus process, and when not showing > the desktop, Nautilus just exits when there are no windows. > > See: https://bugzilla.gnome.org/show_bug.cgi?id=585545 > > - Owen > Thanks for the update Think I'll wait for the newer gnome-shell. I sort of got hooked on the compiz eye-candy. Any idea if that (e.g., wobbly windows, rotating cube, ...) will be part of the "new gnome-shell experience"? tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Nautilus still no go in rawhide
On Sat, Sep 25, 2010 at 8:21 PM, darrell pfeifer wrote: > > > On Sat, Sep 25, 2010 at 11:55, Owen Taylor wrote: >> >> On Sat, 2010-09-25 at 14:04 -0400, Owen Taylor wrote: >> >> > > (nautilus:11408): GLib-GObject-CRITICAL **: g_object_ref: assertion >> > > `G_IS_OBJECT (object)' failed >> > > Segmentation fault (core dumped) >> > >> > There also seem to be problems with nautilus from GTK+ ABI changes - I >> > see various warnings along the lines of: >> > >> > (nautilus:27082): GLib-GObject-WARNING **: specified class size for type >> > `EvPropertiesView' is smaller than the parent type's `GtkVBox' class >> > size >> > >> > These indicate a definite need for rebuild, so I'll kick one off now, >> > and maybe things will be better after that finishes. It's certainly not >> > worth worrying about anything related to Nautilus until it's rebuild. >> > > The newer version still dies. It seemed to work for a while but segfaults > again. Also, sftp doesn't work any more. > Interestingly enough, it doesn't segfault under KDE. > darrell > -- Does this sound like your segfaults: https://bugzilla.redhat.com/show_bug.cgi?id=636543 I'm guessing that is some change in the gtk3 interface... tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Nautilus still no go in rawhide
On Sun, Sep 26, 2010 at 9:45 AM, darrell pfeifer wrote: > > > On Sun, Sep 26, 2010 at 09:30, Tom London wrote: >> >> On Sat, Sep 25, 2010 at 8:21 PM, darrell pfeifer >> wrote: >> > >> > >> > On Sat, Sep 25, 2010 at 11:55, Owen Taylor wrote: >> >> >> >> On Sat, 2010-09-25 at 14:04 -0400, Owen Taylor wrote: >> >> >> >> > > (nautilus:11408): GLib-GObject-CRITICAL **: g_object_ref: assertion >> >> > > `G_IS_OBJECT (object)' failed >> >> > > Segmentation fault (core dumped) >> >> > >> >> > There also seem to be problems with nautilus from GTK+ ABI changes - >> >> > I >> >> > see various warnings along the lines of: >> >> > >> >> > (nautilus:27082): GLib-GObject-WARNING **: specified class size for >> >> > type >> >> > `EvPropertiesView' is smaller than the parent type's `GtkVBox' class >> >> > size >> >> > >> >> > These indicate a definite need for rebuild, so I'll kick one off now, >> >> > and maybe things will be better after that finishes. It's certainly >> >> > not >> >> > worth worrying about anything related to Nautilus until it's rebuild. >> >> >> > >> > The newer version still dies. It seemed to work for a while but >> > segfaults >> > again. Also, sftp doesn't work any more. >> > Interestingly enough, it doesn't segfault under KDE. >> > darrell >> > -- >> >> Does this sound like your segfaults: >> https://bugzilla.redhat.com/show_bug.cgi?id=636543 >> >> I'm guessing that is some change in the gtk3 interface... >> > > I haven't run a stack trace on mine, so I can't be sure. > Your guess might be accurate though. I also notice that chrome has been > segfaulting with annoying frequency which is strange because it has been > very stable for me. > darrell > > -- Interesting. I just locally patched gtk3 (as described here: https://bugzilla.redhat.com/show_bug.cgi?id=636543), and now 'automounting' appears to be working as usual: the nice nautilus window with the device's root directory opens as expected. I'm running: nautilus-2.90.1-5.gitf3bbee7.fc15.x86_64 gtk3-2.90.7-2.local.fc15.x86_64 <--- this is the 'patched' gtk3. I don't know if this is the 'right' patch, but this appears to indicate (at least part of) a problem. tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: One big old problem and one new with Rawhide
On Sat, Jul 16, 2011 at 1:49 PM, Lucas wrote: > One big problem is that my laptop can't go through systemd startup with > selinux enabled. > Boot hangs at random points - setup keyboard, stdio syslog bridge, kernel > variables. Laptop just > hangs, nothing happens and all I can do it turn it off. The only way is to > add "selinux=0". Its usually better to add "enforcing=0" rather than "selinux=0". "enforcing=0" keeps files appropriately labeled. > > > > The second one that raises today - I can't log in at all - nor with root nor > with user. > I reported yesterday about: > > [ 37.654015] [ INFO: possible recursive locking detected ] > [ 37.654015] 3.0-0.rc7.git0.1.fc16.i686 #1 > [ 37.654015] - > [ 37.654015] systemd-logind/651 is trying to acquire lock: > > And yesterday I was able to log into user and root account, today I can't - > it looks like it checks > the password, because it reports if it is wrong, when I type the right one it > hangs again. May be > system can't start console (I was trying to do it in level 3). > > What I can do with it? > Need advice. > Thanks. Not sure, but my Rawhide system is booting to gnome just fine with "enforcing=0". tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: One big old problem and one new with Rawhide
On Sat, Jul 16, 2011 at 2:15 PM, Lucas wrote: > On 07/17/2011 01:03 AM, Tom London wrote: >> On Sat, Jul 16, 2011 at 1:49 PM, Lucas wrote: >>> One big problem is that my laptop can't go through systemd startup with >>> selinux enabled. >>> Boot hangs at random points - setup keyboard, stdio syslog bridge, kernel >>> variables. Laptop just >>> hangs, nothing happens and all I can do it turn it off. The only way is to >>> add "selinux=0". >> >> Its usually better to add "enforcing=0" rather than "selinux=0". >> "enforcing=0" keeps files appropriately labeled. > > "enforcing=0" doesn't help me, system hangs. > I installed XFCE spin and then upgrade it to Rawhide, I do not have gnome > because I hate it. > I turned off enforcing when I start to test it, but selinux doesn't report > anything, may be selinux > can't do its job with new kernels, because system hangs in different points. > -- Sorry, not enough info to help much more Do you have a "stock" system system? Did you try booting with the 'rhgb quiet' options removed and 'debug' added? Any unexpected messages? ... etc.? -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FYI, rawhide makes /usr/bin/install (matchpathcon) segfault
On Wed, Sep 7, 2011 at 6:02 AM, Jim Meyering wrote: > Richard W.M. Jones wrote: >> On Wed, Sep 07, 2011 at 01:44:36PM +0200, Jim Meyering wrote: >>> Jim Meyering wrote: >>> ... >>> > $ touch a && $ env -i /usr/bin/install a b >>> > zsh: segmentation fault env -i /usr/bin/install a b >>> > [Exit 139 (SEGV)] >>> >>> Rich Jones found that updating to libselinux-2.1.5-2.fc17.x86_64 >>> made it so he too sees the above failure. >> >> [...] >> >> Instead of this workaround, can we ask rel-eng to untag the >> broken libselinux update? > > Good idea. > Done: https://fedorahosted.org/rel-eng/ticket/4914 Koji has libselinux-2.1.5-3.fc17.x86_64. Its changelog says: * Tue Sep 06 2011 Dan Walsh - 2.1.5-3 - Fix handling of subset labeling that is causing segfault in restorecon After downloading/installing: "Works for me". tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux kernel 3.0 + SELinux problem
On Wed, Jun 8, 2011 at 3:52 PM, Jerry James wrote: > I'm having some kind of problem with SELinux on the Rawhide 3.0 > kernels. The boot process gets stuck loading the SELinux policy over > and over again. I get a long series of messages like this for a few > minutes: > > [ timestamp] type=1403 audit(various numbers): policy loaded > auid=4294967295 ses=4294967295 > > Then something times out, I think. It always scrolls by too quickly > for me to read it, but it looks like a typical stuck process kernel > backtrace. Then I get some variety, and start seeing an endless > parade of these: > > [ timestamp] type=1403 audit(various numbers): policy loaded > auid=4294967295 ses=4294967295 > [ timestamp] SELinux: 2048 avtab hash slots, 223865 rules. > [ timestamp] SELinux: 2048 avtab hash slots, 223865 rules. > [ timestamp] SELinux: 9 users, 13 roles, 3663 types, 193 bools, 1 > sens, 1024 cats > [ timestamp] SELinux: 81 classes, 223865 rules > > Well, at least I guess it's endless. I've let it go for as long as 10 > minutes in the hope that something else would happen. I've tried both > kernel 3.0-0.rc1.git0.2 and kernel 3.0-0.rc2.git0.1 and have the same > problem with both. I touched /.autorelabel and rebooted with the last > 2.6.39 kernel, but that didn't help. The only way I can boot these > kernels is to use "selinux=0" on the boot line. > > I'm seeing this on 2 virtual machines, one x86_64 and one i686, both > with fully updated Rawhide as of today and (almost) the same set of > packages installed. Both "yum upgrade" and "package-cleanup > --orphans" show nothing to do. On both, after booting with selinux=0, > "systemctl --failed" lists 0 units. Both started life as F-14 > machines, became F-15 Alpha and then F-15 Beta boxes, and were > upgraded to Rawhide after the release of F-15. It's possible some > configuration got screwed up along the way. > > If anyone has a theory about what's going on, I'm all ears. Thanks, > -- > Jerry James > http://www.jamezone.org/ See https://bugzilla.redhat.com/show_bug.cgi?id=711015 Believe updated systemd is building. tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are 3.0 kernels working for anyone?
On Fri, Jun 10, 2011 at 11:19 AM, Bruno Wolff III wrote: > The 3.0 kernels are not working for me. (A cpu lockup is reporting during > boot.) I am wondering if things are broken for everyone where I should > probably just wait for updates and try again, or if I should get a picture > of the traceback and file a bug? > -- "Boots for me" on Thinkpad X200 with SELinux enforcing. gdm-greeter screen is scrambled, but if I blindly enter login/password, gnome comes up just fine. tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are 3.0 kernels working for anyone?
On Fri, Jun 10, 2011 at 11:54 AM, Jerry James wrote: > On Fri, Jun 10, 2011 at 12:19 PM, Bruno Wolff III wrote: >> The 3.0 kernels are not working for me. (A cpu lockup is reporting during >> boot.) I am wondering if things are broken for everyone where I should >> probably just wait for updates and try again, or if I should get a picture >> of the traceback and file a bug? > > I've been using today's x86_64 Rawhide kernel with no problems. I had > to attempt a boot 6 times before I finally got the i686 version off > the ground, though. Twice udev segfaulted during boot, and I got some > kind of lockup (perhaps what you are seeing) on the other 3 attempts. > But the 6th time, it worked great. > > Unlike Tom's experience, the gdm login screen looked fine for me on > both x86_64 and i686. > -- > Jerry James > http://www.jamezone.org/ Didn't mention: exclusively using x86_64 version. tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are 3.0 kernels working for anyone?
On Sat, Jun 11, 2011 at 9:29 AM, Lucas wrote: > > I can only boot if selinux is disabled - "selinux=0" in grub. Otherwise boot > always stops in > different moments. > I can't figured out which problem is this - selinux or systemd? > -- Does this sound like it? https://bugzilla.redhat.com/show_bug.cgi?id=711015 If so, you need a newer systemd. systemd-28-3.fc16.x86_64 "works for me". tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
On Sun, Jun 24, 2012 at 12:57 PM, Jef Spaleta wrote:
> Rawhide target scratch build of the upstream tree with the fix.
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=4191839
>
> I have done a local build and test on an F16 system. Revelation
> informs me that the key file is an old encryption format and requests
> me to resave to update the encryption.
>
> Can someone please do an independent confirmation that this actually
> fixes the underlying issues with the encryption weakness?
>
> There appears to be one potential regression in 0.14.3+ with
> searching...but I think its due to a change in gconf key layout. If
> you experience the search crash...logout/login or shutdown/restart
> and the problem appears to go away. I saw the crash last week on F16
> and F17 while I was doing initial testing for 0.14.3 test packages
> that I rolled ahead of this security fix landing...but I could not
> duplicate the search traceback again after a system restart... making
> it a bit difficult to track down and squash.
>
> AnywaysI'm inclined to wait for the official release tarball to
> land from upstream tomorrow to push update packages into
> rawhide->F17,F16 testing for release 0.14.4 that rolls in the
> encryption changes. In the meantime anyone who is seriously concerned
> about this, please beat on the on the scratch build and make sure its
> actually a fix.
>
> -jef
> --
Haven't checked the crypto changes, but I do notice this spew when I
try 'Edit->Preferences':
Traceback (most recent call last):
File "/usr/bin/revelation", line 206, in
action.connect("activate", lambda w: self.prefs())
File "/usr/bin/revelation", line 1527, in prefs
dialog.run_unique(Preferences, self, self.config)
File "/usr/lib64/python2.7/site-packages/revelation/dialog.py", line
1324, in run_unique
d = create_unique(dialog, *args)
File "/usr/lib64/python2.7/site-packages/revelation/dialog.py", line
1282, in create_unique
UNIQUE_DIALOGS[dialog] = dialog(*args)
File "/usr/bin/revelation", line 1623, in __init__
self.__init_section_password(self.page_general)
File "/usr/bin/revelation", line 1762, in __init_section_password
ui.config_bind(self.config, "passwordgen/punctuation",
self.check_punctuation_chars)
File "/usr/lib64/python2.7/site-packages/revelation/ui.py", line
182, in config_bind
id = cfg.monitor(key, cb_get, widget)
File "/usr/lib64/python2.7/site-packages/revelation/config.py", line
150, in monitor
callback(key, self.get(key), userdata)
File "/usr/lib64/python2.7/site-packages/revelation/config.py", line
129, in get
raise ConfigError
ConfigError
tom
--
Tom London
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
On Sun, Jun 24, 2012 at 2:39 PM, Jef Spaleta wrote:
> On Sun, Jun 24, 2012 at 12:17 PM, Tom London wrote:
>
>> Haven't checked the crypto changes, but I do notice this spew when I
>> try 'Edit->Preferences':
>
> Okay I think I have the GConf scriptlets fixed:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=4191873
>
>
> On local testing.
>
> Install the new scratch build.
> Logout/Login
> run revelation
> open edit/prefs
> No traceback.
>
> Tom can you confirm that the above works for you with the new test package?
>
> I suspect that we'll still get tracebacks unless the logout/login
> happens to restart gconf and have it look for the updated schema. I
> don't know how to have a running gconf "see" the schema updates
> introduced by a package install.
>
>
> -jef
> --
Hmm... Still seeing spew:
Traceback (most recent call last):
File "/usr/bin/revelation", line 206, in
action.connect("activate", lambda w: self.prefs())
File "/usr/bin/revelation", line 1527, in prefs
dialog.run_unique(Preferences, self, self.config)
File "/usr/lib64/python2.7/site-packages/revelation/dialog.py", line
1324, in run_unique
d = create_unique(dialog, *args)
File "/usr/lib64/python2.7/site-packages/revelation/dialog.py", line
1282, in create_unique
UNIQUE_DIALOGS[dialog] = dialog(*args)
File "/usr/bin/revelation", line 1623, in __init__
self.__init_section_password(self.page_general)
File "/usr/bin/revelation", line 1762, in __init_section_password
ui.config_bind(self.config, "passwordgen/punctuation",
self.check_punctuation_chars)
File "/usr/lib64/python2.7/site-packages/revelation/ui.py", line
182, in config_bind
id = cfg.monitor(key, cb_get, widget)
File "/usr/lib64/python2.7/site-packages/revelation/config.py", line
150, in monitor
callback(key, self.get(key), userdata)
File "/usr/lib64/python2.7/site-packages/revelation/config.py", line
129, in get
raise ConfigError
ConfigError
Here is what I did:
1. I 'rpm -Uvh --force' the new package.
2. I 'recovered' my old ~/.gconf/apps/revelation/ settings (I had
saved them by moving them to revelation.old before updating/testing
with the previous test build).
3. I rebooted and started revelation
4. Edit->Preferences
I'm guessing if I nuke the ~/.gconf/apps/revelelation/ dir and
reboot/etc. it will work...
tom
--
Tom London
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
On Mon, Jun 25, 2012 at 9:46 AM, Jef Spaleta wrote: > On Mon, Jun 25, 2012 at 5:36 AM, Tom London wrote: >> Hmm... Still seeing spew: >> Here is what I did: >> >> 1. I 'rpm -Uvh --force' the new package. >> 2. I 'recovered' my old ~/.gconf/apps/revelation/ settings (I had >> saved them by moving them to revelation.old before updating/testing >> with the previous test build). >> 3. I rebooted and started revelation >> 4. Edit->Preferences >> >> I'm guessing if I nuke the ~/.gconf/apps/revelelation/ dir and >> reboot/etc. it will work... > > I'd image the problem in your steps is the fact that you did 2 after 1. > Get your system into the old state with the old 0.4.11 revelation > update to new rpm > logout/log back in. > tracebacks should stop. > > I've tested this on a couple of systems now. > > > -jef > > Oops Sorry for the fumble. Will redo and report tonight. tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
On Mon, Jun 25, 2012 at 11:22 AM, Tom London wrote:
> On Mon, Jun 25, 2012 at 9:46 AM, Jef Spaleta wrote:
>> On Mon, Jun 25, 2012 at 5:36 AM, Tom London wrote:
>>> Hmm... Still seeing spew:
>>> Here is what I did:
>>>
>>> 1. I 'rpm -Uvh --force' the new package.
>>> 2. I 'recovered' my old ~/.gconf/apps/revelation/ settings (I had
>>> saved them by moving them to revelation.old before updating/testing
>>> with the previous test build).
>>> 3. I rebooted and started revelation
>>> 4. Edit->Preferences
>>>
>>> I'm guessing if I nuke the ~/.gconf/apps/revelelation/ dir and
>>> reboot/etc. it will work...
>>
>> I'd image the problem in your steps is the fact that you did 2 after 1.
>> Get your system into the old state with the old 0.4.11 revelation
>> update to new rpm
>> logout/log back in.
>> tracebacks should stop.
>>
>> I've tested this on a couple of systems now.
>>
>>
>> -jef
>>
>>
>
> Oops Sorry for the fumble.
>
> Will redo and report tonight.
>
> tom
> --
> Tom London
Must be something 'interesting' about my conf files This still fails for me:
Traceback (most recent call last):
File "/usr/bin/revelation", line 206, in
action.connect("activate", lambda w: self.prefs())
File "/usr/bin/revelation", line 1527, in prefs
dialog.run_unique(Preferences, self, self.config)
File "/usr/lib64/python2.7/site-packages/revelation/dialog.py", line
1324, in run_unique
d = create_unique(dialog, *args)
File "/usr/lib64/python2.7/site-packages/revelation/dialog.py", line
1282, in create_unique
UNIQUE_DIALOGS[dialog] = dialog(*args)
File "/usr/bin/revelation", line 1623, in __init__
self.__init_section_password(self.page_general)
File "/usr/bin/revelation", line 1762, in __init_section_password
ui.config_bind(self.config, "passwordgen/punctuation",
self.check_punctuation_chars)
File "/usr/lib64/python2.7/site-packages/revelation/ui.py", line
182, in config_bind
id = cfg.monitor(key, cb_get, widget)
File "/usr/lib64/python2.7/site-packages/revelation/config.py", line
150, in monitor
callback(key, self.get(key), userdata)
File "/usr/lib64/python2.7/site-packages/revelation/config.py", line
129, in get
raise ConfigError
ConfigError
I copied my 'old' conf files from a backup, reinstalled via 'rpm -Uvh
--force', rebooted, and started revelation.
Something useful I can do? (or just blow the conf dir away?)
tom
--
Tom London
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dracut-20-51 - Heads up
On Mon, Jul 9, 2012 at 3:09 AM, Harald Hoyer wrote: > Am 09.07.2012 09:44, schrieb Harald Hoyer: > > Do not install dracut-020-51! > > > > Sorry for those, who have been bitten by dracut-020-51. Instead of > installing to > > the /var/tmp/initramfs.* directory, it installed in your real root. > > > > To remove most (if not all) of the files, it has installed, do the > following: > > > > # rm /.bash_history > > # rm /dracut-state.sh > > # rm /lib/dracut-crypt-lib.sh /lib/dracut-lib.sh /lib/dracut/modules.txt > > # rm -r /lib/dracut/hooks > > # rm /sbin/btrfs_finished /sbin/btrfs_timeout /sbin/cryptroot-ask > > # rm /sbin/initqueue /sbin/insmodpost.sh /sbin/iscsiroot /sbin/loginit > > # rm /sbin/lvm_scan > > # rm /sbin/mdraid-cleanup /sbin/mdraid_start /sbin/nbdroot /sbin/netroot > > # rm /sbin/nfsroot /sbin/probe-keydev /bin/dracut-cmdline > /bin/dracut-initqueue > > # rm /bin/dracut-pre-pivot /bin/dracut-pre-trigger /bin/dracut-pre-udev > > # rm /bin/mount-hook /bin/mount-lun.sh > > # rm /lib/fs-lib.sh /lib/net-lib.sh /lib/nfs-lib.sh > > # rm /etc/initrd-release > > # rm /lib/systemd/system/dracut* > > # rm /lib/systemd/system/*/dracut* > > # rm /lib/systemd/system/default.target > > # rm /lib/systemd/system/initrd-switch-root.service > > # rm -r /lib/systemd/system/initrd-switch-root.target > > # vi /etc/fstab .. remove all /sysroot lines > > # mkdir /tmp/dracut-fixup; ( cd /tmp/dracut-fixup; yumdownloader setup; > \ > > rpm2cpio setup*.rpm | cpio -id ; cp etc/profile /etc ); \ > > rm -fr /tmp/dracut-fixup > > # mkdir /tmp/dracut-fixup; ( cd /tmp/dracut-fixup; \ > > yumdownloader --archlist=$(arch) systemd; \ > > rpm2cpio systemd*.$(arch).rpm | cpio -id ; \ > > cp usr/lib/systemd/system/emergency.service /usr/lib/systemd/system; \ > > cp usr/lib/systemd/system/rescue.service /usr/lib/systemd/system; ); \ > > rm -fr /tmp/dracut-fixup > > # for i in 10-console.rules 10-dm.rules 11-dm.rules 13-dm-disk.rules \ > > 40-multipath.rules 50-firmware.rules 50-udev-default.rules > 50-udev.rules \ > > 59-persistent-storage.rules 60-cdrom_id.rules 60-pcmcia.rules \ > > 60-persistent-storage.rules 61-dmraid-imsm.rules \ > > 61-persistent-storage-edd.rules 61-persistent-storage.rules \ > > 64-device-mapper.rules 64-lvm.rules 64-md-raid.rules \ > > 65-md-incremental-imsm.rules 71-biosdevname.rules \ > > 80-btrfs.rules 80-drivers.rules 95-dm-notify.rules 95-late.rules \ > > 95-udev-late.rules ; do [[ -f $i ]] && rm -vf /etc/udev/rules.d/$i; > done > > > > # rm -f /etc/os-release; mkdir /tmp/dracut-fixup; \ > ( cd /tmp/dracut-fixup; yumdownloader fedora-release; \ >rpm2cpio fedora-release*.rpm | cpio -id ; cp etc/os-release /etc ); \ >rm -fr /tmp/dracut-fixup > > > > -- > Works for me, thanks! Booted up kernel-3.5.0-0.rc3.git0.2.fc18.x86_64. tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
fuse, /dev/fuse, systemd, ... ?
For the past week or two, I've noticed that cryptkeeper is not starting when Gnome starts up on my "fully Rawhide" system. Noticed that /dev/fuse is not set for user access, fuse module has not been loaded, etc. This by design (i.e., migrating udev to ..., etc.)? Here is what I am seeing: [root@tlondon ~]# ls -l /dev/fuse crw---. 1 root root 10, 229 Aug 3 09:48 /dev/fuse [root@tlondon ~]# lsmod | grep fuse [root@tlondon ~]# [root@tlondon ~]# systemctl status sys-fs-fuse-connections.mount sys-fs-fuse-connections.mount - FUSE Control File System Loaded: loaded (/usr/lib/systemd/system/sys-fs-fuse-connections.mount; static) Active: inactive (dead) start condition failed at Sat 2013-08-03 09:48:28 PDT; 2h 37min ago Where: /sys/fs/fuse/connections What: fusectl Docs: https://www.kernel.org/doc/Documentation/filesystems/fuse.txt http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems [root@tlondon ~]# [root@tlondon ~]# ls -l /sys/fs/fuse/connections ls: cannot access /sys/fs/fuse/connections: No such file or directory [root@tlondon ~]# [root@tlondon ~]# systmctl status systemd-modules-load.service bin-bash: systmctl: command not found [root@tlondon ~]# systemctl status systemd-modules-load.service systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static) Active: inactive (dead) start condition failed at Sat 2013-08-03 09:48:27 PDT; 2h 38min ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) [root@tlondon ~]# systemctl status systemd-readahead-collect.service systemd-readahead-collect.service - Collect Read-Ahead Data Loaded: loaded (/usr/lib/systemd/system/systemd-readahead-collect.service; enabled) Active: active (exited) since Sat 2013-08-03 09:48:27 PDT; 2h 39min ago Docs: man:systemd-readahead-replay.service(8) Main PID: 279 (code=exited, status=0/SUCCESS) Status: "Collecting readahead data" [root@tlondon ~]# systemctl status systemd-readahead-replay.service systemd-readahead-replay.service - Replay Read-Ahead Data Loaded: loaded (/usr/lib/systemd/system/systemd-readahead-replay.service; enabled) Active: active (exited) since Sat 2013-08-03 09:48:27 PDT; 2h 39min ago Docs: man:systemd-readahead-replay.service(8) Main PID: 278 (code=exited, status=0/SUCCESS) Status: "Replaying readahead data" [root@tlondon ~]# ls -l /lib/modules-load.d /usr/lib/modules-load.d /usr/local/lib/modules-load.d /etc/modules-load.d /run/modules-load.d ls: cannot access /usr/local/lib/modules-load.d: No such file or directory ls: cannot access /run/modules-load.d: No such file or directory /etc/modules-load.d: total 0 /lib/modules-load.d: total 0 /usr/lib/modules-load.d: total 0 [root@tlondon ~]# [root@tlondon ~]# cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.11.0-0.rc3.git2.2.fc20.x86_64 root=/dev/mapper/vg_tlondon-lv_root ro LANG=en_US.UTF-8 [root@tlondon ~]# Something to BZ or all part of the plan tom -- Tom London -- 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: Fwd: [ANNOUNCE] xf86-video-intel 2.20.16
On Sat, Dec 15, 2012 at 11:54 AM, Ilyes Gouta wrote: > Hi Adam, > > On Sat, Dec 15, 2012 at 8:35 PM, Adam Williamson > wrote: >> >> On Sat, 2012-12-15 at 12:23 +0100, Ilyes Gouta wrote: >> > Hi, >> > >> > >> > Would it be possible to pull in and package xorg-x11-drv-intel driver >> > updates more frequently in Fedora? >> > >> > >> > These are kinda critical for the stability of desktop/X. >> >> It sucks if you use an 830 or 845, sure, but that's not many people any >> more. > > > Nah, I have a GM45, and this particular update breaks the desktop and video > acceleration (overlay) on my machine. > >> >> >> This update is an exception, but xorg-x11-drv package updates are >> usually fairly dull and not worth caring much about these days. I don't >> think you can use this update as a typical example of an xorg-x11-drv >> update. I'm sure ajax is considering whether this one is appropriate as >> an update. > > > Let's just move to the latest xf86-video-intel 2.20.16 update. I'll be > filing a bugzilla w/ the GPU lockup report. > > -Ilyes > >> >> >> -- >> Adam Williamson >> Fedora QA Community Monkey >> IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora >> http://www.happyassassin.net >> Believe there are already a few BZs for GPU lockup: https://bugzilla.redhat.com/show_bug.cgi?id=877461 https://bugzilla.redhat.com/show_bug.cgi?id=869354 https://bugzilla.redhat.com/show_bug.cgi?id=879823 tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [ANNOUNCE] xf86-video-intel 2.20.16
On Sun, Dec 16, 2012 at 1:56 AM, Ilyes Gouta wrote: > > and performance (blt and blending, cairo-demos) is way better than the > 2.20.10 and 2.20.14 releases. > > -Ilyes > > > On Sun, Dec 16, 2012 at 10:47 AM, Ilyes Gouta wrote: >> >> Hi, >> >> Just testing the 2.20.16 release and everything looks good so far on GM45. >> >> -Ilyes >> >> >> On Sun, Dec 16, 2012 at 2:28 AM, Sérgio Basto wrote: >>> >>> On Dom, 2012-12-16 at 01:10 +0200, Ebru Arslan wrote: >>> > I am using 32 bit Fedora 14 . our platform is Adlink cPCI-3970D and >>> > this platform using Intel HD 3000 i915 graphic. >>> > I install Base video mode. after that i dont achieve install intel >>> > driver. >>> > i need installation steps of xf86-video-intel 2.20.16 . libdrm >>> > version,X-server version, etc. also create problem when i >>> > make ./configure >>> > but i already updated Fedora 14 . >>> >>> When I want update packages I do custom rpms, and recently use mock (*) >>> to build the packages. >>> >>> #cd fedora-scm/ >>> #git clone git://pkgs.fedoraproject.org/xorg-x11-drv-intel.git >>> #cd xorg-x11-drv-intel/ >>> edit xorg-x11-drv-intel.spec >>> change version to Version: 2.20.16 >>> >>> fedpkg mockbuild --root fedora-18-x86_64 (or fedora-14-x86_64) >>> >>> fedpkg mockbuild --root fedora-18-i386 (or fedora-14-i386) >>> >>> and finally >>> rpm -Uvh the build rpms >>> >>> if not have mock and fedpkg in F14 you could try >>> >>> rpmbuild -ba xorg-x11-drv-intel.spec ... >>> >>> (*) my notes to use mock >>> http://www.serjux.com/alps/how_to_use_mock.txt >>> >>> > On Sun, Dec 16, 2012 at 1:06 AM, Ilyes Gouta >>> > wrote: >>> > Hi Adam, >>> > >>> > On Dec 15, 2012 9:48 PM, "Adam Williamson" >>> > wrote: >>> > > >>> > > On Sat, 2012-12-15 at 20:54 +0100, Ilyes Gouta wrote: >>> > > > Hi Adam, >>> > > > >>> > > > On Sat, Dec 15, 2012 at 8:35 PM, Adam Williamson >>> > >>> > > > wrote: >>> > > > On Sat, 2012-12-15 at 12:23 +0100, Ilyes Gouta >>> > wrote: >>> > > > > Hi, >>> > > > > >>> > > > > >>> > > > > Would it be possible to pull in and package >>> > > > xorg-x11-drv-intel driver >>> > > > > updates more frequently in Fedora? >>> > > > > >>> > > > > >>> > > > > These are kinda critical for the stability of >>> > desktop/X. >>> > > > >>> > > > >>> > > > It sucks if you use an 830 or 845, sure, but >>> > that's not many >>> > > > people any >>> > > > more. >>> > > > >>> > > > >>> > > > Nah, I have a GM45, and this particular update breaks the >>> > desktop and >>> > > > video acceleration (overlay) on my machine. >>> > > >>> > > > Let's just move to the latest xf86-video-intel 2.20.16 >>> > update. I'll be >>> > > > filing a bugzilla w/ the GPU lockup report. >>> > > >>> > > I'm confused. If this update breaks your system, why would >>> > you want us >>> > > to move to it? >>> > >>> > No, the 2.20.14 which is in updates-testing isn't stable. From >>> > the changelog, the 2.20.16 looks like it has fixes for the >>> > issues reported for GM45. >>> > >>> > -Ilyes >>> > >>> > > -- >>> > > Adam Williamson >>> > > Fedora QA Community Monkey >>> > > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora >>> > > http://www.happyassassin.net >>> > > >>> > > -- >>> > > devel mailing list >>> > > devel@lists.fedoraproject.org >>> > > https://admin.fedoraproject.org/mailman/listinfo/devel >>> > >>> > >>> > -- >>> > devel mailing list >>> > devel@lists.fedoraproject.org >>> > https://admin.fedoraproject.org/mailman/listinfo/devel >>> > >>> >>> -- >>> Sérgio M. B. >>> >>> -- I concur: I locally build xorg-x11-drv-intel (including xf86-video-intel-2.20.16.tar.bz2), updated, and logged out/in. System does appear snappier, and I have not yet been able to recreate the hang/crash. tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [ANNOUNCE] xf86-video-intel 2.20.16
On Sun, Dec 16, 2012 at 12:39 PM, Tom London wrote: > On Sun, Dec 16, 2012 at 1:56 AM, Ilyes Gouta wrote: >> >> and performance (blt and blending, cairo-demos) is way better than the >> 2.20.10 and 2.20.14 releases. >> >> -Ilyes >> >> >> On Sun, Dec 16, 2012 at 10:47 AM, Ilyes Gouta wrote: >>> >>> Hi, >>> >>> Just testing the 2.20.16 release and everything looks good so far on GM45. >>> >>> -Ilyes >>> >>> >>> On Sun, Dec 16, 2012 at 2:28 AM, Sérgio Basto wrote: >>>> >>>> On Dom, 2012-12-16 at 01:10 +0200, Ebru Arslan wrote: >>>> > I am using 32 bit Fedora 14 . our platform is Adlink cPCI-3970D and >>>> > this platform using Intel HD 3000 i915 graphic. >>>> > I install Base video mode. after that i dont achieve install intel >>>> > driver. >>>> > i need installation steps of xf86-video-intel 2.20.16 . libdrm >>>> > version,X-server version, etc. also create problem when i >>>> > make ./configure >>>> > but i already updated Fedora 14 . >>>> >>>> When I want update packages I do custom rpms, and recently use mock (*) >>>> to build the packages. >>>> >>>> #cd fedora-scm/ >>>> #git clone git://pkgs.fedoraproject.org/xorg-x11-drv-intel.git >>>> #cd xorg-x11-drv-intel/ >>>> edit xorg-x11-drv-intel.spec >>>> change version to Version: 2.20.16 >>>> >>>> fedpkg mockbuild --root fedora-18-x86_64 (or fedora-14-x86_64) >>>> >>>> fedpkg mockbuild --root fedora-18-i386 (or fedora-14-i386) >>>> >>>> and finally >>>> rpm -Uvh the build rpms >>>> >>>> if not have mock and fedpkg in F14 you could try >>>> >>>> rpmbuild -ba xorg-x11-drv-intel.spec ... >>>> >>>> (*) my notes to use mock >>>> http://www.serjux.com/alps/how_to_use_mock.txt >>>> >>>> > On Sun, Dec 16, 2012 at 1:06 AM, Ilyes Gouta >>>> > wrote: >>>> > Hi Adam, >>>> > >>>> > On Dec 15, 2012 9:48 PM, "Adam Williamson" >>>> > wrote: >>>> > > >>>> > > On Sat, 2012-12-15 at 20:54 +0100, Ilyes Gouta wrote: >>>> > > > Hi Adam, >>>> > > > >>>> > > > On Sat, Dec 15, 2012 at 8:35 PM, Adam Williamson >>>> > >>>> > > > wrote: >>>> > > > On Sat, 2012-12-15 at 12:23 +0100, Ilyes Gouta >>>> > wrote: >>>> > > > > Hi, >>>> > > > > >>>> > > > > >>>> > > > > Would it be possible to pull in and package >>>> > > > xorg-x11-drv-intel driver >>>> > > > > updates more frequently in Fedora? >>>> > > > > >>>> > > > > >>>> > > > > These are kinda critical for the stability of >>>> > desktop/X. >>>> > > > >>>> > > > >>>> > > > It sucks if you use an 830 or 845, sure, but >>>> > that's not many >>>> > > > people any >>>> > > > more. >>>> > > > >>>> > > > >>>> > > > Nah, I have a GM45, and this particular update breaks the >>>> > desktop and >>>> > > > video acceleration (overlay) on my machine. >>>> > > >>>> > > > Let's just move to the latest xf86-video-intel 2.20.16 >>>> > update. I'll be >>>> > > > filing a bugzilla w/ the GPU lockup report. >>>> > > >>>> > > I'm confused. If this update breaks your system, why would >>>> > you want us >>>> > > to move to it? >>>> > >>>> > No, the 2.20.14 which is in updates-testing isn't stable. From >>>> > the changelog, the 2.20.16 looks like it has fixes for the >>>> > issues reported for GM45. >>>> > >>>> > -Ilyes >>>> > >>>> > > -- >>>> > > Adam Williamson >>>> > > Fedora QA Community Monkey >>>> > > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora >>>> > > http://www.happyassassin.net >>>> > > >>>> > > -- >>>> > > devel mailing list >>>> > > devel@lists.fedoraproject.org >>>> > > https://admin.fedoraproject.org/mailman/listinfo/devel >>>> > >>>> > >>>> > -- >>>> > devel mailing list >>>> > devel@lists.fedoraproject.org >>>> > https://admin.fedoraproject.org/mailman/listinfo/devel >>>> > >>>> >>>> -- >>>> Sérgio M. B. >>>> >>>> -- > > I concur: I locally build xorg-x11-drv-intel (including > xf86-video-intel-2.20.16.tar.bz2), updated, and logged out/in. > > System does appear snappier, and I have not yet been able to recreate > the hang/crash. > Sigh. Spoke too soon. Hang resurfaced. See: https://bugzilla.redhat.com/show_bug.cgi?id=877461 tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [ANNOUNCE] xf86-video-intel 2.20.16
On Mon, Dec 17, 2012 at 12:20 AM, Ilyes Gouta wrote: > Hi, > > On Mon, Dec 17, 2012 at 12:27 AM, Tom London wrote: >> >> >> > >> > I concur: I locally build xorg-x11-drv-intel (including >> > xf86-video-intel-2.20.16.tar.bz2), updated, and logged out/in. >> > >> > System does appear snappier, and I have not yet been able to recreate >> > the hang/crash. >> > >> >> Sigh. Spoke too soon. Hang resurfaced. See: >> https://bugzilla.redhat.com/show_bug.cgi?id=877461 > > > It still worth the update, IMHO. The 2.20.16 is just way better than the > 2.20.10. > > As the gdm crash is still there, despite the 2.20.16 being the latest > release, it might make sense to report the bug (with all the relevant > information) directly on https://bugs.freedesktop.org/ > > -Ilyes > I agree. System actually is running much better with the update to 2.20.16: The entire system feels snappier. I've updated my "grab the error state script" to also grab /var/log/Xorg.0.log and the gdm logs. When I capture these again, I'll report upstream tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Donate 1 minute of your time to test upgrades from F29 to F30
on3.7dist(pycodestyle) < 2.5.0, but none of the providers can be > installed > - problem with installed package python3-flake8-3.5.0-6.fc29.noarch > - python3-pycodestyle-2.4.0-3.fc29.noarch does not belong to a > distupgrade > repository > - python3-flake8-3.5.0-6.fc29.noarch does not belong to a distupgrade > repository > Problem 9: package dbus-common-1:1.12.12-2.fc30.noarch conflicts with > fedora-release < 30-0.2 provided by fedora-release-29-7.noarch > - package rpmfusion-free-release-29-1.noarch requires > system-release(29), > but none of the providers can be installed > - problem with installed package dbus-common-1:1.12.12-1.fc29.noarch > - package fedy-plugins-4.0.5-1.fc22.noarch requires rpmfusion-free- > release, but none of the providers can be installed > - dbus-common-1:1.12.12-1.fc29.noarch does not belong to a distupgrade > repository > - problem with installed package fedy-plugins-4.0.5-1.fc22.noarch > Problem 10: package dnf-yum-4.1.0-1.fc30.noarch conflicts with yum > provided > by yum-3.4.3-521.fc30.noarch > - package yumex-3.0.17-2.fc23.noarch requires yum >= 3.2.23, but none of > the providers can be installed > - problem with installed package dnf-yum-4.1.0-1.fc29.noarch > - yum-3.4.3-518.fc29.noarch does not belong to a distupgrade repository > - dnf-yum-4.1.0-1.fc29.noarch does not belong to a distupgrade repository > - problem with installed package yumex-3.0.17-2.fc23.noarch > Problem 11: package rpmfusion-free-release-29-1.noarch requires system- > release(29), but none of the providers can be installed > - package dbus-daemon-1:1.12.12-2.fc30.x86_64 conflicts with fedora- > release < 30-0.2 provided by fedora-release-29-7.noarch > - package fedy-plugins-4.0.5-1.fc22.noarch requires rpmfusion-free- > release, but none of the providers can be installed > - problem with installed package dbus-daemon-1:1.12.12-1.fc29.x86_64 > - package fedy-4.0.5-1.fc22.noarch requires fedy-plugins, but none of > the > providers can be installed > - dbus-daemon-1:1.12.12-1.fc29.x86_64 does not belong to a distupgrade > repository > - problem with installed package fedy-4.0.5-1.fc22.noarch > (try to add '--allowerasing' to command line to replace conflicting > packages > or '--skip-broken' to skip uninstallable packages) > ___ > 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 > -- Tom London ___ 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: Donate 1 minute of your time to test upgrades from F38 to F39
On Thu, Aug 24, 2023 at 3:39 AM Nicola Sella wrote: > Thanks Mirek, > > dnf --releasever=39 --setopt=module_platform_id=platform:f39 \ >> --enablerepo=updates-testing \ >> $(rpm -q fedora-repos-modular >/dev/null && echo >> --enablerepo=updates-testing-modular) \ >> --assumeno distro-sync >> > Allow me to steal some testing. :) > I would like to point out that running the same command, replacing dnf > with dnf5, should work and produce the same transaction. > I suggest running both commands and report eventual errors. This would be > of great help for the dnf team to implement/debug distro-upgrade commands. > > I am getting no errors in the transaction and have the same package list > with both package managers. > > Thanks, > > > > I get this with dnf5: Problem 1: package python3-slip-0.6.4-29.fc38.noarch requires python(abi) = 3.11, but none of the providers can be installed - cannot install both python3-3.11.4-1.fc38.x86_64 and python3-3.12.0~rc1-1.fc39.x86_64 - cannot install the best update candidate for package python3-slip-0.6.4-29.fc38.noarch - cannot install the best update candidate for package python3-3.11.4-1.fc38.x86_64 Problem 2: package python3-3.11.4-1.fc38.x86_64 requires python3-libs(x86-64) = 3.11.4-1.fc38, but none of the providers can be installed - package python3-slip-dbus-0.6.4-29.fc38.noarch requires python(abi) = 3.11, but none of the providers can be installed - cannot install both python3-libs-3.11.4-1.fc38.x86_64 and python3-libs-3.12.0~rc1-1.fc39.x86_64 - cannot install the best update candidate for package python3-slip-dbus-0.6.4-29.fc38.noarch - cannot install the best update candidate for package python3-libs-3.11.4-1.fc38.x86_64 Problem 3: package ibus-1.5.29~rc1-2.fc39.x86_64 requires python(abi) = 3.12, but none of the providers can be installed - python3-3.12.0~rc1-1.fc39.i686 has inferior architecture - cannot install both python3-3.11.4-1.fc38.x86_64 and python3-3.12.0~rc1-1.fc39.x86_64 - problem with installed package - package python3-slip-dbus-0.6.4-29.fc38.noarch requires python(abi) = 3.11, but none of the providers can be installed - cannot install the best update candidate for package ibus-1.5.28-6.fc38.x86_64 Problem 4: package vtk-9.2.6-6.fc39.x86_64 requires libpython3.12.so.1.0()(64bit), but none of the providers can be installed - cannot install both python3-libs-3.11.4-1.fc38.x86_64 and python3-libs-3.12.0~rc1-1.fc39.x86_64 - package python3-3.11.4-1.fc38.x86_64 requires python3-libs(x86-64) = 3.11.4-1.fc38, but none of the providers can be installed - problem with installed package - package python3-slip-0.6.4-29.fc38.noarch requires python(abi) = 3.11, but none of the providers can be installed - cannot install the best update candidate for package vtk-9.2.5-2.fc38.x86_64 and this with dnf: Problem 1: package python3-slip-0.6.4-29.fc38.noarch requires python(abi) = 3.11, but none of the providers can be installed - cannot install both python3-3.11.4-1.fc38.x86_64 and python3-3.12.0~rc1-1.fc39.x86_64 - cannot install the best update candidate for package python3-slip-0.6.4-29.fc38.noarch - cannot install the best update candidate for package python3-3.11.4-1.fc38.x86_64 Problem 2: package python3-3.11.4-1.fc38.x86_64 requires python3-libs(x86-64) = 3.11.4-1.fc38, but none of the providers can be installed - package python3-slip-dbus-0.6.4-29.fc38.noarch requires python(abi) = 3.11, but none of the providers can be installed - cannot install both python3-libs-3.11.4-1.fc38.x86_64 and python3-libs-3.12.0~rc1-1.fc39.x86_64 - cannot install the best update candidate for package python3-slip-dbus-0.6.4-29.fc38.noarch - cannot install the best update candidate for package python3-libs-3.11.4-1.fc38.x86_64 Problem 3: package torbrowser-launcher-0.3.6-6.fc39.noarch requires python(abi) = 3.12, but none of the providers can be installed - python3-3.12.0~rc1-1.fc39.i686 has inferior architecture - cannot install both python3-3.11.4-1.fc38.x86_64 and python3-3.12.0~rc1-1.fc39.x86_64 - problem with installed package - package python3-slip-dbus-0.6.4-29.fc38.noarch requires python(abi) = 3.11, but none of the providers can be installed - cannot install the best update candidate for package torbrowser-launcher-0.3.6-3.fc38.noarch Problem 4: package vtk-9.2.6-6.fc39.x86_64 requires libpython3.12.so.1.0()(64bit), but none of the providers can be installed - cannot install both python3-libs-3.11.4-1.fc38.x86_64 and python3-libs-3.12.0~rc1-1.fc39.x86_64 - package python3-3.11.4-1.fc38.x86_64 requires python3-libs(x86-64) = 3.11.4-1.fc38, but none of the providers can be installed - problem with installed package - package python3-slip-0.6.4-29.fc38.noarch requires python(abi) = 3.11, but none of the providers can be installed - cannot install the best update candidate for
Re: Donate 1 minute of your time to test upgrades from F38 to F39
BTW, after removing python3-slip, python3-slip-dbus and python3-decorator, both dnf5 and dnf produce no errors On Thu, Aug 24, 2023 at 6:35 AM Tom London wrote: > > > On Thu, Aug 24, 2023 at 3:39 AM Nicola Sella wrote: > >> Thanks Mirek, >> >> dnf --releasever=39 --setopt=module_platform_id=platform:f39 \ >>> --enablerepo=updates-testing \ >>> $(rpm -q fedora-repos-modular >/dev/null && echo >>> --enablerepo=updates-testing-modular) \ >>> --assumeno distro-sync >>> >> Allow me to steal some testing. :) >> I would like to point out that running the same command, replacing dnf >> with dnf5, should work and produce the same transaction. >> I suggest running both commands and report eventual errors. This would be >> of great help for the dnf team to implement/debug distro-upgrade commands. >> >> I am getting no errors in the transaction and have the same package list >> with both package managers. >> >> Thanks, >> >> >> >> I get this with dnf5: > > Problem 1: package python3-slip-0.6.4-29.fc38.noarch requires python(abi) > = 3.11, but none of the providers can be installed > - cannot install both python3-3.11.4-1.fc38.x86_64 and > python3-3.12.0~rc1-1.fc39.x86_64 > - cannot install the best update candidate for package > python3-slip-0.6.4-29.fc38.noarch > - cannot install the best update candidate for package > python3-3.11.4-1.fc38.x86_64 > Problem 2: package python3-3.11.4-1.fc38.x86_64 requires > python3-libs(x86-64) = 3.11.4-1.fc38, but none of the providers can be > installed > - package python3-slip-dbus-0.6.4-29.fc38.noarch requires python(abi) = > 3.11, but none of the providers can be installed > - cannot install both python3-libs-3.11.4-1.fc38.x86_64 and > python3-libs-3.12.0~rc1-1.fc39.x86_64 > - cannot install the best update candidate for package > python3-slip-dbus-0.6.4-29.fc38.noarch > - cannot install the best update candidate for package > python3-libs-3.11.4-1.fc38.x86_64 > Problem 3: package ibus-1.5.29~rc1-2.fc39.x86_64 requires python(abi) = > 3.12, but none of the providers can be installed > - python3-3.12.0~rc1-1.fc39.i686 has inferior architecture > - cannot install both python3-3.11.4-1.fc38.x86_64 and > python3-3.12.0~rc1-1.fc39.x86_64 > - problem with installed package > - package python3-slip-dbus-0.6.4-29.fc38.noarch requires python(abi) = > 3.11, but none of the providers can be installed > - cannot install the best update candidate for package > ibus-1.5.28-6.fc38.x86_64 > Problem 4: package vtk-9.2.6-6.fc39.x86_64 requires > libpython3.12.so.1.0()(64bit), but none of the providers can be installed > - cannot install both python3-libs-3.11.4-1.fc38.x86_64 and > python3-libs-3.12.0~rc1-1.fc39.x86_64 > - package python3-3.11.4-1.fc38.x86_64 requires python3-libs(x86-64) = > 3.11.4-1.fc38, but none of the providers can be installed > - problem with installed package > - package python3-slip-0.6.4-29.fc38.noarch requires python(abi) = 3.11, > but none of the providers can be installed > - cannot install the best update candidate for package > vtk-9.2.5-2.fc38.x86_64 > > and this with dnf: > > Problem 1: package python3-slip-0.6.4-29.fc38.noarch requires python(abi) > = 3.11, but none of the providers can be installed > - cannot install both python3-3.11.4-1.fc38.x86_64 and > python3-3.12.0~rc1-1.fc39.x86_64 > - cannot install the best update candidate for package > python3-slip-0.6.4-29.fc38.noarch > - cannot install the best update candidate for package > python3-3.11.4-1.fc38.x86_64 > Problem 2: package python3-3.11.4-1.fc38.x86_64 requires > python3-libs(x86-64) = 3.11.4-1.fc38, but none of the providers can be > installed > - package python3-slip-dbus-0.6.4-29.fc38.noarch requires python(abi) = > 3.11, but none of the providers can be installed > - cannot install both python3-libs-3.11.4-1.fc38.x86_64 and > python3-libs-3.12.0~rc1-1.fc39.x86_64 > - cannot install the best update candidate for package > python3-slip-dbus-0.6.4-29.fc38.noarch > - cannot install the best update candidate for package > python3-libs-3.11.4-1.fc38.x86_64 > Problem 3: package torbrowser-launcher-0.3.6-6.fc39.noarch requires > python(abi) = 3.12, but none of the providers can be installed > - python3-3.12.0~rc1-1.fc39.i686 has inferior architecture > - cannot install both python3-3.11.4-1.fc38.x86_64 and > python3-3.12.0~rc1-1.fc39.x86_64 > - problem with installed package > - package python3-slip-dbus-0.6.4-29.fc38.noarch requires python(abi) = > 3.11, but none of the providers can be installed > - cannot install the best update candidate for packag
