f33: nothing provides gnome-themes needed by fedora-icon-theme
Hi, Apparently, fc33 contains a broken package dependency On fc33: # dnf install fedora-icon-theme Last metadata expiration check: 3:52:18 ago on Mon 26 Oct 2020 11:29:53 AM CET. Error: Problem: conflicting requests - nothing provides gnome-themes needed by fedora-icon-theme-1.0.0-28.fc33.noarch (try to add '--skip-broken' to skip uninstallable packages) Ralf ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Fedora-Live-26 fails to boot: A start job is running for dev-map...\x2drv.device
Hi, I have been trying to test Fedora-Workstation-Live-i386-26-*.n.0.iso Unfortunately, all attempts in recent weeks hang with this boot message: ... [...] A start job is running for dev-map...\x2drv.device Q: Which component is issuing this message? I just filed a BZ against device-mapper, but to my big surprise this package appears orphaned[1]. Ralf [1] https://bugzilla.redhat.com/show_bug.cgi?id=1436096 ___ perl-devel mailing list -- perl-de...@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: F25 much more worse then F24, I hope F26 will be better
On 03/02/2017 12:27 PM, Joerg Lechner wrote:
Hi,
investigation of the first action point: "dnf update" takes too much
time in F25.
I made timestamps by my watch not by the system.
start of dnf update 09:48
...
update finished at 10:37
Question: Are these update times ok, tolerable,
Hard to tell. Overall, these times are miserable and are unlike what I
am used to. But from what you are telling, one can only guess on the
origin, esp. one would have to identify whether it's the download
transfer rate or a bottleneck on your machine.
My first guess on the origin, would be drpms, which I found are a
significant source of time-waste, esp. on machines with slow (e.g.
flash?) or little memory. I recommend to try switching them off (Add
deltarpm=false to /etc/dnf/dnf.conf).
My second guess would be you to have hit a slow mirror. During project
phases with heavy mirror activities, like the current one, I have been
experiencing a tendency in yum and dnf to favour broken and outdated
mirrors, seemingly because the fast mirrors are constantly out of sync.
In this case, aborting (Ctrl C) and erasing the cache ("dnf clean all"
or rm -rf /var/cache/dnf) and retrying again, hoping dnf will choose a
better mirror, should help.
A third possibility, I have seen during updates is something else
loading a machine to an extend, it starts behaving utterly slow. In the
past, one such cases I was facing journald trying to fill its files at
rates the machine could not write them to disk anymore, in recent times,
I am occasionally experiencing situations which look like network-io
bringing machines close to stand-still.
Ralf
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: Moan about dnf on Rawhide
On 02/20/2017 05:16 PM, Adam Williamson wrote: On Mon, 2017-02-20 at 16:38 +0100, Ralf Corsepius wrote: On 02/20/2017 03:20 AM, Adam Williamson wrote: On Sun, 2017-02-19 at 09:07 -0800, Adam Williamson wrote: So as there was a successful Rawhide compose today, what's there now (allowing for mirror sync) has changed since yesterday and the updated dnf is there. Sorry, I was wrong about this, I misread my emails a bit. There's still not been a successful compose since 20170215. Hopefully we get one soon. In other words, since Feb 15, due to rawhide not having been updated you have strangled any local package building and testing rawhide. To me this qualifies as your "That's how things work" being fundamentally flawed and broken for no-good, absurd reasons. I don't know why you're talking about 'me', since I've not got anything to do with release engineering. Then extend my sentences to releng. Fact is YOU (who ever feels addressed) are strangling Fedora and render testing and development into a joke. Since I don't work for release engineering I don't know all the details about why the process works this way, I clearly can't have passed those reasons on to you, so your assertion that the reasons are 'no-good [and] absurd' is itself absurd. Quite simple: Making "a consistent release" a prerequisite to rawhide is utter non-sense. Rawhide is not a release. The person, who added this prerequisite, should leave Fedora, IMNSHO. Rawhide serves testing purposes and by-definition is permanently broken. Or more pragmatically put: in current (Feb 15) release: - The kernel is broken for me (doesn't boot) - glibc is broken for me (It segfaults). - dnf is a corrupt and inconsistent train-wreck. ... Since then, probably several 100s of supposed to-be-bugfixes where built, but YOU are keeping them behind closed doors. Ralf ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: Moan about dnf on Rawhide
On 02/20/2017 03:20 AM, Adam Williamson wrote: On Sun, 2017-02-19 at 09:07 -0800, Adam Williamson wrote: So as there was a successful Rawhide compose today, what's there now (allowing for mirror sync) has changed since yesterday and the updated dnf is there. Sorry, I was wrong about this, I misread my emails a bit. There's still not been a successful compose since 20170215. Hopefully we get one soon. In other words, since Feb 15, due to rawhide not having been updated you have strangled any local package building and testing rawhide. To me this qualifies as your "That's how things work" being fundamentally flawed and broken for no-good, absurd reasons. Ralf ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: Moan about dnf on Rawhide
On 02/19/2017 02:13 AM, Adam Williamson wrote: On Sat, 2017-02-18 at 05:43 +, Russel Winder wrote: This has been happening for a while now. Given that dnf is so critical to updating Rawhide I would not have expected this to be the case. It was in fact fixed a while ago (as Viorel explained). But Rawhide packages only appear in the repository after a successful Rawhide compose, Why? and Rawhide compose has failed every day since 20170215, so no packages built since then are in the repo; you have to get them from kojipkgs until compose works again. This is not helpful. It disables people/testers from testing, building and upgrading packages. Ralf ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: Fedora 25 RC 1.2 compose check report
On 11/10/2016 02:43 AM, Fedora compose checker wrote: No missing expected images. Failed openQA tests: 2/101 (x86_64), 3/17 (i386) New failures (same test did not fail in 25 RC 1.1): ID: 47037 Test: i386 Workstation-live-iso install_default URL: https://openqa.fedoraproject.org/tests/47037 ID: 47124 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/47124 ID: 47125 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/47125 ID: 47138 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/47138 Old failures (same test failed in 25 RC 1.1): ID: 47139 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/47139 Passed openQA tests: 99/101 (x86_64), 14/17 (i386), 2/2 (arm) fc25 still creates an empty file /null upon every bootup. I would have filed a BZ but, I don't know which component to assign such a BZ to, because I don't know what creates this file. Ralf ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24
On 10/04/2016 05:51 PM, Adam Williamson wrote: Recently several reports of people getting 'duplicated packages' and 'kernel updates not working' have come through to us in QA from Fedora 24 users. I managed to get one reporter to explain more specifically what happened, and it sounds a lot like what's happening is that something in the 'dnf update' process can cause a GNOME or X crash, possibly depending on hardware or package set installed. When that happens, the update process is killed and does not complete cleanly, which is why you get 'duplicated packages' and other odd results. I'm working with the reporter right now to investigate and hopefully get this fixed, but in the meantime - and this is in fact our standard advice anyway, but it bears repeating - DON'T RUN 'dnf update' INSIDE A DESKTOP. FWIW: Since ca. f22/f23 I've repeatedly seen "dnf update" running in xfce4-terminals in Xfce4 desktops killing X or something underneath of X, leaving duplicate packages in rpmdb. So far, I've been suspecting some systemd services is killing something related to networking or X, but I never managed to isolate the cause. Ralf ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org
Re: [Bug 1338076] kernel crash on boot, just when gdm is supposed to launch
On 05/22/2016 06:47 AM, Felix Miata wrote: Peter G. composed on 2016-05-21 22:01 (UTC-0+00): Without it, I might not have been able to recognize or view the kernel crash output this morning h/t I sure hope we can get this fixed :-) Whatever broke it happened after f23, since it worked splendidly right up until about Saturday, when I overwrote f23 with f24 (clean install). For me, all i686-kernels >= 4.5 were just plain dysfunctional, seemingly because of i915/i945GSE problems on an older N270-based netbook. Did you look at https://fedoraproject.org/wiki/Common_F24_bugs before choosing to replace your functioning installation with a pre-release? The very first bug there should have given you cause to investigate before disposing of your full functionality. We've been having trouble with 32 bit Intel for several months. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1302071 was filed more than 4 months ago, and is not! marked FIXED. This mailing list has warned of various 32 bit troubles several times since then. I have several F24 installations on Intel i686, probably all of which have been non-functional with some or all kernels since F23 was released. For me, this morning came with a surprise: kernel-4.5.5-201.fc23 and kernel-4.5.5-300.fc24 (Both currently in koji) were the first kernel-packages from the 4.5.x-series which seem to work for me on above-mentioned netbook. If you want a working system back soon, I suggest you consider either restoring your backup of F23 if you have one, reinstalling F23 if you don't, or, now that i686 is being squeezed out of Fedora, consider a different (Plasma 5, or lighter weight) distro with less evolutionary activity. Is FESCo or the Board still wondering why Fedora is loosing users? ;) Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: Bug 1257131 (also proposed as blocker) needs testing
On 09/06/2015 08:31 AM, Adam Williamson wrote: On Sat, 2015-09-05 at 23:28 +0200, Ralf Corsepius wrote: In my understanding, this bug resembles quite bit to what I am observing with Fc22 on a Lenovo Flex-2 https://bugzilla.redhat.com/show_bug.cgi?id=1189107 I haven't tried fc23 on this machine, yet. There are some Magic Voodoo Kernel Parameters that those affected could try, let me go look 'em up... oh, that's right, the 'reboot=' parameter - might be useful to try the variants of that. https://www.kernel.org/doc/Documentation/kernel-parameters.txt , search for reboot= Googling seems to indicate my issue w/ fc22 likely is: https://bugzilla.kernel.org/show_bug.cgi?id=66171 At least adding xhci_hcd.quirks=270336 (i.e. (1<<18 | 1<<13) == (XHCI_SPURIOUS_WAKEUP | XHCI_SPURIOUS_REBOOT) ) to the kernel boot parameters seems to fix it. I've updated BZ https://bugzilla.redhat.com/show_bug.cgi?id=1189107#c9 accordingly. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Bug 1257131 (also proposed as blocker) needs testing
On 09/05/2015 10:14 PM, Adam Williamson wrote: On Sat, 2015-09-05 at 21:38 +0200, Giulio 'juliuxpigface' wrote: Hi folks. Sorry if I write this mail, but there is a bug which might potentially be serious enough to be a nasty blocker - at least in my opinion -. The link is this: https://bugzilla.redhat.com/show_bug.cgi?id=1257131 As I wrote with my comment, I don't hit the issue inside a vm. Unfortunately I haven't got available hardware to test this on bare metal, so I'm asking if anyone encounters this bug. We need to be sure that this doesn't affect a large class of laptops. Again... Please excuse me if I ping the ML, but I think that it's better to collect more data before the next blocker review in order to ease the decision regarding this bug. This sounds a lot like a firmware-specific issue to me; does anyone else on the list have a similar system they could check? (Lenovo Edge) In my understanding, this bug resembles quite bit to what I am observing with Fc22 on a Lenovo Flex-2 https://bugzilla.redhat.com/show_bug.cgi?id=1189107 I haven't tried fc23 on this machine, yet. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: dl.fedoraproject.org rsync broken most of the day
On 08/19/2015 03:05 PM, Bruno Wolff III wrote: On Tue, Aug 18, 2015 at 21:36:11 -0500, Bruno Wolff III br...@wolff.to wrote: I have been getting rsync errors from dl.fedoraproject.org since this morning. Things are working again this morning. Right now, * mirrors.fedoraproject.org seems broken: # dnf --refresh upgrade Error: Failed to synchronize cache for repo 'fedora' from 'https://mirrors.fedoraproject.org/metalink?repo=fedora-22arch=x86_64': Cannot prepare internal mirrorlist: Curl error (35): SSL connect error for https://mirrors.fedoraproject.org/metalink?repo=fedora-22arch=x86_64 [Encountered end of file] * bugzilla.redhat.com behaves jerkish and is almost impossible to use from here. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Live media changes systemtime to UTC
On 05/29/2015 10:27 PM, Gavin Flower wrote: The system should ALWAYS be in UTC (also known as GMT)! It should NEVER be changed to local time. You are ignoring the fact, that other OSes require the RTC to be set to local time and do *NOT SUPPORT* RTC set to UTC. = Fedora cannot avoid having to support RTC in local time if Fedora is supposed to be installable in parallel to such other OSes. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: oversized icons in nautilus
On 05/26/2015 04:48 PM, Matthias Clasen wrote: This thread is lacking a bit in clarity as to what symptoms you all are seeing, and what the circumstances are. Cf. https://bugzilla.redhat.com/show_bug.cgi?id=1224597 Which more details do you need? Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: oversized icons in nautilus
On 05/24/2015 04:44 PM, Ronal B Morse wrote: On 05/24/2015 12:05 AM, Ralf Corsepius wrote: [1] In xfce, try Settings-Xfce Theme Manager-Icons Ralf, in the Nautilus window running on Gnome, click on the middle button on the right side of the upper panel (nine dots). There is a slider control below the layout selection buttons at the top. Move the slider to the left. That fixes the issue for me. Thanks for the hint, but this doesn't help either. The slider changes the size of the file icons but keeps the directory icons constant (constantly oversized). Also, this slider doesn't allow changing the file icon size to the size of the directory icons. Even pulling the silder to max, the file icons are smaller than these huge directory icons. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: oversized icons in nautilus
On 05/24/2015 05:57 PM, Kalev Lember wrote: On 05/24/2015 05:32 PM, Ralf Corsepius wrote: On 05/24/2015 04:44 PM, Ronal B Morse wrote: On 05/24/2015 12:05 AM, Ralf Corsepius wrote: [1] In xfce, try Settings-Xfce Theme Manager-Icons Ralf, in the Nautilus window running on Gnome, click on the middle button on the right side of the upper panel (nine dots). There is a slider control below the layout selection buttons at the top. Move the slider to the left. That fixes the issue for me. Thanks for the hint, but this doesn't help either. The slider changes the size of the file icons but keeps the directory icons constant (constantly oversized). Also, this slider doesn't allow changing the file icon size to the size of the directory icons. Even pulling the silder to max, the file icons are smaller than these huge directory icons. Can you file it at https://bugzilla.gnome.org/enter_bug.cgi?product=nautilus together with the screenshot, please? Done. Cf. https://bugzilla.redhat.com/show_bug.cgi?id=1224597 Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: oversized icons in nautilus
On 05/24/2015 07:40 AM, Ralf Corsepius wrote: On 05/23/2015 07:31 PM, Joachim Backes wrote: On 05/23/2015 06:43 PM, Ralf Corsepius wrote: Hi, in fc22, I am observing unreasonably oversized directory icons (256x256?) in nautilus, much bigger than file icons (64x64?). How to change this? Ralf I asked this question already in the early f22 alpha times, but got only the answer that later nautilus versions would solve this problem. But nothing happened :-( Still huge desktop icons, whose size is not reducable, despite they are of type SVG. Which DE are you using. I am observing this phenomenon when using nautilus w/ xfce, but not with Gnome Classic. Replying to myself: Seems to me as if this issue is related to the icon theme being used. Apparently the Fedora and the Mist icon theme expose this issue, while others (amongst them the Gnome, HighContrast) don't[1]. Somewhat special seems to be the oxygen icon. It seems to scale file and dirs at the same size, but twice the size of Gnome ;) So, my conclusion: The Fedora, Mist and Oxygen icon theme seem not to harmonize well with nautilus and xfce (Read: These themes are broken). Ralf [1] In xfce, try Settings-Xfce Theme Manager-Icons -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: oversized icons in nautilus
On 05/24/2015 08:50 AM, Joachim Backes wrote: Perhaps what you described is an additional (nautilus) problem. Probably. My issue looks different (C.f. attachment; Fedora icon theme w/ nautilus under xfce). I guess, what I am facing are part of xfce/Gnome interoperability issues. AFAIS, there seem to be quite a few, more. They are handicapping usability to an extend, it's not unlikely, I'll stay with fc21 on my production systems, at least for now. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
oversized icons in nautilus
Hi, in fc22, I am observing unreasonably oversized directory icons (256x256?) in nautilus, much bigger than file icons (64x64?). How to change this? Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: dnf vs yum
On 05/23/2015 05:33 PM, Russel Winder wrote: I switched from yum to dnf, and now have managed to stop typing yum :-) However, I have a collection of packages that are not upgrading, I assume due to dependencies not being satisfied. With Yum I could find out what the dependencies were, but I do not see a way of doing this with dnf. The dnf help is either not being helpful or I am just missing the relevant bit. You are likely facing the consequences of the dnf's changes having been discussed in https://lists.fedoraproject.org/pipermail/devel/2015-April/209697.html ff. I had been facing this issue myself and consider this dnf behavior change to be such kind of harmful and silly, I feel to decision to use dnf on fc22 should be reverted. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: oversized icons in nautilus
On 05/23/2015 07:31 PM, Joachim Backes wrote: On 05/23/2015 06:43 PM, Ralf Corsepius wrote: Hi, in fc22, I am observing unreasonably oversized directory icons (256x256?) in nautilus, much bigger than file icons (64x64?). How to change this? Ralf I asked this question already in the early f22 alpha times, but got only the answer that later nautilus versions would solve this problem. But nothing happened :-( Still huge desktop icons, whose size is not reducable, despite they are of type SVG. Which DE are you using. I am observing this phenomenon when using nautilus w/ xfce, but not with Gnome Classic. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedup 21-22 issues
On 05/15/2015 10:51 PM, Adam Williamson wrote: On Thu, 2015-05-14 at 08:31 +0200, Ralf Corsepius wrote: On 05/08/2015 02:32 PM, Ralf Corsepius wrote: Hi, I just gave fedup a try and found myself confronted with this: # yum update ... The situation has worsened: ,,, WARNING: potential problems with upgrade 4:texlive-luatex-bin-svn31084.0-7.1.20140525_r34255.fc21.x86_64 (no replacement) requires poppler-0.26.2-9.fc21.x86_64 (replaced by poppler-0.30.0-3.fc22.x86_64) https://admin.fedoraproject.org/updates/FEDORA-2015-7564/texlive-2014 -8.20140525_r34255.fc22 was pushed stable five days ago (05-10) and looks like it should resolve this: it requires the same soname as the current poppler package provides. It sounds like your repositories are somehow out of date? Well, quite likely, but not deliberately. AFAICT, there had been broken F22 pushes and quite a few broken/out-of-sync F22 EU mirrors, this week. Also, FWIW, I have been facing these issues on 3 machines with fully updated F21. From this, I conclude likely is a systematic problem and not a random repository hick-up This is what I am observing on 2 of these boxes right now: # yum update ... No packages marked for update # fedup --network 22 WARNING: potential problems with upgrade firefox-38.0-4.fc21.x86_64 (no replacement) requires libicu-52.1-6.fc21.x86_64 (replaced by libicu-54.1-1.fc22.x86_64) ... WARNING: problems were encountered during transaction test: broken dependencies firefox-38.0-4.fc21.x86_64 requires libicu-52.1-6.fc21.x86_64 ... IMO, today's case seems to be caused by an inconsistency between the Fedora 21 and Fedora 22 repos. This would be the classic design flaw in fedora's release process during this phase of release preps (fc21's firefox is newer than fc22's, but fc21's firefox depends on older libs) Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedup 21-22 issues
On 05/08/2015 02:32 PM, Ralf Corsepius wrote: Hi, I just gave fedup a try and found myself confronted with this: # yum update ... The situation has worsened: ,,, WARNING: potential problems with upgrade 4:texlive-luatex-bin-svn31084.0-7.1.20140525_r34255.fc21.x86_64 (no replacement) requires poppler-0.26.2-9.fc21.x86_64 (replaced by poppler-0.30.0-3.fc22.x86_64) sqlitebrowser-3.5.1-1.fc21.x86_64 (replaced by sqlitebrowser-3.6.0-1.fc22.x86_64) requires sqlitebrowser-3.5.1-1.fc21.x86_64 (replaced by sqlitebrowser-3.6.0-1.fc22.x86_64) 4:texlive-pdftex-bin-svn30845.0-7.1.20140525_r34255.fc21.x86_64 (no replacement) requires poppler-0.26.2-9.fc21.x86_64 (replaced by poppler-0.30.0-3.fc22.x86_64) ... WARNING: problems were encountered during transaction test: broken dependencies sqlitebrowser-3.6.0-1.fc22.x86_64 requires sqlitebrowser-3.6.0-1.fc22.x86_64 texlive-luatex-bin-4:svn31084.0-7.1.20140525_r34255.fc21.x86_64 requires poppler-0.26.2-9.fc21.x86_64 texlive-pdftex-bin-4:svn30845.0-7.1.20140525_r34255.fc21.x86_64 requires poppler-0.26.2-9.fc21.x86_64 ... Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedup 21-22 issues
On 05/11/2015 09:09 AM, Kamil Paral wrote: Hi, I just gave fedup a try and found myself confronted with this: # yum update ... # fedup --network 22 ... WARNING: potential problems with upgrade sqlitebrowser-3.5.1-1.fc21.x86_64 (replaced by sqlitebrowser-3.6.0-1.fc22.x86_64) requires sqlitebrowser-3.5.1-1.fc21.x86_64 (replaced by sqlitebrowser-3.6.0-1.fc22.x86_64) ... WARNING: problems were encountered during transaction test: broken dependencies sqlitebrowser-3.6.0-1.fc22.x86_64 requires sqlitebrowser-3.6.0-1.fc22.x86_64 ?!? Unfortunately, broken dependencies occur almost every time you use fedup, especially before final release. I know. I have been complaing about this release process *defect* ever since Fedora exists. It's because it uses update instead of distro-sync mode [1]. Well, I do not think this reasoning applies in this case: Both packages in question are provided through the f22 repos: https://dl.fedoraproject.org/pub/fedora/linux/development/22/x86_64/os/Packages/s/sqlitebrowser-3.6.0-1.fc22.x86_64.rpm https:dl.fedoraproject.org/pub/fedora/linux/development/22/x86_64/os/Packages/q/qhexedit2-qt5-libs-0.6.6-1.fc22.x86_64.rpm It's just that fedup fails handling them miserably (== bug #1), producing bogus error messages (== bug #2). Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedup 21-22 issues
On 05/08/2015 04:57 PM, Eric Blake wrote: On 05/08/2015 06:32 AM, Ralf Corsepius wrote: Hi, I just gave fedup a try and found myself confronted with this: # yum update ... # fedup --network 22 ... WARNING: potential problems with upgrade sqlitebrowser-3.5.1-1.fc21.x86_64 (replaced by sqlitebrowser-3.6.0-1.fc22.x86_64) requires sqlitebrowser-3.5.1-1.fc21.x86_64 (replaced by sqlitebrowser-3.6.0-1.fc22.x86_64) ... WARNING: problems were encountered during transaction test: broken dependencies sqlitebrowser-3.6.0-1.fc22.x86_64 requires sqlitebrowser-3.6.0-1.fc22.x86_64 See also https://bugzilla.redhat.com/show_bug.cgi?id=1214931, for a similar message about WARNING: potential problems with upgrade yum-3.4.3-152.fc20.noarch (replaced by yum-3.4.3-505.fc22.noarch) requires yum-3.4.3-152.fc20.noarch (replaced by yum-3.4.3-505.fc22.noarch) In my case, my guess is the origin of the breakdown is a side effect of the f22 repo currently being in a broken state: Proof: On an up2date fc22 system: # dnf install sqlitebrowser Error: nothing provides libqhexedit-qt5.so.1()(64bit) needed by sqlitebrowser-3.6.0-1.fc22.x86_64 Apparently sqlitebrowser was pushed to the repos, but not the necessarily required qhexedit2-qt5-libs-0.6.6-1.fc23.x86_64 (which provides ibqhexedit-qt5.so.1). Nevertheless the WARNING above seems just broken. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: More dnf adventures (Release blocker?)
On 04/23/2015 07:32 AM, Adam Williamson wrote: On Thu, 2015-04-23 at 05:48 +0200, Ralf Corsepius wrote: Hi, I would like to nominate this dnf-bug https://bugzilla.redhat.com/show_bug.cgi?id=1214538 as a release blocker. https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Proposing_blocker_bugs ATM, this issue deterministically happens on my only fc22-test system. Did you actually try loading those links any other way? http://ftp.halifax.rwth-aachen.de/fedora/linux/development/22/i386/os/Packages/g/gdm-3.16.0.1-2.fc22.i686.rpm *is* 404. ftp://ftp.halifax.rwth-aachen.de/fedora/linux/development/22/i386/os/Packages/g/gdm-3.16.0.1-2.fc22.i686.rpm *is* 550. It seems to be a mirror issue, not a dnf issue. And? This doesn't matter at all! dnf must diagnose this situation and react appropriately. Yum did - dnf hangs and seem to try ad infinitum == bug + massive regression. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
More dnf adventures (Release blocker?)
Hi, I would like to nominate this dnf-bug https://bugzilla.redhat.com/show_bug.cgi?id=1214538 as a release blocker. ATM, this issue deterministically happens on my only fc22-test system. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedup f20-f21 kde broken deps
On 12/08/2014 08:26 AM, Adam Williamson wrote: On Mon, 2014-12-08 at 07:36 +0100, Ralf Corsepius wrote: Just for the purpose of testing upgrade.img, you can simply enable updates-testing if it turns out you have a situation like this and you need a package from u-t to make the upgrade package set viable. This is not true. They are completely different scenarios. The purpose of using release+updates+updates-testing is entirely different from using release+updates, esp. in stages like these. The purpose of using release+updates is to test upgrading to Fedora(N+1) (and testing fedup/yum/dnf-support ) and not to test update-candidate packages from update-testing. I don't really see the distinction as important, I consider this to be critically important ... because it is a perennially moving target in any case. After Tuesday, f21 will get a new stable updates push every day. ... it is likely the #1 cause of users facing broken updates - Esp. during time-frames shortly after releases like these. I haven't checked details this time, but there a quite a few reports indicating this has happened again with this release. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedup f20-f21 kde broken deps
On 12/04/2014 06:43 AM, Adam Williamson wrote: On Thu, 2014-12-04 at 06:16 +0100, Ralf Corsepius wrote: Untrue. All you need to do is to apply the after release update policy. I.e.: push updates to updates on both Fedora(N) and Fedora(N+1). When you need to cut a snapshot, move Fedora(N+1) updates into the main repository. Hum. It might be possible to use the branched updates during freezes in that way, yeah. Have to see what releng thinks. 2. Implement a perfect and strictly-enforced upgradepath test and abandon milestone freezes The consequence of this would be be we'd probably never manage to get the damn milestone releases done because people would keep pushing changes that break them. Neither of those seems likes an improvement on the current situation to me. Well, right now, you can't test upgrading and are likely to be broken upgrade paths (as Fedora had always done). You can test fine; just test with updates-testing. No. updates-testing's purpose is to test update-candidate packages. I.e. these packages may never end up in updates for a variety of reasons. updates purpose is to provide updates to packages in release. i.e. they must integrate perfectly into release. The difference is important in release preparation stages of a Fedora release. Just for the purpose of testing upgrade.img, you can simply enable updates-testing if it turns out you have a situation like this and you need a package from u-t to make the upgrade package set viable. This is not true. They are completely different scenarios. The purpose of using release+updates+updates-testing is entirely different from using release+updates, esp. in stages like these. The purpose of using release+updates is to test upgrading to Fedora(N+1) (and testing fedup/yum/dnf-support ) and not to test update-candidate packages from update-testing. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedup f20-f21 kde broken deps
On 12/03/2014 05:54 PM, Neal Becker wrote: What is needed here, is an option to yum to use updates-testing _only_ to solve broken deps. This would be playing with symptoms. What we need is a fix to the Fedora release process. It simply is broken and has always been broken, ever since Fedora exists. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: fedup f20-f21 kde broken deps
On 12/03/2014 09:41 PM, Adam Williamson wrote: On Wed, 2014-12-03 at 18:21 +0100, Ralf Corsepius wrote: On 12/03/2014 05:54 PM, Neal Becker wrote: What is needed here, is an option to yum to use updates-testing _only_ to solve broken deps. This would be playing with symptoms. What we need is a fix to the Fedora release process. It simply is broken and has always been broken, ever since Fedora exists. Nothing's broken. My point is: All NEVRs of packages in Fedora(N) must be = Fedora(N+1). At the current point in time this does not apply, so all attempts to yun/dnf-upgrade and to run fedup must fail Fedora 21 is not yet released. There's no reasonable expectation that upgrades should work perfectly at this point. I disagree. IMO, at this point in time, it's necessary to have upgrades working to be able to test upgrades. An issue like this, which is a perfectly logical and understood consequence of a reasonable release process, does not indicate that 'it simply is broken'. I disagree. At this point in time fedora(N) + fedora-updates(N) and fedora(N+1)+updates(N+1) must be working. fedora-testing(N+1) must be disabled and the update push-cycles be synchronised. The updates repository is populated before we announce the release. If there are broken upgradepaths at that point we should aim to fix them as a high priority before release. Well, this had never worked ever since Fedora exists. At the time releases had been released, fc(N+1) had always contained packages with NEVR less than fc(N). These were a consequence of the working prinicples of the current workflow. There are logically speaking only two ways you could possibly 'fix' this without introducing yet another repository, if that's what you wanted to do: 1. Implement a perfect and strictly-enforced upgradepath test Exactly. The consequence of this would be that no-one could update anything in a stable release past the version in Branched stable - *even during a Branched milestone freeze* Untrue. All you need to do is to apply the after release update policy. I.e.: push updates to updates on both Fedora(N) and Fedora(N+1). When you need to cut a snapshot, move Fedora(N+1) updates into the main repository. 2. Implement a perfect and strictly-enforced upgradepath test and abandon milestone freezes The consequence of this would be be we'd probably never manage to get the damn milestone releases done because people would keep pushing changes that break them. Neither of those seems likes an improvement on the current situation to me. Well, right now, you can't test upgrading and are likely to be broken upgrade paths (as Fedora had always done). Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Server issues
On 11/17/2014 06:19 PM, Mike Chambers wrote: Have a few issues that are now having, but think they are all related.. Had a desktop (using as mini server) that was running Fedora 20. I used yum to upgrade to latest on F21, both main and testing repos, and upgraded without a hitch (no errors that I saw). Now, I can't mount my nfs partitions, email client can't connect, no ftp, no http. I can connect to the server via ssh but that's it. I can ping out to the internet from the server with no issues. I am struggling with similar issues - manually nfs mounting works, but autofs mounting nfs doesn't ;) Sooo, is that kernel causing a problem, Unlikely. or some other service that might be related that didn't start on boot? systemd, rsp. services ;) One issue I had, was nfs-server.service not being started. Seems as if it was renamed from nfs.service in f20 to nfs-server.service in f21, but this renamer not having been taken into account on updates. Some port issue or something related that has to do with all of the issues? Possible. Check your firewalld setting and the nfs-related settings in your SELinux-setup. Both seem to require manual tweaks to get them working. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: why does perl-ExtUtils-MakeMaker depend on systemtap-sdt-devel?
On 09/10/2014 08:24 PM, Adam Jackson wrote:
On Wed, 2014-09-10 at 12:32 -0400, Robert P. J. Day wrote:
possibly admitting my ignorance, but why does installing
perl-ExtUtils-MakeMaker drag in systemtap-sdt-devel? i see no logical
connection, and i don't even have any systemtap packages installed.
i ask since i'm working with a software package that fails to
configure properly if the header file sys/sdt.h is installed on the
development system, but it needs the MakeMaker package, so i'm in a
bit of a dilemma.
Coincidence of events. I hit the same issue yesterday when trying rt-4
on f21 for the first time ;)
When in doubt:
$ echo n | sudo yum install --releasever=21 --installroot=/tmp/empty foo
And then examine the output. In this case, perl-ExtUtils-MakeMaker →
perl-ExtUtils-Install → perl-devel → systemtap-sdt-devel. Which appears
to have been so since December 2010:
Yes, it's perl-devel which pulls in systemtap-sdt-devel
But, I think there are a couple of bogus deps on perl-devel in some of
the perl package's sub-packages, which are causing the dependency bloat e.g:
perl-ExtUtils-CBuilder
perl-ExtUtils-Embed
perl-ExtUtils-Install
perl-ExtUtils-MakeMaker
perl-ExtUtils-ParseXS
perl-Module-Build
I don't think any of these should R: perl-devel
(f21-patch enclosed below).
Ralf
diff --git a/perl.spec b/perl.spec
index 642f6ab..c2aca19 100644
--- a/perl.spec
+++ b/perl.spec
@@ -745,7 +745,6 @@ Epoch: 1
Version:2.49
Requires: %perl_compat
Requires: %{name}-Encode = %{epoch}:%{version}-%{release}
-Requires: perl-devel
BuildArch: noarch
%description Encode-devel
@@ -799,7 +798,6 @@ License:GPL+ or Artistic
Epoch: 1
# real version 0.280210 https://fedoraproject.org/wiki/Perl/Tips#Dot_approach
Version:0.28.2.10
-Requires: perl-devel
Requires: %perl_compat
BuildArch: noarch
@@ -815,7 +813,6 @@ Group: Development/Languages
License:GPL+ or Artistic
Epoch: 0
Version:1.30
-Requires: perl-devel
Requires: %perl_compat
BuildArch: noarch
@@ -829,7 +826,6 @@ Group: Development/Languages
License:GPL+ or Artistic
Epoch: 0
Version:1.59
-Requires: perl-devel
Requires: %perl_compat
BuildArch: noarch
@@ -844,7 +840,6 @@ Group: Development/Languages
License:GPL+ or Artistic
Epoch: 0
Version:6.66
-Requires: perl-devel
Requires: %perl_compat
Requires: perl(Data::Dumper)
Requires: perl(DynaLoader)
@@ -875,7 +870,6 @@ Group: Development/Languages
License:GPL+ or Artistic
Epoch: 0
Version:1.63
-Requires: perl-devel
Requires: %perl_compat
Requires: perl(File::Path)
BuildArch: noarch
@@ -892,7 +886,6 @@ License:GPL+ or Artistic
# Epoch bump for clean upgrade over old standalone package
Epoch: 1
Version:3.18
-Requires: perl-devel
Requires: %perl_compat
BuildArch: noarch
Obsoletes: perl-ExtUtils-Typemaps
@@ -1223,7 +1216,6 @@ Requires: perl(Archive::Tar) = 1.08
Requires: perl(CPAN::Meta) = 2.110420
Requires: perl(ExtUtils::CBuilder) = 0.15
Requires: perl(ExtUtils::ParseXS) = 1.02
-Requires: perl-devel
Requires: %perl_compat
# Optional run-time needed for generating documentation from POD:
Requires: perl(Pod::Html)
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: /var/log/messages is scrambled!
On 02/27/2014 08:56 AM, Adam Williamson wrote: On Thu, 2014-02-27 at 08:25 +0100, Ralf Corsepius wrote: On 02/27/2014 08:08 AM, Adam Williamson wrote: On Thu, 2014-02-27 at 07:10 +0100, Ralf Corsepius wrote: On 02/27/2014 06:43 AM, Chris Murphy wrote: On Feb 26, 2014, at 9:24 AM, Neal Becker ndbeck...@gmail.com wrote: sudo journalctl --verify all say 'PASS' OK good news. It looks like some sort of throttling by rsyslogd. I'm vaguely curious if it's some runaway/annoyed process is dumping a lot of message into the journal, and whether the journal can keep up or if it's also affected and throttles. Could it be (wild guess), rsyslogd and journald when being used simultaneously, are having locking issues? I really doubt it. The current rsyslog is explicitly designed to act as a journald consumer. That was the intent all along. How about log-messages on the console? The symptom I am struggling with is my console is freezing when journald sent a message to the console. Some weeks ago, I reported the details on some fp.org list (IRC users@), but never received a satisfactory reply. Just found the original post: https://lists.fedoraproject.org/pipermail/test/2013-December/119352.html So far, after weeks of struggling my (so far seeingly working) work-around is to yum remove rsyslogd combined with dmsg -D, without knowing the actual cause. Hum - seems odd, but I don't get console log messages very often so I can't say I haven't seen it. Thanks to this long-term persisting kernel bug https://bugzilla.redhat.com/show_bug.cgi?id=769747 I am observing them once per minute at average (This truely nagging bug has been reported on various occasions across probably all distros, but seems to have been ignored so far.) Certainly sounds like a bug. If I were you I'd just file it, probably against rsyslog. Well, to be investigated - I haven't tried journald without dmsg -D, nor have I tried to reinstall rsyslogd, yet. I am inclined to be believe there is a journald vs. kernel issue, because before journald came around, I haven't had these freezes. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: /var/log/messages is scrambled!
On 02/27/2014 06:43 AM, Chris Murphy wrote: On Feb 26, 2014, at 9:24 AM, Neal Becker ndbeck...@gmail.com wrote: sudo journalctl --verify all say 'PASS' OK good news. It looks like some sort of throttling by rsyslogd. I'm vaguely curious if it's some runaway/annoyed process is dumping a lot of message into the journal, and whether the journal can keep up or if it's also affected and throttles. Could it be (wild guess), rsyslogd and journald when being used simultaneously, are having locking issues? I am asking, because I am facing console freezes, which go away, when switching off rsyslogd and console logging (dmesg -D) on a small memory system, which suffers from a kernel bug which raises a warning approx. every second. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: /var/log/messages is scrambled!
On 02/27/2014 08:08 AM, Adam Williamson wrote: On Thu, 2014-02-27 at 07:10 +0100, Ralf Corsepius wrote: On 02/27/2014 06:43 AM, Chris Murphy wrote: On Feb 26, 2014, at 9:24 AM, Neal Becker ndbeck...@gmail.com wrote: sudo journalctl --verify all say 'PASS' OK good news. It looks like some sort of throttling by rsyslogd. I'm vaguely curious if it's some runaway/annoyed process is dumping a lot of message into the journal, and whether the journal can keep up or if it's also affected and throttles. Could it be (wild guess), rsyslogd and journald when being used simultaneously, are having locking issues? I really doubt it. The current rsyslog is explicitly designed to act as a journald consumer. That was the intent all along. How about log-messages on the console? The symptom I am struggling with is my console is freezing when journald sent a message to the console. Some weeks ago, I reported the details on some fp.org list (IRC users@), but never received a satisfactory reply. So far, after weeks of struggling my (so far seeingly working) work-around is to yum remove rsyslogd combined with dmsg -D, without knowing the actual cause. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: May I file 1000 bugs aka upstream test suite tracking
On 02/23/2014 12:14 PM, drago01 wrote: On Sun, Feb 23, 2014 at 8:15 AM, Ralf Corsepius rc040...@freenet.de wrote: On 02/22/2014 07:34 PM, drago01 wrote: And running tests at build time is a kludge anyway building has nothing to do with testing. Well, a lot of people will disagree with this claim. Sure a lot of people disagree with a lot of things. Testing as part of building (running a package's testsuite) can cover a lot of cases, but is a subset of general testing. I didn't say it cannot cover cases (in fact it does). It is just the wrong point where it should be run. I have to disagree with you again. The best place to implement a package's self test is within the package, by the package authors. This is common practice for ages and has been exercised 1000's of times. I regret, but denying this consideration is just evidence of lack of experience. We do it due to lack of better infrastructure. Sure one can add additonal tests at various levels outside of a package, but this doesn't invalidate what I wrote above. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rfc: expectations for partitioning, Fedora.next
On 02/23/2014 03:33 AM, Felix Miata wrote: On 2014-02-22 18:49 (GMT-0700) Chris Murphy composed: This crappy partioning GUI in the installer is does not give me the amount of control on partitioning desired by me. I don't understand this. It's the most capable GUI partitioner + OS installer I've ever encountered, and I've used quite a few installers, yet maybe I'm missing something obvious? openSUSE? That's one point. Most people I have been talking to, are German and thus quite likely have experience with the openSUSE. I for one, also consider it to be the most evolved partitioner amongst those installers/partitioners I've encountered throughout the years. Another point people are referring to, is the Usability of Fedora's partitioner's GUI. Esp. users with some Linux experience (no absolute new comers nor experts/nerds), complain about too much hidden voodoo and shy away from installing Fedora, because they are afraid of the partitioner killing their existing partioning and them loosing the other OSes they already have installed (Often Win + Ubuntu). Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: May I file 1000 bugs aka upstream test suite tracking
On 02/22/2014 07:34 PM, drago01 wrote: And running tests at build time is a kludge anyway building has nothing to do with testing. Well, a lot of people will disagree with this claim. Testing as part of building (running a package's testsuite) can cover a lot of cases, but is a subset of general testing. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Fedora-packaging] May I file 1000 bugs aka upstream test suite tracking
On 02/21/2014 05:43 PM, Nikos Roussos wrote: On February 21, 2014 4:51:52 PM EET, Alexander Todorov atodo...@redhat.com wrote: На 21.02.2014 16:27, Richard W.M. Jones написа: Is it correct that you're only going to be filing bugs when upstream tarballs already contain test suites, but they are just not enabled in the Fedora package? Hi Richard, I meant just the opposite. However I will also do what you suggest but this will result in far less number of bugs (probably around 100). I want to track which packages *DO NOT* have any tests and later be able to focus on creating them (be it working with volunteers, GSoC participants or whoever is willing to step up to this task). And what happens if you create a testing suite for a project but the upstream is unwilling to integrate? It seems that it would make more sense to do it in cooperation with upstream, thus filing the bug there. Exactly. However most upstreams who are confronted with bugs telling them Your package is lacking a testsuite, please add one, without being presented a concrete proposaly will simply close this bug and consider the submitter to be troll. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: /bin/sh: -chmod: command not found
On 02/03/2014 01:34 AM, poma wrote: What's the better way to deal with this phenomenon? The first step would be to build verbose such that you see where the error actually occurs. … Making all in api make[4]: Entering directory `/home/poma/rpmbuild/BUILD/ModemManager-1.2.0/docs/reference/api' DOC Preparing build DOC Scanning header files DOC Introspecting gobjects DOC Rebuilding template files DOC Building XML /bin/sh: -chmod: command not found DOC Building HTML DOC Fixing cross-references make[4]: Leaving directory `/home/poma/rpmbuild/BUILD/ModemManager-1.2.0/docs/reference/api' Making all in libmm-glib make[4]: Entering directory `/home/poma/rpmbuild/BUILD/ModemManager-1.2.0/docs/reference/libmm-glib' DOC Preparing build DOC Scanning header files DOC Introspecting gobjects DOC Rebuilding template files DOC Building XML /bin/sh: -chmod: command not found DOC Building HTML DOC Fixing cross-references In general /bin/sh: -chmod indicates a makefile fragment is being invoked as shell code instead of make-code. One classical cause would be using leading spaces instead of a leading tab in a makefile. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Karma request: LibreOffice
On 12/18/2013 09:03 AM, Adam Williamson wrote: Hi folks! can people please test and up-karma https://admin.fedoraproject.org/updates/libreoffice-4.1.4.2-1.fc20 ? LO is currently newer in F19 stable than F20 stable, and it's causing some weird dep issues when people try to yum distro-sync to F20. We are seeing these issues ever since Fedora is around. Why hasn't Fedora's release process been fixed to prevent such incidents happen? Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Karma request: LibreOffice
On 12/18/2013 02:58 PM, Bob Lightfoot wrote: On 12/18/2013 08:35 AM, Ralf Corsepius wrote: Because Ralf foo-1.0.fc18.rpm ; foo-1.0.fc19.rpm ; foo-1.0.fc20.rpm are considered 3 separate packages and each must be reviewed and moved to stable. Depending on resources foo-1.0.fc18.rpm might reach stable before foo-1.0.fc19.rpm. There presently is no mechanism to cross-link that I am aware of. And to make f19 users wait for an f20 before deploying the next release also has some disadvantages. At least that's my understanding. Right, nobody denies it's non-trivial, but ... regret if I am sounding bitter and fed up, Fedora's release management only had 10 years to take care about these issues. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Recommended system requirements for f20 not sufficient?
On 12/18/2013 08:03 PM, Adam Williamson wrote: On Wed, 2013-12-18 at 15:03 +0100, Dennis Jacobfeuerborn wrote: Hi, i just booted the live iso in a VM with 1G of memory and after I start Software the VM locks up completely after a few seconds. Having top open while starting Software shows very little free/cached RAM left over before the system dies so I upped the RAM of the VM to 2G and with that the problem disappears. It looks like the 1G of RAM recommended on http://fedoraproject.org/ really aren't sufficient to run the basic stuff and this should be updated to probably 1.5-2G RAM or at least 1G RAM + some swap. Well, I did some testing during F20 cycle which seems to indicate F20 Shell takes up a lot more memory than F19 when using llvmpipe. We're not sure exactly what's going on yet, I need to find time to circle back and investigate, but I suspect '1GB in a VM' and '1GB on metal' will be somewhat different experiences. 1GB is getting a bit thin for the default desktop with the current typical requirements of GNOME, FF and LO, though, yeah. FWIW: F20 runs without many problems on 512k RAM: # cat /proc/meminfo MemTotal: 508392 kB MemFree: 127952 kB # cat /etc/fedora-release Fedora release 20 (Heisenbug) However, this is a system on which Fedora was installed long time ago gradually upgraded to f20. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: xfce does not remember saved sessions on Fedora 20
On 12/16/2013 11:38 PM, Kevin Fenzi wrote: I'm still scratching my head over the other applications not saving/restoring correctly, Next probably genuine xfce bug: thunar File Manager windows do not get restored to their position they had carried before. Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1043806 Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: any report of fedup f19-f20?
On 12/18/2013 08:12 AM, Chris Murphy wrote: On Dec 17, 2013, at 11:37 PM, Chris Murphy li...@colorremedies.com wrote: Yeah I just did an F18 live desktop install to kvm, installed 0.7.3-4, ran it with: fedup --network 20 --debuglog fedupdebug.log The download is fine. The grub.cfg is correct. The reboot fails and before I can read anything it reboots and the grub.cfg has changed such that the fedup option isn't present. The screen shots I captured of the reboot failure shows a couple hints: https://dl.dropboxusercontent.com/u/3253801/fedupfailss1.png https://dl.dropboxusercontent.com/u/3253801/fedupfailss2.png That looks to me like the initramfs possibly doesn't contain the right root. Weird. /system-upgrade-root exists so the 2nd screen shot complaint indicating it doesn't is bogus. The next complaint, that /system-upgrade-root/sysimage is true, it doesn't exist. The debug log shows: [ 5678.220] (II) fedup.sysprep:setup_upgraderoot() creating upgraderoot dir: /system-upgrade-root An earlier screenshot of boot shows: dracut-pre-pivot: Warning: UPGRADEROOT isn't unset, can't save initramfs If anyone else is having such errors, is your rootfs btrfs by any chance? I am also observing these messages. No, my rootfs is ext4, not btrfs. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: xfce does not remember saved sessions on Fedora 20
On 12/16/2013 11:38 PM, Kevin Fenzi wrote: I'm still scratching my head over the other applications not saving/restoring correctly, but xfce4-terminal at least is fixed in an update I just pushed. Thanks for taking care about this issue. Testing and karma welcome: https://admin.fedoraproject.org/updates/xfce4-terminal-0.6.2-3.fc19 So far, I've only given the x86_64.fc19 version a try. - xfce4-terminals now seem to be saved and restored correctly. - Same issues with gnome as before. E.g. ghex, gedit get restored on last active workspace before log-out (The workspace the log-out was performed), instead of the workspace they were placed on before log-out. - No issues with firefox and thunderbird. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: xfce does not remember saved sessions on Fedora 20
On 12/14/2013 06:14 AM, Ralf Corsepius wrote: On 12/13/2013 05:48 PM, Kevin Fenzi wrote: On Fri, 13 Dec 2013 17:04:01 +0100 Ralf Corsepius rc040...@freenet.de wrote: When re-loggin in, - sometimes, *all* saved apps appear on virtual workspace 1, plastered on top of each other. Some more details after some experiments with newly created, local accounts on f19 and f20: - instead of getting restored at their former positions, xfce-terminals always pop up on random positions on workspace 1 - gnome-terminals don't seem to be saved at all and do not get restored. They vanish. - firefox and thunderbird do get restored correctly. From this, I conclude, xfce-terminal and gnome-terminal are both broken in different ways. Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1043178 Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: xfce does not remember saved sessions on Fedora 20
On 12/14/2013 06:20 PM, Kevin Fenzi wrote: Also, from re-reading the info in this thread, in addition to the xfce4-terminal bug, it sounds like perhaps recently all gnome based stuff isn't saving at all? (liferea, gnome-terminal, etc) I wonder if something changed recently in gtk3 session saving... will try and look into it. I am observing - some seem to be restored on the last active workspace (e.g. ghex, gedit, rhythmbox, totem) - some seem to be restored correctly (e.g. gnome-calculator) - gnome-terminals do not get restored. Other apps, which do not get restored: vlc, projectx. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: xfce does not remember saved sessions on Fedora 20
On 12/13/2013 04:09 PM, nonamedotc wrote: I believe this happened before recently - XFCE does not remember sessions anymore. I tried clearing the ~/.cache/sessions/* and restarting the system - this does not affect the behavior in any way. Is anyone else seeing this? Yes, I am. Both under F19 and F20! How can I troubleshoot this and what information should I provide for getting to the root of this? I have no idea. I've been playing with various of the usual suspects, which used to work in the past, but no success on F19/20 so far. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: xfce does not remember saved sessions on Fedora 20
On 12/13/2013 05:48 PM, Kevin Fenzi wrote: On Fri, 13 Dec 2013 17:04:01 +0100 Ralf Corsepius rc040...@freenet.de wrote: On 12/13/2013 04:09 PM, nonamedotc wrote: I believe this happened before recently - XFCE does not remember sessions anymore. I tried clearing the ~/.cache/sessions/* and restarting the system - this does not affect the behavior in any way. Is anyone else seeing this? Yes, I am. Both under F19 and F20! How can I troubleshoot this and what information should I provide for getting to the root of this? I have no idea. I've been playing with various of the usual suspects, which used to work in the past, but no success on F19/20 so far. Odd. I do not see this here (with rawhide), nor have I gotten any bugs on it. ;( So, can you folks pinpoint about when it started doing that? (perhaps it's an update that caused it?) Unfortunately, no. All I can say, *automatic session* saving already was flakey during f17/f18, but since having upgraded to f19 it almost never works. Also, the symptoms I am observing seem not consistent and non-systematic/non-deterministic. I usually work with 6 virtual workspaces and use automatic session saving, typically with many terminals (gnome-terminal and xfce-terminal) and very few GUI apps (e.g. thunderbird, firefox, nautilus, vlc) spread across these virtual workspaces. Also, I often su to other accounts in some of these terminals and often ssh'ed into other machines inside of these terminals. Furthermore, I am using nfs/yp/automounted homes. When re-loggin in, - sometimes, *all* saved apps appear on virtual workspace 1, plastered on top of each other. - sometimes, I end up with an empty workspace. - sometimes, some GUI-apps seem to be restored, but the terminals aren't. - on one machine My guess would, be there are several issues interacting, with xfce only being one part of the game. SELinux (I have been observing sealerts referring to /home/user with homes being shared between f19 and f20), systemd and something related to the GPU (kernel or x-server) definitely are involved on occasion. If you pull up prefs- sessions and startup what do you have checked there? X Automatically save session on logout X Prompt on logout In -Advanced: X Launch Gnome Services Everything else is unchecked. [That's part of what I was referring to as usual suspects - I have been playing with these settings, but ... no deterministic improvements, so far.] If you go to the Session tab and click 'save session' does the ~/.cache/session* files get updated? Yes, it does. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
systemd-journald flush hangs system
Hi, I am facing a weird issue on an f20 test system: During a yum update in an attempt to update this machine from the status ca. a week ago to today's, a message appears: # yum update ... systemd-journald[...]: Received request to flush runtime journal from PID 1 [hangs] After this message, the system appears to be hung and non-responsive. The yum process hangs, Ctl-Alt-FX doesn't work, no visible disk activity. However, pressing the power-off button seems to trigger a proper systemd-controlled shutdown. What is going on? Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: systemd-journald flush hangs system
On 12/11/2013 03:04 PM, Jóhann B. Guðmundsson wrote: On 12/11/2013 01:50 PM, Ralf Corsepius wrote: Received request to flush runtime journal from PID 1 With limited info it could be the kernel or it could simply be short on space on /var ? No. Though this is a small RAM and small disk system, space doesn't seem to be the issue, this time. Follow http://freedesktop.org/wiki/Software/systemd/Debugging/ and see if you get something more meaningful Though this issue meanwhile has happened 3 times, I am still pretty clueless. I can't spot anything remarkable or deterministic error message in /var/log/messages (rsp. journalctl). The only noteworthy systemd messages, I am observing is frequent messages of this kind in /var/log/messages: ... Dec 11 16:57:02 gunvald1 dbus-daemon: dbus[580]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' Dec 11 16:57:02 gunvald1 dbus-daemon: dbus[580]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory. Dec 11 16:57:02 gunvald1 dbus[580]: [system] Activating via systemd: service name='org.freedesktop.ModemManager1' unit='dbus-org.freedesktop.ModemManager1.service' Dec 11 16:57:02 gunvald1 dbus[580]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory. ... However, when the hanger happened for the 3rd time, I was logged in from remote. From this, I can tell the system is still alive, except that the console appears to be gone. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedup test?
On 10/18/2013 09:28 AM, Ed Greshko wrote: Never mind. It seems that mirror probably hadn't been synced yet Though this likely is true, it means Fedora's mirrormanager doesn't work properly. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Moving away from reporting to RH bugzilla and adopting pure upstream reporting mantra.
On 09/24/2013 10:25 AM, Jan Wildeboer wrote: That said, I regret having to tell you that your plan is dumb, naive, and far from being workable. That said, I regret having to tell you that insulting the OP instead of pointing out relevant arguments is dumb, naive and far from being helpful. Well, sometimes, there are situations, where there is no other way but to resort to this kind of drastic language to have people comprehend what they are proposing. Johan's proposal is such kind of beyond reason and applicability, it's not even worth being discussed. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Moving away from reporting to RH bugzilla and adopting pure upstream reporting mantra.
On 09/23/2013 11:49 PM, Jóhann B. Guðmundsson wrote: Greetings you all After bit of irc discussion there is a compelling reason to move entirely away from Red Hat bugzilla as well as away from concept of hosting our own. Now it pretty much boils down to this. 1. Generic attitude of many maintainers is that reports either go to the correct place ( upstream ) or they get their bugzilla ignored. 2. More often than not downstream maintainer as in packager does not know the code at all so filling the bug downstream makes no sense since it brings just unnecessary latency to the process. 3. Hosting our own bugzilla cost resources and does not solve 1. or 2. I personally for many years have argued against this since to an reporter it might mean having thousand of accounts but given that we are going through new fase and the times are changing in the linux eco system I would like to get your opinion about we stop reporting altogether in Red Hat bugzilla and report only directly upstream as in kernel bugs to the kernel community, Gnome bugs to theirs, KDE to their etc. The obvious benefit of doing this is that our bugs might actually get look at,dealt with as well as all that being done in a shorter time frame. Thoughts and comment. This kind of discussions have been beaten to death over the years Fedora exits. That said, I regret having to tell you that your plan is dumb, naive, and far from being workable. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Moving away from reporting to RH bugzilla and adopting pure upstream reporting mantra.
On 09/24/2013 03:45 AM, Michal Jaegermann wrote: On Mon, Sep 23, 2013 at 09:49:23PM +, Jóhann B. Guðmundsson wrote: After bit of irc discussion there is a compelling reason to move entirely away from Red Hat bugzilla as well as away from concept of hosting our own. ... Thoughts and comment. This absolutely does not scale from a POV of a user reporting bugs. Exactly, users are reporting bugs against a product called Fedora, not against another party's product called package. In that sense it's a Fedora package maintainer's duty to arbitrate processing bug reports and communicate them to appropriate channels and/or initiate appropriate measures, while keeping the impact on the Fedora user and bug-reporters low. In some situations, this means the package maintainer to implement a patch, in others, to forward a bug report to upstream, in some it may mean to initiate a direct contact between upstream and bug reporter. It's simply another case of there is no size fits all, except that Fedora MUST continue to carry some central address to receiving bug reports on Fedora's bugs. Currently that's bugzilla. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rawhide report: 20130815 changes
On 08/15/2013 04:32 PM, Fedora Rawhide Report wrote: Compose started at Thu Aug 15 08:15:02 UTC 2013 Broken deps for i386 -- [FlightGear] [fgrun] Fallout of the OpenSceneGraph upgrade. Now fixed in rawhide. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Schr@*!dinger*#@s Cat
On 06/11/2013 07:46 PM, Richard Vickery wrote: On Tue, Jun 11, 2013 at 10:31 AM, Chuck Forsberg WA7KGX N2469R c...@omen.com wrote: It seems the name of the Fedora 19 release is getting corrupted in various places. It might be breaking some scripts as well. It might be wise to eliminate the special characters (including the ' ) before final release. -- Chuck Forsberg WA7KGX c...@omen.com www.omen.com Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc The High Reliability Software 10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test I don't think I have any issues with the accents. Rather, I'm sure that I don't. I am facing similar issues as Chuck has. During bootup, bootlogs report to be booting Schrôdingerüs Cat (o circumflex instead of o umlaut and u umlaut instead of '). Same on console prompts: Fedora release 19 (Schrôdingerüs Cat) Are you sure that the corruption issues that you're having are not due to something else? No, I am not sure. localectl on VCs also seems not to work. # localectl System Locale: LANG=en_US.UTF-8 VC Keymap: de-latin1 X11 Layout: de X11 Model: pc105 X11 Options: terminate:ctrl_alt_bksp, This setting works for me on F18, but it apparently doesn't on F19 consoles (The special German keys of my German keyboards don't seem to be honored correctly - e.g. pressing 'ö' (o umlaut) produces a '['). Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Repairing truncated file
On 06/03/2013 02:43 PM, Frank McCormick wrote: On 06/03/2013 01:09 AM, Adam Williamson wrote: On Sun, 2013-06-02 at 19:14 -0400, Frank McCormick wrote: Doesn't work. Erased the offending files and re installed but ldconfig still complains about the truncated file. And what is the ;51a94e8f on the end of the file ? Have you run out of disk space? No 40% used. Wild guess: You might have run out of memory due to /tmp on /tmpfs. I have occasionally hit such issues during yum runs on low RAM machines. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: build control-center in MOCK
On 05/08/2013 04:29 AM, Adam Williamson wrote: On Wed, 2013-05-08 at 06:25 +0400, Igor Gnatenko wrote: Yes. I have internet. I think that mock hasn't /etc/resolv.conf.. I don't think Fedora packages are supposed to require external network access to be built. In general, you can't access a network in mock. A localhost only network sometimes works in some simple cases, but this can easily become unreliable and tedious. That said, its common best practice not to use network-access in rpm.specs. IIRC (I haven't checked), we have a rule disallowing network access in rpm.specs inside the FPG. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Nvidia Drivers
On 01/07/2013 01:16 PM, Lawrence Graves wrote: Nvidia drivers aren't working with the new kernel update. What doesn't work for you? I am having severe issues with both nvidia's drivers on both fc17 and fc18 in combination with Xfce: https://bugzilla.redhat.com/show_bug.cgi?id=883875 Seemingly, this issue is known for many months, but apparently the Xfce and the xorg-x11-server guys doen't seem to be able to find an agreement to fix this issue. Also there is another ooen issue related to F18's dracut and modprobe open unfixed in current F18. ... before somebody mentions nouveau: I gave it a try - It doesn't work reliably on my HW (abrt dump in BZ). Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: imsettings
On 12/20/2012 11:11 PM, Adam Williamson wrote: On Thu, 2012-12-20 at 16:53 -0500, Gene Czarcinski wrote: There are updates available for imsettings. But, something is messed up with a dependency problem. This means that you cannot update a current F18beta. This means that an install fails because of it. The claim is that imsettings-desktop-module(x86_64) = 1.5.1-1.fc18 is required. imsettings-gnome provides imsettings-desktop-module = 1.5.1-1.fc18 Close but not a match. Already known and reported, it's only in updates-testing. Reminds me about asking: Why is updates-testing still activated by default in current f18? It's to some extend appropriate in early development phases, but I don't see any real sense for it in late phases, like the one at the moment. Or differently: Could somebody please add a note to advise people, to disable updates-testing to https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_17_-.3E_Fedora_18 ? Yesterday, I tried another f17-f18 upgrade using the yum method and was hit by the imsettings bug above. Provided I was using a slow and older machine, it took me quite a while to find out what was going on. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: An arbitrarily sized /tmp does not fit all
On 12/20/2012 11:46 PM, Jóhann B. Guðmundsson wrote: On 12/20/2012 09:03 PM, Chuck Forsberg WA7KGX N2469R wrote: For whatever reason Anaconda generates a separate file system for /tmp using an arbitrary size. One one machine it is about 4GB, causing Brasero to fail on larger jobs. Meanwhile there is some 30GB unused in the root filesystem. If /tmp is no longer part of / then its size should be easily adjustable. File a bug against brasero since it should be using /var/tmp these days... This means playing with symptoms. The fix is to disable /tmp on tmpfs. /tmp on tmpfs lacks generality and will only work in a limited subset of installations. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: An arbitrarily sized /tmp does not fit all
On 12/22/2012 08:22 AM, Adam Williamson wrote: On Sat, 2012-12-22 at 08:15 +0100, Ralf Corsepius wrote: On 12/20/2012 11:46 PM, Jóhann B. Guðmundsson wrote: On 12/20/2012 09:03 PM, Chuck Forsberg WA7KGX N2469R wrote: For whatever reason Anaconda generates a separate file system for /tmp using an arbitrary size. One one machine it is about 4GB, causing Brasero to fail on larger jobs. Meanwhile there is some 30GB unused in the root filesystem. If /tmp is no longer part of / then its size should be easily adjustable. File a bug against brasero since it should be using /var/tmp these days... This means playing with symptoms. The fix is to disable /tmp on tmpfs. /tmp on tmpfs lacks generality and will only work in a limited subset of installations. Please keep this pointless regurgitation of old arguments off test@. It's bad enough on devel@. The discussion has been had, and escalated, and settled, and had again, and again. Please just stop it now. Move on. Whether you like it or not, this discussion will reoccur as an FAQ in any Fedora forum maillist after F18 will be released, until /tmp on tmpfs will be reverted or at least be made optional, because the technical limitations remain valid, whether you continue to deny them or not - /tmp on tmpfs lacks generality - period. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Yum update chnages BIOS setting
On 11/24/2012 07:53 AM, Adam Williamson wrote: On Sat, 2012-11-24 at 05:20 +0100, Ralf Corsepius wrote: d) hard and difficult to reproduce you're _really_ going to have to include logs. No luck, yet. So far, I have always found myself with a shredded partition, but haven't found indication for what could have caused the shredding in any log, yet. Some details to report (No idea whether they are related to my sporadic issue): [Preliminary remark: The exteral HD has several different Linuxes distros installed in parallel. It is the drive being booted from.] 1. The external disk seems to have issues with it's id (Here Fedora 16): # ls -l /dev/disk/by-id/ | grep sdb11 lrwxrwxrwx. 1 root root 11 Nov 27 14:29 usb-TOSHIBA_MK8025GAS_†娠㈵ 㝇㠳匹-0:0-part11 - ../../sdb11 2. dmesg reports this (Here: Fedora 16): [ 26.904380] ata_id[762]: HDIO_GET_IDENTITY failed for '/dev/sdb': Invalid argument 3. Fedora 16 and 18 seem to order the drives this way: sda - internal drive sdb - external drive For reasons unknown to me, CentOS6 has this order reversed: sdb - internal drive sda - external drive 4. When additionally having plugged-in a USB-stick while booting, afterwards, different distros see the HD under different device names: Fedora 18: # df | grep /dev/sd /dev/sdc6 12385456 6773000 4983312 58% / /dev/sdc5 495844 42823427421 10% /boot Fedora 16: # df | grep sd /dev/sdb12 12385456 3789344 7966968 33% / /dev/sdb11495844 34269435975 8% /boot CentOS 6 # df | grep sd /dev/sda9 12385456 3418456 8337856 30% / /dev/sda8 495844 31598438646 7% /boot [The disk and the machine are the same in all cases. Of cause, the partitions are different for each distro.] 4. Is something in Fedora using partions by-label? There is a possiblity, the shredded partion's label was identical to a partition label on the external HD. (Since the incident, both disks have been partially repartioned and reformated.) Together, storage.log, program.log and syslog ought to record all relevant actions. storage.log and program.log should record formatting and bootloader writing actions, and syslog should ID the disks. Thanks for the pointer, but so far nothing has caught my eye. There is no possible way we can figure out what happened without the install logs. Correct, that's why I haven't BZ'ed it, yet and am telling you about it, here. This doesn't invalidate the fact, I am experiencing issues of this kind with this particular machine and this particular external HD every now and then (non deterministic, sporatic). However, like I said before, I have not been able to identify the cause and am only wild guessing. is it possible the BIOS is changing the drive order for some reason and you're not noticing? I would not want to exclude this possiblity, but haven't yet found any way to provoke such behavior. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Yum update chnages BIOS setting
On 11/23/2012 12:32 PM, Sergio wrote: --- Em sex, 23/11/12, Chuck Forsberg WA7KGX N2469R c...@omen.com escreveu: De: Chuck Forsberg WA7KGX N2469R c...@omen.com Assunto: Yum update chnages BIOS setting Para: Fedora test@lists.fedoraproject.org Data: Sexta-feira, 23 de Novembro de 2012, 6:50 I have done a few kernel updates of Fedora 18 without major incident until today. This time the BIOS boot order was changed to point to sda instead of sdf where Fedora 18 resides. I noticed when I discovered that the reboot after yum update dumped me into Fedora 16, which couldn't talk to the internet any more. Once I grokked it I changed the BIOS boot drive order back to starting with sdf and things went back to normal. Maybe it's the UEFI thing? Normal BIOS isn't touched by OS updates. Hmm, for quite a while (starting around ca. F15), I have been experiencing boot issues with Fedora, the only explanation I have for, is something in Fedora could be modifying the BIOS or Fedora not being able to interact correctly with the BIOS [1]. Unfortunately, so far I haven't managed to identify the cause of these issues :( Ralf [1] E.g. today, an update of a Fedora 17 installation on an external USB HD-disk seems to have shredded a partition on the main (internal) disk. My wild guess would be BIOS-drive order has changed between installation time and run-time. As things appears to me, something (grub2?) has written to the wrong disk (hdaX instead of hdbX). -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Yum update chnages BIOS setting
On 11/24/2012 04:32 AM, Adam Williamson wrote: On Fri, 2012-11-23 at 16:44 +0100, Ralf Corsepius wrote: On 11/23/2012 12:32 PM, Sergio wrote: --- Em sex, 23/11/12, Chuck Forsberg WA7KGX N2469R c...@omen.com escreveu: De: Chuck Forsberg WA7KGX N2469R c...@omen.com Assunto: Yum update chnages BIOS setting Para: Fedora test@lists.fedoraproject.org Data: Sexta-feira, 23 de Novembro de 2012, 6:50 I have done a few kernel updates of Fedora 18 without major incident until today. This time the BIOS boot order was changed to point to sda instead of sdf where Fedora 18 resides. I noticed when I discovered that the reboot after yum update dumped me into Fedora 16, which couldn't talk to the internet any more. Once I grokked it I changed the BIOS boot drive order back to starting with sdf and things went back to normal. Maybe it's the UEFI thing? Normal BIOS isn't touched by OS updates. Hmm, for quite a while (starting around ca. F15), I have been experiencing boot issues with Fedora, the only explanation I have for, is something in Fedora could be modifying the BIOS or Fedora not being able to interact correctly with the BIOS [1]. Unfortunately, so far I haven't managed to identify the cause of these issues :( Ralf [1] E.g. today, an update of a Fedora 17 installation on an external USB HD-disk seems to have shredded a partition on the main (internal) disk. My wild guess would be BIOS-drive order has changed between installation time and run-time. As things appears to me, something (grub2?) has written to the wrong disk (hdaX instead of hdbX). If you're going to report something that is this a) vague, b) seemingly unlikely and c) important in the apparently unlikely case that it's actually true, d) hard and difficult to reproduce you're _really_ going to have to include logs. No luck, yet. So far, I have always found myself with a shredded partition, but haven't found indication for what could have caused the shredding in any log, yet. There is no possible way we can figure out what happened without the install logs. Correct, that's why I haven't BZ'ed it, yet and am telling you about it, here. This doesn't invalidate the fact, I am experiencing issues of this kind with this particular machine and this particular external HD every now and then (non deterministic, sporatic). However, like I said before, I have not been able to identify the cause and am only wild guessing. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: man files...
On 05/06/2012 02:52 AM, Rob Healey wrote: Greetings: Could someone tell me which is more appropriate to do? place project manual files in: 1) usr/share/man/lang/man1/gramps.1.gz, or 2) /usr/local/share/man/man1/gramps.1 Each man page should accompany the program it documents. i.e. if a program is installed to /usr/bin/ ... /usr/share/man/man1 is the location to host its man-page. if a program is installed to /usr/local/bin ... /usr/local/share/man/man1 is the location to host its man-page. Which format is also better *.gz or *.1 ??? Common sense and common practice is to let packages install uncompressed manpages (*.1, *.2, etc.). In Fedora and other Red Hat-based Linux distributions, these uncompressed man-pages later are automatically gzip-compressed when building the corresponding rpm. Ralf P.S.: I think, this mail is off-topic for this list. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Testing of packages
On 04/27/2012 02:11 PM, Matthias Runge wrote: I wonder how different a run-time test-suite dffers from a test suite to be executed during build. There are 2 major differences: 1. The package-to-test itself is not installed to its final destination. 2. A testsuite being run in %check has access to the source-tree and build-tree. Both together imply a %check testsuite usually accesses different files in a different environment than an installed testsuite would. Apart of this, there are test-cases, which can not be/can not be easily executed inside of a mock-environment as part of building. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: New testcase for installation without selinux
On 01/31/2012 09:00 PM, Adam Williamson wrote: On Tue, 2012-01-31 at 11:43 -0500, Chris Lumens wrote: The installed system must run normally if the user chooses to install without SELinux There is no test case for this now. I have one note on this. There is used noselinux option, but it doesn't work now. I filled bug [2] there is another option with the same effect - selinux=0 and this one works fine, but Anaconda have noselinux in documentation, so it should work and they're working on it. The option to install without selinux was added at a time when selinux was a new, experimental feature in Fedora. Now, it's an integral part of the distribution. It's time for this option to go away. I disagree. Though SELinux isn't in the poor shape it once was, there are still situations, where users prefer or can not avoid to switch off SELinux. If we don't want to support that, the alternative is to ditch the release criterion. I'm okay with that. I am not OK with that. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Well, I've tried GNOME 3 now...
On 04/27/2011 07:13 PM, Bryn M. Reeves wrote: On 04/27/2011 06:01 PM, Ralf Corsepius wrote: On 04/27/2011 05:04 PM, Adam Williamson wrote: On Wed, 2011-04-27 at 09:52 +0200, Ralf Corsepius wrote: On 04/27/2011 07:14 AM, Adam Williamson wrote: On Wed, 2011-04-27 at 06:56 +0200, Ralf Corsepius wrote: Fedora, as a volunteeer effort, cannot. It's worse. I fear Fedora will loose contributors, because Fedora is not shipping the DE these users want. We ship every major currently maintained desktop. Which one do you think is missing? Adam, please. All of this thread is about Gnome 3 not being a replacement for what used to be Gnome 2, Is any other desktop more of a GNOME 2 replacement than GNOME 3? i.e., would changing to another default desktop result in more continuity? I would say not. Agreed. Things have derailed. Now the cart is stuck in the mud In other words Gnome and Fedora (Both projects dominated by a single enterprise) haved decided to switch their target audience. I'll avoid expressing my opinion of this opinion and merely ask: if you are so passionate about the decisions the upstream projects have made why are you not more involved in the development and decision-making that go into them? Pardon, but in case of gnome I am just an ordinary user, who is being confronted with changes in the DE he has been using for many years but now has become unusable for him. This isn't MS or Apple - if you have an opinion express it constructively by getting involved and doing something positive. Well, Gnome and Fedora are like MS and Apple, IMO. Some people draw decisions and press them through at any price, Having watched numerous people start out on a hacking career by getting involved in Gnome and then quickly become very well respected developers (I'd name names but I don't want to make anyone blush ;) I am already involved in many projects and don't have any time left to also get involved in to Gnome. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Well, I've tried GNOME 3 now...
On 04/27/2011 10:21 AM, Ed Greshko wrote: On 04/27/2011 03:52 PM, Ralf Corsepius wrote: On 04/27/2011 07:14 AM, Adam Williamson wrote: On Wed, 2011-04-27 at 06:56 +0200, Ralf Corsepius wrote: Fedora, as a volunteeer effort, cannot. It's worse. I fear Fedora will loose contributors, because Fedora is not shipping the DE these users want. We ship every major currently maintained desktop. Which one do you think is missing? Adam, please. All of this thread is about Gnome 3 not being a replacement for what used to be Gnome 2, I don't think you carefully read what Adam wrote: I did ... my feel Adam doesn't want to understand. We ship every major *currently maintained* desktop. Correct ... IMO, Gnome upstream has derailed, but Fedora is blindly following, telling their users they are dumb and unable to learn. AFAIK, GNOME 2 is no long about to be maintained Therefore it doesn't meet the criteria. I think it is clear The upstream folks at gnome.org aren't interested in maintaining GNOME 2. So, if there is a body of people wanting it, they can take it over. Well, there is a different perspective: If an upstream is doing a bad job and breaking a large numbers of a distro's users expectations, a distro should reconsider its position towards such an upstream and can not avoid to fork. Debian turned aways from libc, SUSE has always followed KDE, ... Many Fedora packagers do so on the package level, when upstreams die or go nuts. That said, I can't deny finding some wisdom in Ubuntu's decision to launch Unity (we will see where this ends). Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Well, I've tried GNOME 3 now...
On 04/27/2011 05:04 PM, Adam Williamson wrote: On Wed, 2011-04-27 at 09:52 +0200, Ralf Corsepius wrote: On 04/27/2011 07:14 AM, Adam Williamson wrote: On Wed, 2011-04-27 at 06:56 +0200, Ralf Corsepius wrote: Fedora, as a volunteeer effort, cannot. It's worse. I fear Fedora will loose contributors, because Fedora is not shipping the DE these users want. We ship every major currently maintained desktop. Which one do you think is missing? Adam, please. All of this thread is about Gnome 3 not being a replacement for what used to be Gnome 2, Is any other desktop more of a GNOME 2 replacement than GNOME 3? i.e., would changing to another default desktop result in more continuity? I would say not. Agreed. Things have derailed. Now the cart is stuck in the mud In other words Gnome and Fedora (Both projects dominated by a single enterprise) haved decided to switch their target audience. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Well, I've tried GNOME 3 now...
On 04/26/2011 05:23 PM, Gerald Henriksen wrote: On Tue, 26 Apr 2011 03:43:55 + (UTC), you wrote: Why did Fedora decide to abandon Gnome 2, instead of offering Gnome 3 as an experimental college-level project via a spin (as one poster here already asked), representing a work-in-progress where geeks still learn their Computer Science principles and skills ? As much as I dislike Gnome 3 and am considering my alternatives, it is very unfair to dump on Fedora for the problems with Gnome 3. Why? I think it's appropriate to dump Fedora because of this, because Fedora has made Gnome 3 it's default desktop and because Fedora is actively promoting it. Do you know that even on Gnome 3 Shell devs (and users) list people admit that they possibly boxed themselves into a corner and now are not willing or able to reverse the course where things went wrong ? It is a Fedora problem, and it will be a Red Hat problem in due time ! Red Hat is fortunate that they can wait and see, and if necessary evaluate the cost/benefit and if necessary allocate resources to the issue. Well, as others already said, the current Fedora 15 desktop is unusable to many people. Kool smartphone kiz and newcomers may like it, as I feel it's unusable for business class use-cases due to its GUI-design. Fedora, as a volunteeer effort, cannot. It's worse. I fear Fedora will loose contributors, because Fedora is not shipping the DE these users want. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Perl test case suggestions?
On 04/07/2011 02:57 PM, James Laska wrote: On Thu, 2011-04-07 at 07:06 +0200, Ralf Corsepius wrote: Anything else to consider? I am not sure what you are aim at. I'm looking for some quick/basic ideas we can turn into test cases on the wiki anchored at https://fedoraproject.org/wiki/Category:Package_perl_test_cases. These tests are then linked in the bodhi updated as suggested tests. While providing karma feedback for perl, I thought it would be handy to have a list of *basic* perl tests available for testers to run (esp since I don't use perl much). OK, somewhat oversimplified, think of perl-module packages as library and plugin packages. Should there be any general considerations for testing them, they may also be applicable to perl module packages. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: yum 3.2.29 translation
On 04/01/2011 11:42 AM, Adam Pribyl wrote:
Running yum update in F15 shows me messages like this:
--- Package upower.i686 0:0.9.8-3.fc15 will be aktualizaci
--- Package upower.i686 0:0.9.9-1.fc15 will be an update
--- Package usbmuxd.i686 0:1.0.6-2.fc15 will be aktualizaci
--- Package usbmuxd.i686 0:1.0.7-1.fc15 will be an update
--- Package vinagre.i686 0:2.91.91-2.fc15 will be aktualizaci
--- Package vinagre.i686 0:2.91.93-1.fc15 will be an update
--- Package vino.i686 0:2.99.3-1.fc15 will be aktualizaci
--- Package vino.i686 0:2.99.5-1.fc15 will be an update
--- Package webkitgtk.i686 0:1.3.12-3.fc15 will be aktualizaci
--- Package webkitgtk.i686 0:1.3.13-1.fc15 will be an update
Looking into .pot file I can not find a
message will be and an udpate.
File output.py line 2041:
_('--- Package %s.%s %s:%s-%s will be %s'), n, a, e, v, r,
It is not present in transifex, nor in
yum git. Same for other messages with new will be sentences.
The po's are outdated.
Somebody (Upstream?) will want to run cd po make update-po
Afterwards you will see this in cs.po (Presuming this is what you are
looking into):
#: ../output.py:2041
#, fuzzy, python-format
msgid --- Package %s.%s %s:%s-%s will be %s
msgstr --- Balíček %s.%s %s:%s-%s nastaven k %s
Ralf
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: Extremly long login time in F15?
On 03/30/2011 07:07 AM, Joachim Backes wrote: Hi, I'm running F15 with gnome-shell. Having the following effect: after having entered the login password, it takes about 10-15 secs until the session is running and the gnome-shell panel appears at the desktop's top. For me, that extreme long: I have a dual core Intel CPU, both with 1.8 Ghz, and 2 Gigs of mem. Somebody can explain this effect? Any autofs/automount or nfs mounted partitions? On F15 with autofs-mounted, nfs-mounted homes I am observing something (seemingly gdm) trying to mount all remote homes in a network. Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: /media directory weirdness
On 07/07/2010 09:22 PM, Ankur Sinha wrote: hi, I'm using a Seagate USB hard drive which is divided into 3 partitions, 2 ext3 and one NTFS. There is new very weird behavior when it comes to directories in the /media folder. The partition names are: Ankur_backup, Stuff, NTFS Temp at times when I plug in my external HDD, the /media dir has Ankur_backup, Stuff, NTFS Temp (all empty) AND Ankur_backup_ , Stuff_ , NTFS Temp_ ( with the files in them) I am observing this behavior as well, not only with usb-sticks/HDDs but with CD/DVDs, also. Is this a known issue? I *always* safely remove the HDD. The trouble is that I can't exactly reproduce what causes these bogus folders to stay. I had observed the same behavior on F12, where I suspected it to be related to using command-line eject and where safely remove seems to have been a mostly functional work-around. On FC13, things seem to be different, ... even with safely remove, I am observing these *_ folders. Any help/pointers would be appreciated. At the moment, I manually remove the empty folders if I see them, and then plug in my HDD. Did you bugzilla it? Ralf -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
