Re: Release criteria proposal: installing / removing software

[drago01]

On Wednesday, July 18, 2018, Chris Murphy  wrote:

> On Tue, Jul 17, 2018 at 3:53 PM, Adam Williamson
>  wrote:
> > On Tue, 2018-07-17 at 14:48 -0700, Adam Williamson wrote:
> >> I instinctively like the non-split form here because, to me, it
> >> emphasizes more clearly that "appropriately" applies to all three
> >> actions.
> >
> > To be clearer here, consider these options:
> >
> > "...to appropriately install, remove and update..."
> > "...to install, remove and update appropriately..."
> > "...appropriately to install, remove and update..."
> >
> > To me, it's at least possible that someone might read the first as if
> > the "appropriately" applies only to the action "install", and the
> > second as if the "appropriately" applies only to the action "update".
> > The third, however, can't really be understood in any way *other* than
> > with "appropriately" applying to all three actions.
>
> Use a colon.
>
> to appropriately: install, remove, and update...
>
> Unambiguous.
>

Just drop "appropriately" and replace it with a footnote. Then there is no
need for all of this discussion and the text is easier to read (also
installing the correct update falls into common sense hence for most people
it will be clear even without reading the footnote).
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/Z4XS4SEMLIR5FVNJ2F6MKGYF6BIN75L6/

Re: Restart of gnome-shell rejceted in a F25 Wayland session

[drago01]

On Sun, Oct 30, 2016 at 9:15 AM, Joachim Backes
 wrote:
> I'm running F25 inside a wayland session, and for curiosity i tried to
> restart gnome-shell with Alt+F2 / r.
>
> This is rejected by a popup "Restart is not available on Wayland".
>
> Really?

Yes. That would be the same as restarting Xorg in a regular X11
session. You would lose your whole session.
So you could as well just relogin.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org

Re: F24 - gnome3 - hidpi any better?

[drago01]

On Fri, May 20, 2016 at 11:13 PM, Adam Williamson
 wrote:
> On Tue, 2016-05-10 at 17:37 +0200, Jaroslav Reznik wrote:
>> On Tue, May 10, 2016 at 4:53 PM, Nikos Roussos 
>> wrote:
>>
>> > On 05/10/2016 03:12 PM, Ankur Sinha wrote:
>> > > Hi,
>> > >
>> > > I just had an email from someone that installed F23 on a box with an
>> > > hidpi screen. Apparently, even using the window scaling etc doesn't
>> > > quite "make it look OK" - has anyone tried F24 with one of these
>> > > screens? Is it any better?
>> > >
>> > > (All I've found are multiple posts suggesting tweak-tool and then a few
>> > > that crib about window scaling options being limited to whole numbers.)
>> >
>> > That's the most common complaint I also hear around hidpi support.
>> > Scaling window accepting only integers and not decimals makes it pretty
>> > much unusable.
>> >
>>
>> Yep, that makes GNOME practically unusable on semi-HDPI screens like Carbon
>> has - you have too small or too big everything. And the worst scenario is
>> when you mix it with FullHD external monitors (at least, this is fixed with
>> Wayland - somehow). Unfortunately Qt guys decided to follow integer only
>> approach (even it's internally implemented as floats) and the only sensible
>> fix is to set font DPI in KDE settings. Also Plasma scales pretty well then
>> and it's possible to find balance between too small on laptop and too big
>> on FullHD :).
>
> Well, the whole point of hidpi is that it's a clever short-cut hack: it
> *can't* use arbitrary scaling factors, because the way it 'scales' is
> simply to sub out the graphical assets.
>
> At scaling factor 2, where you'd normally see a 32x32 icon, it uses a
> 64x64 icon. And so on. It also does text scaling at the same scaling
> factor, and that's basically the entire thing.
>
> It can't do scaling factor 1.6 unless someone draws 51.2x51.2 pixel

There is no such thing as ".2 pixel" which is another reason non
integer scaling does not work. You'd have to round that up or down
resulting into blurriness.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org

Re: [Test-Announce] Fedora 23 Final Release Candidate 9 (RC9) Available Now!

[drago01]

On Thu, Oct 29, 2015 at 8:28 PM, Jan Kurik  wrote:
> I do not want to lower the seriousness of this announcement and request for
> additional testing. However, did not we break the record in number of RCs
> before a release ?

Maybe but we are still on single digit RC ;)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Bugzilla accepts no § character in the password

[drago01]

On Mon, Sep 28, 2015 at 11:27 PM, Adam Williamson
 wrote:
> On Mon, 2015-09-28 at 15:15 -0400, Joerg Lechner wrote:
>> Hi,
>> filed bug 1267005 against Bugzilla, concernng this PW problem with
>> special character "§"
>
> It's not ASCII, which may be the reason? Not a great reason, but a
> reason..

Would be a rather lame reason in 2015 
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F23: "Gnome on Wayland" as login option: some problems with nautilus

[drago01]

On Mon, Sep 28, 2015 at 6:45 PM, Joachim Backes
<joachim.bac...@rhrk.uni-kl.de> wrote:
> On 28.09.2015 18:18, drago01 wrote:
>>
>> On Mon, Sep 28, 2015 at 6:17 PM, Joachim Backes
>> <joachim.bac...@rhrk.uni-kl.de> wrote:
>>>
>>> Hi f23 testers,
>>>
>>> if choosing the "gnome on Wayland" option (on GDM login screen, maybe on
>>> other too), then after login, nautilus is not running
>>>
>>> So, I don't see the desktop icons after login, despite the fact I
>>> configured
>>> the desktop by gnome-tweak-tool so with "icons on desktop" is set to on!
>>
>>
>> This feature is not supported on wayland.
>>
>
> Simple question: where is this documented?

I am afraid there is no such documentation I can think of.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: firewall-applet GTK+ - Qt

[drago01]

On Wed, Jun 17, 2015 at 11:43 PM, Adam Williamson
adamw...@fedoraproject.org wrote:
 On Mon, 2015-06-15 at 15:19 +0200, drago01 wrote:
 On Mon, Jun 15, 2015 at 3:10 PM, Richard Hughes hughsi...@gmail.com
 wrote:
  On 15 June 2015 at 12:12, Thomas Woerner twoer...@redhat.com
  wrote:
   1) The gtk statusicon widget is deprecated in gtk3, will be
   removed soon.
 
  Why do you need a status icon at all? I can't imagine why I'd want
  my
  firewall sending messages to the desktop.
 
   I plan to port firewall-config also over to Qt for one of the
   next releases.
 
  That's completely your choice, but I'm sure it won't help the do
  we
  need firewalld at all on the workstation crowd at all given that
  the
  workstation is predominantly GTK-based.

 Well given that we ship QT by default and there is work being done on
 a QT theme for workstation I don't think written in QT is an
 argument against an app. (whether we need a firewall config tool by
 default or not is a different story).

 Qt is a part of the Workstation flavor by definition: [...]

I know ... that does not contradict what I said ... in fact it backs it up ;)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: firewall-applet GTK+ - Qt

[drago01]

On Mon, Jun 15, 2015 at 3:10 PM, Richard Hughes hughsi...@gmail.com wrote:
 On 15 June 2015 at 12:12, Thomas Woerner twoer...@redhat.com wrote:
 1) The gtk statusicon widget is deprecated in gtk3, will be removed soon.

 Why do you need a status icon at all? I can't imagine why I'd want my
 firewall sending messages to the desktop.

 I plan to port firewall-config also over to Qt for one of the next releases.

 That's completely your choice, but I'm sure it won't help the do we
 need firewalld at all on the workstation crowd at all given that the
 workstation is predominantly GTK-based.

Well given that we ship QT by default and there is work being done on
a QT theme for workstation I don't think written in QT is an
argument against an app. (whether we need a firewall config tool by
default or not is a different story).
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: sizeof - kernel modules

[drago01]

On Mon, Jun 15, 2015 at 7:38 PM, poma pomidorabelis...@gmail.com wrote:

 # du -hs /lib/modules/4.0.5-300.fc22.i686/ | awk '{print $1}'
 42M

 kernel-modules-4.0.5-300.fc22.i686.rpm  ...  17M

 http://dl.fedoraproject.org/pub/fedora/linux/updates/testing/22/i386/k/
 ~~~ ~~ ~  ~~~ ~~ ~  ~~~

 # du -hs /lib/modules/4.1.0-0.rc7.git0.1.fc23.x86_64/ | awk '{print $1}'
 53M

 kernel-modules-4.1.0-0.rc7.git0.1.fc23.x86_64.rpm  ...  18M

 https://kojipkgs.fedoraproject.org/packages/kernel/4.1.0/0.rc7.git0.1.fc23/x86_64/
 ~~~ ~~ ~  ~~~ ~~ ~  ~~~ ~~ ~ 
 ~~ ~~~

 # du -hs /lib/modules/4.1.0-0.rc7.git1.1.fc23.x86_64/ | awk '{print $1}'
 439M

 kernel-modules-4.1.0-0.rc7.git1.1.fc23.x86_64.rpm  ...  218M

 http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/x86_64/os/Packages/k/
 ~~~ ~~ ~  ~~~ ~~ ~  ~~~ ~~ ~ 
 ~~ ~~~ 

 # du -hs /lib/modules/4.1.0-0.rc8.git0.1.fc23.x86_64/ | awk '{print $1}'
 438M

 kernel-modules-4.1.0-0.rc8.git0.1.fc23.x86_64.rpm  ...  218M

 https://kojipkgs.fedoraproject.org/work/tasks/9420/10059420/
 ~~~ ~~ ~  ~~~ ~~ ~


 218 ÷ 18 = 12.1
 439 ÷ 53 = 8.283018868

= 4.1.0-0.rc7.git1.1 cca. 10 x sizeof

Those are debug builds.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: gnome termenal middle-click paste

[drago01]

On Fri, May 8, 2015 at 4:19 AM, Per Bothner p...@bothner.com wrote:


 On 05/07/2015 07:11 PM, Matthew Miller wrote:

 On Thu, May 07, 2015 at 03:05:49PM -0700, Per Bothner wrote:

 It occurred to me:  Maybe this is a problem with Gnome on Wayland.


 It's not just GNOME. It's just plain not-a-thing in Wayland, currently.


 Middle-click paste works on at least some non-Gnome applications, including
 Konsole and Emacs, when running on Gnome-on-Wayland.

Those aren't native wayland apps.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Test-Announce] 2015-04-27 Blocker Review meeting cancelled due to lack of blockers

[drago01]

On Mon, Apr 27, 2015 at 9:05 AM, Adam Williamson
adamw...@fedoraproject.org wrote:
 As it says in the subject, we currently have exactly 0 proposed
 blockers, so no need for a blocker review meeting! Everyone gets extra
 sleep / drinking time. :) Thanks folks! I expect we'll have a review
 meeting next week, as bugs roll in from the TCs.

Does that mean that we have to break more stuff to not bore the QA team? ;)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: nouveau driver freeze -- can anyone else reproduce this?

[drago01]

On Sun, Apr 26, 2015 at 8:03 PM, Matthew Miller
mat...@fedoraproject.org wrote:
 On Sun, Apr 26, 2015 at 07:45:11PM +0200, drago01 wrote:
  It definitely might be model specific. I should also add that I'm in
  Gnome — it might be something with the way the menus are rendered
  there.
 What kind of menu is that? How big is it (height / width in pixels) ?

 It's the right-click context menu you get when clicking on a filename
 in geeqie. It's nothing special -- 14 items in three groups, with View
 in new window being the longest item. 150x300 pixels, maybe?

OK so nothing special about it ... odd.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: nouveau driver freeze -- can anyone else reproduce this?

[drago01]

On Sun, Apr 26, 2015 at 7:38 PM, Matthew Miller
mat...@fedoraproject.org wrote:
 On Sun, Apr 26, 2015 at 06:51:56AM -0400, Joerg Lechner wrote:
 is it possible that this effect is a hardware dependency?
 As I mentioned I have tested this procedure as Matthew has said,
 I didn't find this error. My hardware is an Acer Aspire E 15 with hybrid
 grafics (Intel/Nvidia), but Nvidia does not work with Fedora because of
 the not working Nvidia driver, therefore in Linux the Intel grafics chip
 is the only active (Nouveau driver).

 It definitely might be model specific. I should also add that I'm in
 Gnome — it might be something with the way the menus are rendered
 there.


What kind of menu is that? How big is it (height / width in pixels) ?
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: More dnf adventures (Release blocker?)

[drago01]

On Thu, Apr 23, 2015 at 8:01 AM, Ralf Corsepius rc040...@freenet.de wrote:
 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.

OMG a bug! The sky is falling.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: why are so much gdm processes are running?

[drago01]

On Sat, Apr 11, 2015 at 10:51 AM, Joachim Backes
joachim.bac...@rhrk.uni-kl.de wrote:
 Hi all testers,

 I'm running f22 with gdm as login manager and GNOME SHELL as desktop.
 Now I saw that a lot of processes are running as gdm, although no other
 normal user is logged in.

 For example _gnome-session_ or _gnome-shell_ are running:

That's the gdm session itself. The login manager is just another mode
of gnome-shell.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Auto Login and Logout?

[drago01]

On Thu, Apr 9, 2015 at 11:35 AM, Michael Schwendt mschwe...@gmail.com wrote:
 Does this work as intended?

No.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F22: nautilus will not allow desktop icons if using session type Gnome on Wayland

[drago01]

On Sat, Mar 28, 2015 at 8:12 AM, Joachim Backes
joachim.bac...@rhrk.uni-kl.de wrote:
 On 03/28/2015 08:07 AM, Adam Williamson wrote:

 On Sat, 2015-03-28 at 07:34 +0100, Joachim Backes wrote:

 Changed my session type to Gnome on Wayland. After relogging in, I
 see
 no more desktop icons. Killing nautilus and starting in a
 gnome-terminal, I see the following message:


 ** (nautilus:4636): Warning **: Desktop icons only supported on X11.
 Desktop not created.

 Will this mean that nautilus will not run completely on
 Gnome/Wayland?


 Well, I mean, it means what it says. It can't display icons on
 Wayland. I'm not sure what else you're asking?


 Is this a bug or a feature? Additionally, will this mean that nautilus will
 be never running under wayland?

Nautilus runs just fine under wayland.
It does not support drawing the desktop yet though.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: High CPU on latest nightly

[drago01]

On Thu, Mar 5, 2015 at 11:18 AM, Kamil Paral kpa...@redhat.com wrote:
 On Wed, Mar 4, 2015 at 9:25 AM, Kamil Paral kpa...@redhat.com wrote:
  it's maybe not noticeable in a typical install,
 
  I have Core i7-2640M CPU @ 2.80GHz with 4 cores (2 physical +
  hyperthreading). If I run netinst in KVM with 2 virtual CPUs attached (I
  assign 2 cores instead of 1 to speed up the installation), my host
  performance is *devastated*. I can hardly scroll a web page in Firefox.
  Opening any application takes 5-10 seconds. The longer the installation
  runs, the worse it gets. If I use Live instead of netinst, everything is
  smooth and fast. If I disable the spinner animation using that
  updates.img, it's again smooth.

 That doesn't sound right ... even if the VM would use 100% *all the
 time* it shouldn't have this kind of effects. How are you starting
 your VM? Are you using virt-manager or qemu-kvm in a terminal? The
 the installation runs, the worse it gets.  does not make sense
 either ... unless your system starts swapping ... how much memory does
 your system have? Does it hit swap when you look at top?

 Not saying we shouldn't fix it ... just can't make any sense of those
 symptoms.

 Thanks, drago01, for your interest.

 I use virt-manager with default options (virtio devices, qxl+spice), 2 CPU 
 and 1500 MB RAM assigned to the VM. My host has 8GB RAM and an SSD disk. 
 There's no swapping (I actually have no swap).

 I was actually quite surprised by the performance hit as well. I made a quick 
 snapshot of htop during installation.

 This is with spinner on, during installation phase:
 http://i.imgur.com/KaNDqZR.png
 and during post-install:
 http://i.imgur.com/Tf93BU1.png

 This is with spinner off, during installation phase:
 http://i.imgur.com/4xbryF0.png
 and during post-install:
 http://i.imgur.com/pURu412.png

 I think the difference lies in several aspects:
 * During installation phase, most of the use it single-threaded and there's a 
 lot of IO. During post-install, there are some tasks which are multithreaded 
 (e.g. selinux policy compilation? some gzipping?) and the IO is lighter or 
 none at all during some time periods. That explains why my host system is 
 much more hogged during the end of the installation.
 * With the spinner on, not only qemu uses 200-240% CPU all the time, but I 
 also see 30-45% CPU consumed by virt-manager, 25% CPU by Xorg and 10-15% CPU 
 by gnome-shell. I assume this is caused by an extreme number of (probably 
 full-screen) image redraws submitted by the VM, which in turn are submitted 
 by metacity running inside the VM. If you compare this with the run with 
 spinner off, virt-manager+Xorg+gnome-shell CPU consumption is basically zero.

OK, if you close the vm window (it continues running in the
background) ... does the (host) system feel faster?

 If you add up all the numbers in case of animated spinner, consider that I 
 have just 2 physical CPUs (and the other 2 are just hyperthreading), and 
 imagine I'm trying to browse some ajax-heavy website at the same time, no 
 wonder that my system is completely trashed.

Well the scheduler is supposed to be smarter then that the VM runs
inside its own cgroup as does your user session. Each one should get
an equal CPU share .. so I think the problem is that the drawing
inside the VM affects the host (by having the VM window open/visible).
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: High CPU on latest nightly

[drago01]

On Wed, Mar 4, 2015 at 9:25 AM, Kamil Paral kpa...@redhat.com wrote:
 it's maybe not noticeable in a typical install,

 I have Core i7-2640M CPU @ 2.80GHz with 4 cores (2 physical + 
 hyperthreading). If I run netinst in KVM with 2 virtual CPUs attached (I 
 assign 2 cores instead of 1 to speed up the installation), my host 
 performance is *devastated*. I can hardly scroll a web page in Firefox. 
 Opening any application takes 5-10 seconds. The longer the installation runs, 
 the worse it gets. If I use Live instead of netinst, everything is smooth and 
 fast. If I disable the spinner animation using that updates.img, it's again 
 smooth.

That doesn't sound right ... even if the VM would use 100% *all the
time* it shouldn't have this kind of effects. How are you starting
your VM? Are you using virt-manager or qemu-kvm in a terminal? The
the installation runs, the worse it gets.  does not make sense
either ... unless your system starts swapping ... how much memory does
your system have? Does it hit swap when you look at top?

Not saying we shouldn't fix it ... just can't make any sense of those symptoms.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: High CPU on latest nightly

[drago01]

On Wed, Mar 4, 2015 at 8:05 AM, Adam Williamson
adamw...@fedoraproject.org wrote:
 On Wed, 2015-03-04 at 08:04 +0100, drago01 wrote:
 On Wed, Mar 4, 2015 at 2:40 AM, Adam Williamson 
 adamw...@fedoraproject.org wrote:
  On Tue, 2015-03-03 at 17:00 -0800, Adam Williamson wrote:
   On Tue, 2015-03-03 at 04:59 -0500, Kamil Paral wrote:
 On Mon, 2015-03-02 at 22:46 +, Alexander Bisogianis
 wrote:
   I'm not seeing anything like that on my F22 desktop.
  
 
  I mean while installing F22, all four CPUs on the KVM host
  (F21) are constantly at 100% usage.
 
  Running top in TTY2, while F22 is installing, I see:
 
  Xorg using constantly CPU 60%-70%
  2 anaconda processes using constantly CPU 60%-70%
 
  I can understand anaconda, but Xorg?

 IIRC there's a spinner or something similar visible during
 install; it could well be caused by that. I even think I
 caught some discussion about a patch to disable it during
 automated
 test runs or something in #anaconda the other day...
   
Alexander, try running the installation with this boot option:
   
inst.updates=https://kparal.fedorapeople.org/tmp/no-spinner.img
   
It should disable spinner animation. Then compare the CPU
usage. I still haven't gotten to reporting it as a bug, but
it's true that the spinner seems to be a *gigantic*
performance hog, making all our installations take much
longer, especially in VMs.
  
   Now I come to notice it, GTKSpinners don't seem to spin at all
   in TC7 and TC8. They do spin on my desktop. Not sure if there's a
   package difference or it's a KVM vs. real hardware thing, but
   they're broken with at least both 'vga' and 'qxl' in a KVM. Just
   burning a USB stick to see if it's the same on bare metal.
   Probably GTK+ 3.15.9 is involved.
 
  Huh, it's odder than that - GtkSpinners apparently don't spin in
  GNOME on a KVM, but they *do* spin in the installer environment.

 That's not really a bug. There is a xsettings key
 Gtk/EnableAnimations that gets disabled if the system is using
 software rendering (or if it is a remote system) to improve
 performance.
 There is no full gnome in the installer environment so nothing
 disables the key but in the user session ...

 yeah, mclasen said the same. still, it's a problem that spinners are
 so CPU heavy. it's maybe not noticeable in a typical install, but on
 an openQA setup we have 4-8 installs running simultaneously on a
 single host, and the combination causes major load.

Yeah I am just explaining why it is different between the installer
environment and GNOME.
I am not sure what runs in the installer environment but running
gnome-settings-daemon there would fix it ... the code that handles it
is here:
https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/xsettings/gsd-remote-display-manager.c#n270
 maybe ananconda can do something similar on its own.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: High CPU on latest nightly

[drago01]

On Wed, Mar 4, 2015 at 2:40 AM, Adam Williamson
adamw...@fedoraproject.org wrote:
 On Tue, 2015-03-03 at 17:00 -0800, Adam Williamson wrote:
 On Tue, 2015-03-03 at 04:59 -0500, Kamil Paral wrote:
   On Mon, 2015-03-02 at 22:46 +, Alexander Bisogianis wrote:
 I'm not seeing anything like that on my F22 desktop.

   
I mean while installing F22, all four CPUs on the KVM host
(F21) are constantly at 100% usage.
   
Running top in TTY2, while F22 is installing, I see:
   
Xorg using constantly CPU 60%-70%
2 anaconda processes using constantly CPU 60%-70%
   
I can understand anaconda, but Xorg?
  
   IIRC there's a spinner or something similar visible during
   install; it could well be caused by that. I even think I caught
   some discussion about a patch to disable it during automated
   test runs or something in #anaconda the other day...
 
  Alexander, try running the installation with this boot option:
 
  inst.updates=https://kparal.fedorapeople.org/tmp/no-spinner.img
 
  It should disable spinner animation. Then compare the CPU usage. I
  still haven't gotten to reporting it as a bug, but it's true that
  the spinner seems to be a *gigantic* performance hog, making all
  our installations take much longer, especially in VMs.

 Now I come to notice it, GTKSpinners don't seem to spin at all in
 TC7 and TC8. They do spin on my desktop. Not sure if there's a
 package difference or it's a KVM vs. real hardware thing, but
 they're broken with at least both 'vga' and 'qxl' in a KVM. Just
 burning a USB stick to see if it's the same on bare metal. Probably
 GTK+ 3.15.9 is involved.

 Huh, it's odder than that - GtkSpinners apparently don't spin in GNOME
 on a KVM, but they *do* spin in the installer environment.

That's not really a bug. There is a xsettings key
Gtk/EnableAnimations that gets disabled if the system is using
software rendering (or if it is a remote system) to improve
performance.
There is no full gnome in the installer environment so nothing
disables the key but in the user session ...
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[drago01]

On Wed, Jan 28, 2015 at 5:53 PM, Brian C. Lane b...@redhat.com wrote:

 I *know* this is going to be a bit of a pain to get used to. But the
 increased security is worth it.

Depends ... if you force user to choose a password that they can't
possibly remember you increase the likelihood of them just writing it
on a piece of paper (and in the worst case have it near the computer).
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: fedup f20-f21 kde broken deps

[drago01]

On Sat, Dec 13, 2014 at 11:48 AM, Michael Schwendt mschwe...@gmail.com wrote:
 On Fri, 12 Dec 2014 12:16:34 -0800, Adam Williamson wrote:

 Awesome, so now you have me running a test install of F20 with R just
 to see what happens in this situation. There's certainly no other way I
 could be using my damn morning.

 Well, the problems are real. Unresolvable deps in many cases are equal to
 denial-of-service at runtime, i.e. the programs don't execute.

 In some cases and depending on whether the system survives the reboot, a
 distro-sync may work. Doing downgrades of packages bears even further
 risks, though (and in most cases are completely untested). [For example,
 there are cases where parts of the software and/or packages have converted
 settings and other runtime files already only to run into breakage later
 on, such as a broken component.]

 Btw, this morning I've had fun porting Audacious plugins to the new API.

 We seem to keep going in circles here.

 I hear you well. Going in circles cannot be avoided. My opinion in this
 matter is: If individual package maintainers are not careful enough to
 violate upgrade paths, update release procedures ought to get adjusted.

 It may be that you're happy (so far) with suggesting a distro-sync as a
 preliminary work-around. Users are scared by such extra commands, however,
 especially if Yum asks for confirmation before wanting to remove (!) and
 downgrade packages.

 Violated upgrade paths are an issue all the time. Not only shortly before
 release of next Fedora! There's always some sort of window when packagers
 mass-release upgrades to multiple dists and cause an upgrade race. Sometimes
 just a few days, sometimes a week, sometimes several weeks, if a test update
 is forgotten or withdrawn.  Shortly before a new release of Fedora it can
 be worse, however, because users are not interested in Test Releases that
 are not ready.  They hope for the final release to just work. Meanwhile
 they continue the drill and apply updates daily, and if they happen to
 hear about the new Fedora release, they upgrade from an up-to-date earlier
 release where packages are even newer than in the release they upgrade
 to. If the upgrade method cannot handle that, yes, repeating that won't
 improve it. Facing the facts is necessary, though.

 work, I think it's taking things too far to say that it's worthless to
 test upgrades against updates-testing, which was one place where we
 started this endless debate.

 We two have not been the only participants in this thread.

 *I* haven't claimed that test upgrades to updates-testing are worthless.

 But I claim that the ordinary user doesn't upgrade to updates-testing and
 doesn't want to upgrade to updates-testing due to some of the stuff that's
 dumped in there. Too many updates, too many packages updated too frequently.

 Hey, perhaps even a name change would make that repo less intimidating:
 update-candidates. ;)  A bit of an obfuscation contest, unfortunately,
 and much too lose if such a repo causes severe breakage.  Plain users don't
 want to be the guinea pigs to install Test Updates, which may be entirely
 _untested_. They want the Fedora Project to ensure the quality of
 updates. And quality ensurance needs to start somewhere.  We can't dump
 random upgrades into updates-testing and only hope that withdrawing them
 may be enough. Burnt repo users may be fed up when that happens regularly.

 * The obvious way you can really 'solve' this 'problem' is to tighten
 down the updates policy, but that's not a free action. It *does* come
 with negative consequences and there *will* be pushback against it
 from packagers.

 Of course.

 Personally I am totally happy if anyone wants to come
 up with a comprehensive proposal for adjusting the updates policy and
 *take it to FESCo*, who own the updates policy. If someone comes up
 with such a proposal, we can even put it up for discussion on this
 list or in a QA meeting and decide if QA as a whole wants to back it
 in the FESCo discussion.

 That doesn't work for me.  It doesn't work for me at all, if people hide
 somewhere, are not interested in the topic on this list, and would not be
 informed at all when learning about the topic in a meeting.

 But I'm just tired of going around in endless
 discussion, especially when no-one seems to acknowledge the issue just
 isn't as straightforward as 'oh well it's OBVIOUSLY wrong and we
 should OBVIOUSLY just have strict upgradepath enforcement'.

 Well, early resistance kills all progress. Early.

 Some of this discussion is ridiculous. On one hand, delaying upgrades for
 old dist releases is considered a major problem, because those upgrades
 may be oh-so-important-brown-paperbag-showstopper-fixes. On the other hand,
 for the latest dist release a distro-sync downgrade is suggested, which
 downgrades to old packages where the oh-so-important upgrade is not
 available yet or only in updates-testing. Something's wrong here with
 the 

Re: F21 FInal RC1 - Xfce Sensors Viewer - cannot save changes

[drago01]

On Sun, Nov 30, 2014 at 7:55 PM, Kevin Fenzi ke...@scrye.com wrote:
 On Sun, 30 Nov 2014 13:51:27 -0500
 Robert Moskowitz r...@htt-consult.com wrote:


 On 11/30/2014 01:39 PM, Kevin Fenzi wrote:
  Try this update:
 
  https://admin.fedoraproject.org/updates/xfce4-sensors-plugin-1.2.5-1.fc21
 
  and see if it improves things.

 Well, I can get to this web page, but I don't see what I have to do
 to install it...

 I just submitted it, so it's not in updates-testing yet, but if you
 wait until tomorrow it should appear there and you can do:
 'yum --enablerepo=updates-testing update xfce4-sensors-plugin'

 Or you could follow the 'builds' link from the top of the update page
 and download from koji and yum update the rpm.

Just for the record you could just do

yum install http://.../whatever.rpm

it will do the downloading and everything for you.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Mongodb-server fails to start with selinux enforcing

[drago01]

On Wed, Nov 19, 2014 at 6:19 PM, Daniel J Walsh dwa...@redhat.com wrote:

 On 11/19/2014 09:16 AM, Paul Knox-Kennedy wrote:
 On a clean installation built from
 Fedora-Live-Workstation-x86_64-21_Beta-4.iso, I installed mongodb-server
 but it failed to start due to selinux: SELinux is preventing mongod
 from name_bind access on the tcp_socket port 27017.

 Following the selinux instructions from the journal resolves this:
 # grep mongod /var/log/audit/audit.log | audit2allow -M mypol
 # semodule -i mypol.pp

 Should I bugzilla this, and if so, is it against mongodb or
 selinux-policy?
 Is this a standard port the mongodb should be listening on?

http://docs.mongodb.org/manual/reference/default-mongodb-port/

Seems like the answer is yes.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Resume still broken on Thinkpad X1 Carbon

[drago01]

On Tue, Nov 18, 2014 at 8:54 PM, valent.turko...@gmail.com
valent.turko...@gmail.com wrote:
 Thanks to this bugreport [1] now suspend and resume work as expected
 on Fedora 21, finally!

 Issue was with missing TPM modules! One solution would be to disable
 TPM in EFI/BIOS and other to install missing kernel-modules-extra
 package.

 Now resume finally works!

 Also suspend now takes almost twice long, and screen blinks quite few
 more times like this: on-pressed_suspend-off-on-off-on-off

 But main thing is that both suspend and resume work now as expected.

 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1164937

OK that means that tpm shouldn't be in modules-extra
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Test-Announce] Fedora 21 Beta Release Candidate 1 (RC1) Available Now!

[drago01]

On Fri, Oct 24, 2014 at 9:31 AM, Kamil Paral kpa...@redhat.com wrote:
 As per the Fedora 21 schedule [1], Fedora 21 Beta Release Candidate 1
 (RC1) is now available for testing. Content information, including
 changes, can be found at
 https://fedorahosted.org/rel-eng/ticket/6010#comment:11 . Please see the
 following pages for download links (including delta ISOs) and testing
 instructions. Normally dl.fedoraproject.org should provide the fastest
 download, but download-ib01.fedoraproject.org is available as a mirror
 (with an approximately 1 hour lag) in case of trouble. To use it, just
 replace dl with download-ib01 in the download URL.

 Since freenode is not working for me (netsplit), I have to ask here - there 
 are no Workstation netinst images for RC1? Also I noticed there is no os/ 
 directory for them.

That's intentional. See
http://meetbot.fedoraproject.org/fedora-meeting/2014-10-22/workstation.2014-10-22-15.00.html
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Expected Kernel Panic?

[drago01]

On Mon, Oct 13, 2014 at 10:52 AM, Ed Greshko ed.gres...@greshko.com wrote:
 This is with F21 Beta TC3 KDE Live.

 I ran the install to disk function.  Upon completion I hit Quit.  After 
 hitting quit and waiting a few seconds, instead of doing a shutdown I 
 powered off the VM thinking (expecting) everything to have been complete.  
 However, when I boot the system I get a panic.

 The last line on the screen reads

 ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on 
 unknown-block(0,0)

 Is that considered normal?

No.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: wpa_supplicant - Koji Buildsystem - No search results

[drago01]

On Tue, Oct 7, 2014 at 8:27 PM, poma pomidorabelis...@gmail.com wrote:

 http://koji.fedoraproject.org/koji/search?terms=wpa_supplicanttype=packagematch=glob

Seems to be caused by the _ try using a wildcard instead i.e wpa*supplicant
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Some F21 Alpha impressions

[drago01]

On Mon, Oct 6, 2014 at 7:58 PM, Jonathan Corbet corbet...@lwn.net wrote:

 The HiDPI pixel scaling stuff seems to be full of surprises, though.  I've
 been exploring the intersection with external monitors, which is...not
 fully pleasing.

Yeah this is a major limitation which is pretty much impossible to fix
under X11. We can do better on wayland (we currently don't but
hopefully will for gnome 3.16).
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Emacs (was: Some F21 Alpha impressions)

[drago01]

On Sun, Oct 5, 2014 at 4:05 PM, Jonathan Corbet corbet...@lwn.net wrote:
 On Sat, 4 Oct 2014 21:02:15 +0200
 drago01 drag...@gmail.com wrote:

 Do you have a screenshot of the wrong looking emacs?

 Attached, finally.  Took me a while to get back to a nominally working
 system after the scaling experiment - had to go to backups in the end.
 Whatever gnome-tweak-tool tweaks in that case, it's not a simple
 reversable transformation.

Ugh ... I though it would be easier to direct you to tweak tool but
apparently accessing the setting directly would have been a better
idea.
Sorry for that. All that tweak tool does is to set a value in
gsettings which you can do using::

gsettings set org.gnome.desktop.interface scaling-factor value for instance
gsettings set org.gnome.desktop.interface scaling-factor 1 and go back using
gsettings set org.gnome.desktop.interface scaling-factor 0 or
gsettings reset org.gnome.desktop.interface scaling-factor

 Anyway, here's an Emacs window being resized; it thinks it's 39x18,
 but, as can be seen, it's actually a little more than double that in
 both directions.

Oh ok. Well seems like emacs somehow gets this wrong while
gnome-terminal doesn't. The scaling is supposed
to be transparent to applications though so looks like a gtk bug. Can
you file one (upstream if possible) ?

 Setting GDK_SCALE=1 makes Emacs behave rationally, thanks!

OK good to hear. What this does is disabling the scaling for emacs but
leave the rest of the desktop / other applications alone.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Emacs (was: Some F21 Alpha impressions)

[drago01]

On Sat, Oct 4, 2014 at 7:42 PM, Adam Williamson
adamw...@fedoraproject.org wrote:
 On Sat, 2014-10-04 at 18:20 +0200, Michael Schwendt wrote:
 On Sat, 4 Oct 2014 10:08:21 -0400, Jonathan Corbet wrote:

   - Emacs is *totally* confused about its window size.  Any new window
 comes up essentially full screen, but the sizes it shows when one
 resizes indicates that it thinks its window is quite small - even
 though text display works just fine.  F20 shows this too, it's not an
 F21 specific thing.

 Cannot reproduce. Emacs hasn't changed here anything like that for a very
 long time. Even if I remove my current .emacs file, it starts up in the
 same way.  Only thing I've added to my notes is, I still need to install
 the xorg-x11-fonts-misc package for my font customisations.

 It may be something to do with the hiDPI screen on the Carbon, and
 possibly with GNOME's interface scaling that deals with that. Is it just
 that the window is scaled to 4x the size emacs reports?

Afaik emacs doesn't use gtk3 and thus does not get any hidpi scaling.
The font size is just doubled. That *shouldn't* affect the window size
but it might.

Jonathan can you try to install gnome-tweak-tool and set the scaling
factor to 1 (warning: everything will be smaller) to verify that
(default is 0) ?
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Question about the gnome3 restart dialog

[drago01]

On Fri, Oct 3, 2014 at 10:54 AM, Joachim Backes
joachim.bac...@rhrk.uni-kl.de wrote:
 On 10/03/2014 10:51 AM, Joachim Backes wrote:
 Sometimes, if rebooting my box by the upper right gnome3 menu, there is
 some additional toggle button in the appearing popup (besides the OK,
 Cancel, ... buttons) : Install pending software updates?. If I
 activate this toggle button, then during the boot process a message
 shortly appears  saying that updates are installed, but nothing about
 which updates. Later on, if my box is running, I find no info in
 /var/log/yum.log.

 So, how to get more info about this updates?

 Kind regards

 Joachim Backes



 Sorry, I forgot to mention that I'm running f21.


You should get a notification after login that tells you that updates
have been installed.
It has a button which opens gnome-software where you have a list of
the updated components / apps.

It does not use yum so there is nothing in yum.log
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Sound problems with skype in F21

[drago01]

On Thu, Sep 18, 2014 at 1:52 PM, John Dulaney
jdula...@fedoraproject.org wrote:
 To: test@lists.fedoraproject.org
 From: rdie...@math.unl.edu
 Subject: Re: Sound problems with skype in F21
 Date: Thu, 18 Sep 2014 06:46:53 -0500

 Temlakos wrote:

  That suggests when I do the upgrade from F20-F21, I should use
  pulseaudio with no latency. True?

 Do you even need it on F20 anymore?

 (perhaps skype has been fixed to not require that workaround)

 -- Rex


 Skype for Linux hasn't been updated in a long time.

http://blogs.skype.com/2014/06/18/skype-4-3-for-linux/ ... 3 months
ago is not that a long time also PulseAudio 3.0 and 4.0 support
that's the fix for the latency issue.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: how to start qemu:///system hypervisor?

[drago01]

On Fri, Sep 12, 2014 at 11:18 AM, Robert P. J. Day
rpj...@crashcourse.ca wrote:

   i suspect this has an easy answer but playing with virtualization
 for the first time in a while, installed what i think are all the
 necessary packages, and just want to test virt-manager, so i run

  $ virt-manager

 am prompted for password, then:

   Unable to connect to libvirt.
no connection driver available for qemu:///system

 and the VMM window displays:

   localhost (QEMU) - Not Connected

 is this a permission problem? have i not started the appropriate
 system unit?

   i've already done a group install of virtualization, i can see the
 appropriate modules are loaded on this intel quad core i7:

 $ lsmod | grep kvm
 kvm_intel 152115  0
 kvm   492841  1 kvm_intel
 $

   what embarrassingly obvious step have i overlooked? thanks.

systemctl start libvirtd.service
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Test-Announce] Fedora 21 Alpha Test Compose 6 (TC6) Available Now!

[drago01]

On Sun, Sep 7, 2014 at 6:00 AM, Adam Williamson
adamw...@fedoraproject.org wrote:
 On Fri, 2014-09-05 at 14:56 -0600, Orion Poplawski wrote:
 On 09/05/2014 01:03 AM, Andre Robatino wrote:
  As per the Fedora 21 schedule [1], Fedora 21 Alpha Test Compose 6 (TC6)
  is now available for testing.

 Minor nit, but can we try for consistent naming?  Thanks.  We've had:

 F21a-TC1/
 21-Alpha-T2/2014-07-21 01:59-
 21-Alpha-TC3/   2014-08-23 03:32-
 21-Alpha-TC4/   2014-08-26 04:58-
 21-Alpha-TC5/   2014-08-30 04:38-

 and now:

 21_Alpha_TC6/   2014-09-05 06:06-

 The changes are all intended, not accidental.

Because ?
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Test-Announce] Fedora 21 Alpha Test Compose 6 (TC6) Available Now!

[drago01]

On Sun, Sep 7, 2014 at 10:47 AM, Adam Williamson
adamw...@fedoraproject.org wrote:
 On Sun, 2014-09-07 at 19:39 +1200, Gavin Flower wrote:
 On 07/09/14 19:13, drago01 wrote:
  On Sun, Sep 7, 2014 at 6:00 AM, Adam Williamson
  adamw...@fedoraproject.org wrote:
  On Fri, 2014-09-05 at 14:56 -0600, Orion Poplawski wrote:
  On 09/05/2014 01:03 AM, Andre Robatino wrote:
  As per the Fedora 21 schedule [1], Fedora 21 Alpha Test Compose 6 (TC6)
  is now available for testing.
  Minor nit, but can we try for consistent naming?  Thanks.  We've had:
 
  F21a-TC1/
  21-Alpha-T2/2014-07-21 01:59-
  21-Alpha-TC3/   2014-08-23 03:32-
  21-Alpha-TC4/   2014-08-26 04:58-
  21-Alpha-TC5/   2014-08-30 04:38-
 
  and now:
 
  21_Alpha_TC6/   2014-09-05 06:06-
  The changes are all intended, not accidental.
  Because ?
 Because !!!   :-)

 Actually, I don't know and am also curious.

 I prefer the hyphenated name.

 21 Alpha TC3 is really one long version string, not separate elements in
 the way 'Fedora' and 'Workstation' are separate elements, for e.g.

 the discussion about naming is on the releng list, though.

Well I don't really care about the name ... but I agree that it should
be consistent and not be chosen randomly each time.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Test-Announce] Fedora 21 Alpha Test Compose 6 (TC6) Available Now!

[drago01]

On Sun, Sep 7, 2014 at 6:41 PM, Adam Williamson
adamw...@fedoraproject.org wrote:
 On Sun, 2014-09-07 at 12:52 +0200, drago01 wrote:
 On Sun, Sep 7, 2014 at 10:47 AM, Adam Williamson
 adamw...@fedoraproject.org wrote:
  On Sun, 2014-09-07 at 19:39 +1200, Gavin Flower wrote:
  On 07/09/14 19:13, drago01 wrote:
   On Sun, Sep 7, 2014 at 6:00 AM, Adam Williamson
   adamw...@fedoraproject.org wrote:
   On Fri, 2014-09-05 at 14:56 -0600, Orion Poplawski wrote:
   On 09/05/2014 01:03 AM, Andre Robatino wrote:
   As per the Fedora 21 schedule [1], Fedora 21 Alpha Test Compose 6 
   (TC6)
   is now available for testing.
   Minor nit, but can we try for consistent naming?  Thanks.  We've had:
  
   F21a-TC1/
   21-Alpha-T2/2014-07-21 01:59-
   21-Alpha-TC3/   2014-08-23 03:32-
   21-Alpha-TC4/   2014-08-26 04:58-
   21-Alpha-TC5/   2014-08-30 04:38-
  
   and now:
  
   21_Alpha_TC6/   2014-09-05 06:06-
   The changes are all intended, not accidental.
   Because ?
  Because !!!   :-)
 
  Actually, I don't know and am also curious.
 
  I prefer the hyphenated name.
 
  21 Alpha TC3 is really one long version string, not separate elements in
  the way 'Fedora' and 'Workstation' are separate elements, for e.g.
 
  the discussion about naming is on the releng list, though.

 Well I don't really care about the name ... but I agree that it should
 be consistent and not be chosen randomly each time.

 It's not randomly chosen, we're iterating towards a naming scheme that
 doesn't suck.

OK fair enough.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: What's wrong with Fedora 21 GNOME?

[drago01]

On Tue, Aug 26, 2014 at 9:57 PM, Michael Schwendt mschwe...@gmail.com wrote:
 Is only my installation broken?

 Do any of the (GNOME) developers run Fedora 21 actually?

Some do ...

 Where is the menu of Evince? Its Help system refers to it (top right
 corner), but I can't find it. Searching for it with various clicks of the
 right mouse-button, I managed to freeze the GNOME Shell and get more than
 one black Minimize Maximize Move ... popup menu.

 What's the reason for other changes? GNOME Shell's Favourites bar at the
 left: Why do I need to press'n'hold the right mouse button now in order to
 select something from the popup menu?

That sounds like a bug.

  Why is it no longer possible to
 open new gnome-terminal windows but only be offered access to the single
 open one? Am I really supposed to Launch more instances via the
 Show Details feature? That would be odd.

Looks like fallout from
https://git.gnome.org/browse/gnome-shell/commit/?id=3182aba744e7d64ecf71dfdbb5f5b1fa663325dc
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: What's wrong with Fedora 21 GNOME?

[drago01]

On Tue, Aug 26, 2014 at 10:02 PM, drago01 drag...@gmail.com wrote:
 On Tue, Aug 26, 2014 at 9:57 PM, Michael Schwendt mschwe...@gmail.com wrote:
 Is only my installation broken?

 Do any of the (GNOME) developers run Fedora 21 actually?

 Some do ...

 Where is the menu of Evince? Its Help system refers to it (top right
 corner), but I can't find it. Searching for it with various clicks of the
 right mouse-button, I managed to freeze the GNOME Shell and get more than
 one black Minimize Maximize Move ... popup menu.

 What's the reason for other changes? GNOME Shell's Favourites bar at the
 left: Why do I need to press'n'hold the right mouse button now in order to
 select something from the popup menu?

 That sounds like a bug.

  Why is it no longer possible to
 open new gnome-terminal windows but only be offered access to the single
 open one? Am I really supposed to Launch more instances via the
 Show Details feature? That would be odd.

 Looks like fallout from
 https://git.gnome.org/browse/gnome-shell/commit/?id=3182aba744e7d64ecf71dfdbb5f5b1fa663325dc

Filed https://bugzilla.gnome.org/show_bug.cgi?id=735479
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: the 'Software Installer' and Adobe Flash

[drago01]

On Sat, Aug 16, 2014 at 5:08 PM, drago01 drag...@gmail.com wrote:
 On Sat, Aug 16, 2014 at 4:49 PM, Michael Schwendt mschwe...@gmail.com wrote:
 Assume a new installation (Fedora 21 branched) where Adobe Flash Player is
 not installed yet.

 Visiting a website that requires the newest version of the Flash Plugin,
 there is an option to Download that plugin. Following the link to Adobe,
 Linux is correctly recognized by default,
   
 http://get.adobe.com/de/flashplayer/download/?installer=Flash_Player_11.2_for_other_Linux_%28YUM%29_64-bitstandalone=1
 but choosing the Yum version and trying to install it with Fedora's
 Software Installer, this doesn't lead much further.

 Obviously, one only gets the Yum .repo definition package from Adobe, but
 if one must install the Flash Plugin manually, the Software Installer
 application at least ought to make that possible, too. It doesn't find
 anything when searching for flash. Looking closer, it doesn't find
 anything at all.

 What is broken here?

 The flash package lacks an appdate file ...

*appdata*
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: the 'Software Installer' and Adobe Flash

[drago01]

On Sat, Aug 16, 2014 at 4:49 PM, Michael Schwendt mschwe...@gmail.com wrote:
 Assume a new installation (Fedora 21 branched) where Adobe Flash Player is
 not installed yet.

 Visiting a website that requires the newest version of the Flash Plugin,
 there is an option to Download that plugin. Following the link to Adobe,
 Linux is correctly recognized by default,
   
 http://get.adobe.com/de/flashplayer/download/?installer=Flash_Player_11.2_for_other_Linux_%28YUM%29_64-bitstandalone=1
 but choosing the Yum version and trying to install it with Fedora's
 Software Installer, this doesn't lead much further.

 Obviously, one only gets the Yum .repo definition package from Adobe, but
 if one must install the Flash Plugin manually, the Software Installer
 application at least ought to make that possible, too. It doesn't find
 anything when searching for flash. Looking closer, it doesn't find
 anything at all.

 What is broken here?

The flash package lacks an appdate file ...
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: gnome desktop image for arm?

[drago01]

On Wed, Jul 23, 2014 at 8:35 PM, Robert Moskowitz r...@htt-consult.com wrote:

 On 07/23/2014 01:31 PM, John Dulaney wrote:

 Date: Wed, 23 Jul 2014 10:33:47 -0400
 From: r...@htt-consult.com
 To: test@lists.fedoraproject.org
 Subject: gnome desktop image for arm?

 I am looking at:


 http://koji.fedoraproject.org/koji/tasks?state=allview=treemethod=applianceorder=-id

 And do not see a gnome image for f21 arm (let alone any hardware). So
 obviously I am missing how it is encoded in the description.

 How do I find the right f21 armhfp image with gnome?

 xfce is nice, but I DO have 1GB memory

 # cat /proc/meminfo
 MemTotal: 1010204 kB

 And I will want the gnome apps.

 I don't know if Gnome arm images are being spun up or not, but, the
 issue with Gnome on ARM is with the graphics, not necessarily the
 memory.


 Allwinner A20 is suppose to have a fast GPU...

That's not the point does it have a usable 3D driver?
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [DRI3] Problems on old Intel GPUs

[drago01]

On Thu, Jul 3, 2014 at 12:27 AM, František Zatloukal
zatloukal.franti...@gmail.com wrote:
 Many thanks, Gnome Shell still slow but I managed to get Kwin to OpenGL 3.1
 at least.

 @Adam Do I understand it well that DRI3 problems won't be solved on these
 ancient cards?

https://bugzilla.redhat.com/show_bug.cgi?id=1115323#c12
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: xfdesktop general protection error in libgobject

[drago01]

On Tue, Jun 17, 2014 at 10:13 AM, poma pomidorabelis...@gmail.com wrote:

 [...]

Get a backtrace and file a bug.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: DNF utils package?

[drago01]

On Mon, Jun 16, 2014 at 12:16 PM, Tim Lauridsen tim.laurid...@gmail.com wrote:
 dnf builddep currently only work with an local .src.rpm or .spec file, that
 is the most common usecase.

 You can create an RFE in bugzilla against dnf-plugins-core and describe you
 usecase.

 normally, you need to have a locale .spec or .src.rpm to build a package
 locally, so this is properly why dnf builddep has the same requirment

Well you assume that buildep is only used to build packages. But if
you want to build the upstream source of a package for any reason
having a command that installs required packages is handy.

For instance if I want to build foo to write / test a patch I do
yum-builddep foo jhbuild buildone foo ... I have the code, can
hack on it, can build it without messing with deps and do not have to
build a package (development does not always mean packing).
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: DNF utils package?

[drago01]

On Mon, Jun 16, 2014 at 1:35 PM, Tim Lauridsen tim.laurid...@gmail.com wrote:



 On Mon, Jun 16, 2014 at 12:39 PM, drago01 drag...@gmail.com wrote:

 On Mon, Jun 16, 2014 at 12:16 PM, Tim Lauridsen tim.laurid...@gmail.com
 wrote:
  dnf builddep currently only work with an local .src.rpm or .spec file,
  that
  is the most common usecase.
 
  You can create an RFE in bugzilla against dnf-plugins-core and describe
  you
  usecase.
 
  normally, you need to have a locale .spec or .src.rpm to build a package
  locally, so this is properly why dnf builddep has the same requirment

 Well you assume that buildep is only used to build packages. But if
 you want to build the upstream source of a package for any reason
 having a command that installs required packages is handy.

 For instance if I want to build foo to write / test a patch I do
 yum-builddep foo jhbuild buildone foo ... I have the code, can
 hack on it, can build it without messing with deps and do not have to
 build a package (development does not always mean packing).


 Sound like a good usecase, please open a bugzilla RFE against
 dnf-plugins-core

https://bugzilla.redhat.com/show_bug.cgi?id=1109811
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: libgcrypt and google-chrome

[drago01]

On Mon, Apr 28, 2014 at 5:05 PM, Adam Williamson awill...@redhat.com wrote:
 On Mon, 2014-04-28 at 15:43 +0200, Fidel Leon wrote:
 On Monday 28 April 2014 08:31:19 piruthiviraj natarajan wrote:
  Recent libgcrypt update to libgcrypt-1.6.1-2.fc21 doesn't allow you to
  install google-chrome current version in rawhide. The maintainer
  specifically removed the old .so compatibility with this new release. Is
  there any other way how to workaround this without downgrading the
 package?

 +1, it's a quite disruptive change, it breaks compatibility for a VERY MAJOR
 software product! We're not talking about an obscure app living under a rock 
 in
 Github, we're talking about Google Chrome!

 Given the description of the actual changes behind the soname bump:

 Unfortunately the rebase bumps soname to libgcrypt.so.20 due to
 dropping some long-ago deprecated API calls. This should not break
 builds of any reasonably current software.

 I suspect the ugly hack of symlinking should work, for Chrome. But
 really, Google ought to do a new build. Or you could use Chromium;
 there's a COPR that carries it at
 http://copr.fedoraproject.org/coprs/churchyard/chromium-russianfedora/ ,
 though I can't vouch for the quality/safety personally at all (I don't
 use Chrome or Chromium).

How about filing a bug upstream i.e telling google about it? Might not
get you a fixed build ASAP but it is better then relying on
workarounds ...
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: what in fedora rawhide replaces pdftk for extracting pages from PDF file?

[drago01]

On Tue, Apr 22, 2014 at 11:49 PM, Michal Jaegermann mic...@harddata.com wrote:
 On Tue, Apr 22, 2014 at 07:30:35PM +, Jack Peirce wrote:
 On Tue, 22 Apr 2014, Robert P. J. Day wrote:
   wait, hang on, that will extract every single page into its own PDF
   file -- can i not ask for a range of pages to be extracted into a
   single file? is there an option i'm overlooking?

   rday

 No, that's just the way pdfseparate works. Separates into individual files

 May not be ideal, but you can use pdfunite with it to achieve what
 you're trying to do.

 What if you are trying to do those other things that pdftk is capable
 of doing and they are not just splitting and joining pages?

Port pdftk to openjdk? Not sure why it depends on gcj didn't look at
it in detail.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: new f19/f20 images

[drago01]

On Thu, Apr 17, 2014 at 12:24 AM, Matthew Miller
mat...@fedoraproject.org wrote:
 On Wed, Apr 16, 2014 at 11:23:15PM +0200, drago01 wrote:
 Since when do we do something like this? Sounds like an over reaction to me.
 Installing (security) updates is the first thing you should do after
 installing anyway and besides who decided this and when?
 What are the criteria for doing updated images?

 Right now, it's when the security team says we should, pretty much.

I am not against this change (see my mail in the other thread).

But it should have a better process then someone decides about it and
do it without telling anyone about it so it gets no testing until
after its done.

 In this case, since so much is linked against the affected library, and
 since services need to be restarted in order for the update to meaningful, I
 think it's a reasonable thing to do for our users.

(and people complain about offline updates ...)

 For cloud, we did it previously when it was discovered that the root
 password wasn't properly locked (kickstart misconfiguration). In the future
 (see the change proposal), we *do* need some clear guidelines, as well as
 planned-out procedures.

*nod*
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: new f19/f20 images

[drago01]

On Thu, Apr 17, 2014 at 2:51 PM, Chuck Anderson c...@wpi.edu wrote:
 On Wed, Apr 16, 2014 at 11:23:15PM +0200, drago01 wrote:
 On Wed, Apr 16, 2014 at 9:11 PM, Kevin Fenzi ke...@scrye.com wrote:
  Greetings.
 
  We have new f19/f20 images with openssl updated, and they appear to be
  default/live already.
 
  Were we waiting for some testing runs on them before announcing?
  (Which we should have done before making them live, imho)
 
  Or did that already happen?
 
  Did we want to do a full test cycle on them?
  Or just openssl related actions?

 Huh?

 Since when do we do something like this? Sounds like an over reaction to me.
 Installing (security) updates is the first thing you should do after
 installing anyway and besides who decided this and when?
 What are the criteria for doing updated images?

 Live images can't be updated...

1) They can
2) Live images are not supposed be used for production ..
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: new f19/f20 images

[drago01]

On Thu, Apr 17, 2014 at 3:02 PM, Chuck Anderson c...@wpi.edu wrote:
 On Thu, Apr 17, 2014 at 02:52:41PM +0200, drago01 wrote:
 On Thu, Apr 17, 2014 at 2:51 PM, Chuck Anderson c...@wpi.edu wrote:
  On Wed, Apr 16, 2014 at 11:23:15PM +0200, drago01 wrote:
  On Wed, Apr 16, 2014 at 9:11 PM, Kevin Fenzi ke...@scrye.com wrote:
   Greetings.
  
   We have new f19/f20 images with openssl updated, and they appear to be
   default/live already.
  
   Were we waiting for some testing runs on them before announcing?
   (Which we should have done before making them live, imho)
  
   Or did that already happen?
  
   Did we want to do a full test cycle on them?
   Or just openssl related actions?
 
  Huh?
 
  Since when do we do something like this? Sounds like an over reaction to 
  me.
  Installing (security) updates is the first thing you should do after
  installing anyway and besides who decided this and when?
  What are the criteria for doing updated images?
 
  Live images can't be updated...

 1) They can
 2) Live images are not supposed be used for production ..

 1) Sure if you have a persistent live image on a USB I suppose.  But
 with CD/DVD media, you cannot update and then reboot as is necessary
 to fix the issue.  You can manually restart all processes/services
 that were linked against the old openssl I suppose, but you would have
 to go through this dance after every single boot to remove this
 vulnerability.

Which service do we install and run by default that uses OpenSSL and
is configured to use SSL on the live media?
- Answer is none.

 2) Live images could be used to rescue/repair a production
 environment,

See above.

 or could be used as a client to access a production
 environment.  For example one could be using curl which is linked
 against the bad openssl.

curl is a client.

 We shouldn't leave our users exposed if they
 decide to use a live image, especially since I don't think it is
 documented anywhere that these images are unsuitable for use in a
 production environment.

There are unsuitable by their very nature of being live images.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: new f19/f20 images

[drago01]

On Thu, Apr 17, 2014 at 4:31 PM, Chuck Anderson c...@wpi.edu wrote:
 On Thu, Apr 17, 2014 at 03:11:38PM +0200, drago01 wrote:
 On Thu, Apr 17, 2014 at 3:02 PM, Chuck Anderson c...@wpi.edu wrote:
  On Thu, Apr 17, 2014 at 02:52:41PM +0200, drago01 wrote:
  On Thu, Apr 17, 2014 at 2:51 PM, Chuck Anderson c...@wpi.edu wrote:
   On Wed, Apr 16, 2014 at 11:23:15PM +0200, drago01 wrote:
   On Wed, Apr 16, 2014 at 9:11 PM, Kevin Fenzi ke...@scrye.com wrote:
Greetings.
   
We have new f19/f20 images with openssl updated, and they appear to 
be
default/live already.
   
Were we waiting for some testing runs on them before announcing?
(Which we should have done before making them live, imho)
   
Or did that already happen?
   
Did we want to do a full test cycle on them?
Or just openssl related actions?
  
   Huh?
  
   Since when do we do something like this? Sounds like an over reaction 
   to me.
   Installing (security) updates is the first thing you should do after
   installing anyway and besides who decided this and when?
   What are the criteria for doing updated images?
  
   Live images can't be updated...
 
  1) They can
  2) Live images are not supposed be used for production ..
 
  1) Sure if you have a persistent live image on a USB I suppose.  But
  with CD/DVD media, you cannot update and then reboot as is necessary
  to fix the issue.  You can manually restart all processes/services
  that were linked against the old openssl I suppose, but you would have
  to go through this dance after every single boot to remove this
  vulnerability.

 Which service do we install and run by default that uses OpenSSL and
 is configured to use SSL on the live media?
 - Answer is none.

  2) Live images could be used to rescue/repair a production
  environment,

 See above.

  or could be used as a client to access a production
  environment.  For example one could be using curl which is linked
  against the bad openssl.

 curl is a client.

 Clients ARE affected:

Sure you can read out memory from a client the same way by an evil
server but its is far less serve as the
the server case ... besides if you are downloading stuff from a
compromised server you will most likely have other
issues then a server trying to read out your download clients memory
(web browsers would be a worthwhile target but
they do not use openssl).

This is not the only security issue that exists ... it is very bad for
*servers* because an attacker can spam you with requests
until he gets what he wants.

 Does anaconda or yum use OpenSSL?  Because then yum updates and
 liveinst are potentially affected.

 Does libvirt/virt-manager/virt-viewer use OpenSSL?  Because I could
 certainly see a sysadmin using a Live image to run
 virt-manager/virt-viewer to connect over the network via SSL to a
 hypervisor.

Not using live media no.

 Do VNC/RDP clients use OpenSSL?  rdesktop is linked against an OpenSSL
 library.  It may be possible to exploit it.

Its not about being possible to exploit its a bout the servity of
the issue by your logic we should spin media for every security issue
...

  We shouldn't leave our users exposed if they
  decide to use a live image, especially since I don't think it is
  documented anywhere that these images are unsuitable for use in a
  production environment.

 There are unsuitable by their very nature of being live images.

 Why are we shipping unsuitable software then?

We don't. Live media is useful for 1) installing the system 2)
previewing or showcasing the system. Not for use in production
(especially not as a server)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: new f19/f20 images

[drago01]

On Wed, Apr 16, 2014 at 9:11 PM, Kevin Fenzi ke...@scrye.com wrote:
 Greetings.

 We have new f19/f20 images with openssl updated, and they appear to be
 default/live already.

 Were we waiting for some testing runs on them before announcing?
 (Which we should have done before making them live, imho)

 Or did that already happen?

 Did we want to do a full test cycle on them?
 Or just openssl related actions?

Huh?

Since when do we do something like this? Sounds like an over reaction to me.
Installing (security) updates is the first thing you should do after
installing anyway and besides who decided this and when?
What are the criteria for doing updated images?
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: any advice to fix firefox being excruciatingly slooooooooow?

[drago01]

On Sun, Mar 30, 2014 at 8:45 PM, Daniel J Walsh dwa...@redhat.com wrote:
 firefox in Rawhide has become unusable for me also.  It seems to have
 runaway scripts and hangs all the time.  It is asking me to force-kill it
 all the time.  I have had to switch to chrome, in order to have a working
 browser.

Did you (or Robert) file a bug ?
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: any advice to fix firefox being excruciatingly slooooooooow?

[drago01]

On Sat, Mar 29, 2014 at 3:28 PM, Tom London seli...@gmail.com wrote:
 On Sat, Mar 29, 2014 at 1:33 AM, Robert P. J. Day rpj...@crashcourse.ca
 wrote:


   since upgrading to rawhide, numerous operations in firefox are just
 glacially slow -- playing videos results in jerky motion, scrolling
 has a significant time lag, even typing in a search term in youtube
 might take several *seconds* before the first letters i typed even
 display.

   i've gone into about:config and turned off several features but
 that hasn't helped noticeably. anyone else running across this? any
 simple advice?

 rday


 You running firefox-28.0.[123]?

 I noticed that xulrunner-28.0.1.fc21 failed to build.

 Running latest firefox with older xulrunner spews my journal, etc.

Firefox no longer needs xulrunner.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: this mornings kernel rc6 not signed...

[drago01]

On Thu, Mar 13, 2014 at 3:19 PM, Kevin Martin ktm...@gmail.com wrote:
 Tried to do an update this morning and I get:

 Error: Package kernel-3.14.0-0.rc6.git1.1.fc21.x86_64.rpm is not signed

 Can somebody please fix this?

Rawhide packages are never signed ...
-- 
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

[drago01]

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. We do it due to lack of better
infrastructure.
-- 
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

[drago01]

On Sun, Feb 23, 2014 at 1:04 PM, Ralf Corsepius rc040...@freenet.de wrote:
 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.

1. I did not state where the test is just where (or better) *when* it
should run.
2. Package authors rarely do anything other then ... package ... (99%
of the test cases are not implemented by the package authors)

 I regret, but denying this consideration is just evidence of lack of
 experience.

No you seem to not understand my point.


 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.

As stated above you missed the point. Building a package means well
building it not test it.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: 3.14 Regression on Z77 and 3770-k

[drago01]

On Fri, Feb 7, 2014 at 10:30 PM, Chuck Forsberg WA7KGX c...@omen.com wrote:
 Today's rawhide 64 has the same problems I reported some time ago.
 Noveau doesn't work on the Nvidia GTX 670 and devices on the
 Asmedia USB3 ports don't work.

 As an experiment, I force installed 3.14 on a Heisnbug system.
 The results were the same - neither Noveau nor Asmedia USB3
 worked.

Can you be a bit more verbose .. i.e what does doesn't work mean exactly?
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Release criteria proposal: explicit requirements for keyboard layouts

[drago01]

On Tue, Jan 14, 2014 at 1:49 AM, Adam Williamson awill...@redhat.com wrote:
 Hey, folks. So I'm currently looking through f20 blocker review logs to
 try and catch cases where the criteria clearly weren't as clear as they
 could be.

 One that showed up quickly is something of a greatest hit: keyboard
 layout problems. It's quite often the case that keyboard layout
 selection gets broken at some level. The key stages to consider are
 decryption of encrypted storage devices (which happens early in boot),
 login time, and after login. We had a long discussion about such a bug
 in the second F20 blocker review meeting:

 http://meetbot.fedoraproject.org/fedora-blocker-review/2013-08-28/f20alpha-blocker-review-2.2013-08-28-16.01.log.html

 https://bugzilla.redhat.com/show_bug.cgi?id=994180 , Boot-time LUKS
 passphrase input *always* defaults to en-us

 We currently 'cover' this in the sense that we have Alpha requirements
 that decryption and login should work, and a note in the preamble that
 says:

 There may be times where a requirement is unmet only in a particular
 configuration, such as with some keyboard layouts but not others, or if
 a particular character is used in a username, password or passphrase. In
 such cases, the release team should use their judgement and refer to
 precedent to determine whether or not the issue should be considered to
 block the release. They should consider the number of users likely to be
 affected by the issue, the severity of the case when the issue is
 encountered, and the ease or otherwise with which the issue can be
 avoided by both informed and uninformed users.

 That's a generic explanation of the 'conditional blocker' process, but
 we do explicitly list 'keyboard layouts' as one of the examples. Still,
 I think our experience indicates that this kind of problem comes up
 sufficiently often that we'd really benefit from explicit coverage.

 So, I'm proposing we add a section to
 https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Post-install_requirements
  which states that at decryption and login stages, the systemwide keyboard 
 layout must be used, and post-login, the systemwide layout must be used if no 
 per-user configuration is specified; if a user-specific layout configuration 
 for a given desktop exists, it must be used for that user/desktop combination.

 === Keyboard layout configuration ===

 If a particular keyboard layout has been configured for the system, that
 keyboard layout must be used:

 * When unlocking encrypted storage volumes during boot
 * When logging in at a console
 * When logging in via the default login manager for a release-blocking
 desktop
 * After logging in to a release-blocking desktop, if the user account
 does not have its own keyboard layout configuration for that desktop (if
 there is such a user/desktop-specific configuration, it must be used
 when that user logs in to that desktop)

 I think Final is appropriate for this. It's acceptable for it to be
 broken for an Alpha or a Beta, I think, especially given that I think
 we're generally agreed that we may currently be setting too high a
 standard at Alpha and Beta and we should err on the side of trimming
 those requirements rather than adding more.

 Comments, suggestions, objections, improvements? Thanks!

Yeah should finally add it. So +1
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Selinux out of control

[drago01]

On Thu, Dec 26, 2013 at 12:01 AM, Michał Piotrowski mkkp...@gmail.com wrote:
 Hi,

 2013/12/25 Chuck Forsberg WA7KGX c...@omen.com

 A few days ago SELinux was updated.
 Selinux now ignores /etc/selinux/config
 and issues denials.


 I have the same problem on server that I installed yesterday.

 I didn't have this problem on VM that I created last week, but after the
 latest update I also have problem on this system too. I guess that downgrade
 of libselinux* and exclude it from upgrades should fix the problem.

How about filling a bug?
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Criterion revision proposal: KDE default applications

[drago01]

On Fri, Dec 13, 2013 at 3:05 AM, Adam Williamson awill...@redhat.com wrote:
 It was clear at the Go/No-Go meeting today that KDE SIG does not
 consider this release criterion applicable/desired:

 All applications that can be launched using the standard graphical
 mechanism of a release-blocking desktop after a default installation of
 that desktop must start successfully and withstand a basic functionality
 test.

 https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_application_functionality

 jreznik says they consider the live image their 'polished product' where
 everything must work, while the DVD install is more of a grab-bag - they
 install a whole bunch of stuff, and don't think it's the end of the
 world if one or two bits are broken.

 Given that, I propose re-wording as follows:

 All applications that can be launched using the standard graphical
 mechanism of a release-blocking live image after an installation of that
 image must start successfully and withstand a basic functionality test.

 So, that doesn't just apply to KDE. True, but I actually think it's a
 reasonable revision for GNOME as well. It makes sense to see the live
 images as defining what our 'polished core desktops' consist of, and the
 DVD as more of a grab-bag of packages.

No that makes zero sense. You solution is not a solution at all we
found out that we ship random crap on the DVD that does not even start
up ... so lets pretend we don't know about it ... the proper solution
(as others said) is to simply to *NOT* install random stuff by default
just because there is space on the media.

We should improve the software installation experience so that people
can easily find and install software they need (that's what we have
started to do in F20 which is a way better approach then just install
tons of stuff by default).
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Criterion revision proposal: KDE default applications

[drago01]

On Sat, Dec 14, 2013 at 1:54 AM, Adam Williamson awill...@redhat.com wrote:
 On Fri, 2013-12-13 at 18:49 -0500, Rahul Sundaram wrote:
 Hi


 On Fri, Dec 13, 2013 at 4:58 PM, Adam Williamson  wrote:



 Well, then there's the problem. We can't have release criteria
 that say
 we really stand behind the package sets installed from the
 DVD if we
 don't.


 That is true however the solution is not to weaken the release
 criteria but decide  a) do we need the DVD anymore  b) if we need it,
 whether there is anything against trimming down the default package
 sets to be consistent with what is included in the live images.  With
 the new model, I think the right answer is to drop the DVD image
 entirely but b) is the minimum we should do.

 That requires will on the part of the desktop SIGs, though. QA is not
 going to be responsible for this. My position is either the desktop SIGs
 fix their stuff, or we will have to change the criteria as I proposed,
 because what other choice do we have?

Talk to FESCo ? Ask for them to remove the offending crap once we hit it?
Or if the app does not start and is not part of live kick it out.
Its a one line change.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Fedup test?

[drago01]

On Friday, October 18, 2013, Adam Williamson awill...@redhat.com wrote:
 On Fri, 2013-10-18 at 10:39 +0200, drago01 wrote:


 On Friday, October 18, 2013, Ed Greshko ed.gres...@greshko.com
 wrote:
  On 10/18/13 15:33, Ralf Corsepius wrote:
  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.
 
 
  Ooopsss, I lied.  I thought the failure had occured earlier in the
 process and didn't wait long enough.  I get the same error using the
 fedoraproject.org link.
 
  Where should this be reported?

 Just disable delta rpms .. There is a bug filed somewhere.

 Where is the bug? https://bugzilla.redhat.com/show_bug.cgi?id=1005895
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Fedup test?

[drago01]

On Fri, Oct 18, 2013 at 10:53 AM, Ed Greshko ed.gres...@greshko.com wrote:
 On 10/18/13 16:39, drago01 wrote:


 On Friday, October 18, 2013, Ed Greshko ed.gres...@greshko.com 
 mailto:ed.gres...@greshko.com wrote:
  On 10/18/13 15:33, Ralf Corsepius wrote:
  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.
 
 
  Ooopsss, I lied.  I thought the failure had occured earlier in the process 
  and didn't wait long enough.  I get the same error using the 
  fedoraproject.org http://fedoraproject.org link.
 
  Where should this be reported?

 Just disable delta rpms .. There is a bug filed somewhere.


 I don't see an option for that in fedup-cli

Because there is none. You have to disable it for yum (yum.conf) see
https://bugzilla.redhat.com/show_bug.cgi?id=1005895  (or apply the one
line fix by hand).
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: First impressions with F20-Beta

[drago01]

On Fri, Oct 4, 2013 at 2:52 PM, Adam Williamson awill...@redhat.com wrote:
 On Fri, 2013-10-04 at 00:47 +0200, drago01 wrote:


 On Thursday, October 3, 2013, Chuck Forsberg WA7KGX c...@omen.com
 wrote:
  TC1 netinst installation, booting, and initial operation nominal
  on a hardware E6550.  Gnuradio compiled in normal time and
  passed all but one self test (the usual).
 
  The TC1 USB stick netinst UEFI booted on an Asus P8z77v LE Plus was
  unable to modify the hard drive partitions.
 
  Is UEFI boot a requirement for Heisenbug?

 No.

 I think you misread Chuck's mail (I did at first). Just to be sure, here
 are answers to both of the possible questions:

 1. Do you have to be using UEFI to install Fedora 20?
 Answer: No.

Yeah that's the question I answered.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Gnome 3.10: Network UI missing from new system status area

[drago01]

On Fri, Oct 4, 2013 at 3:05 PM, Chuck Anderson c...@wpi.edu wrote:
 On Fri, Oct 04, 2013 at 01:54:17PM +0100, Adam Williamson wrote:
 On Fri, 2013-10-04 at 07:54 +0200, moshe nahmias wrote:
  I think that it must be possible to make the icon visible as an
  option. I use a cellular modem on my laptop and the easiest way to
  connect with it to the net is by clicking that icon...
 
  I guess that it's possible to connect from other places, but it won't
  be as easy.

 GNOME 3.10 has a combined system tray. Your cellular connection will be
 visible in it. (In other words, don't worry, it will work exactly how
 you expect it to). The change we're discussing applies only to boring
 plain wired ethernet connections.

 Use Case #1 for having the wired connection icon show at all times is
 to know when your network connection isn't working locally, as opposed
 to some remote problem.  If you are connected to your LAN, the icon
 would show connected, but if your WAN/Internet connection is down,
 google.com will fail to connect.  This is the first question any tech
 support person would ask the end user--does your computer show that it
 is connected (do you have a link light on the NIC)?  We should be
 making this determination easier, not harder.

 Use Case #2 is for switching between different wired network
 configuration profiles and turning multiple NICs on or off.

 Why are we adding more and more functionality to NetworkManager, just
 to take it away from the user interface?

https://bugzilla.gnome.org/show_bug.cgi?id=708966 is the upstream bug
... if you have anything useful (i.e no flamebait) to add ad it there.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Gnome 3.10: Network UI missing from new system status area

[drago01]

On Thu, Oct 3, 2013 at 8:31 PM, Richard Ryniker ryni...@alum.mit.edu wrote:
 Well, a statically configured network interface might be expected to
 just work.

 With dynamic configuration, there must be successful contact with a DHCP
 server, and the server must be willing to assign an IP address and
 possibly provide other information (gateway, nameserver, host name) to
 the client host.  In this case, a visible indicator of successful network
 configuration might be useful.

You should get an icon indicating failure just no success one. Which
is even very unixy ;)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: First impressions with F20-Beta

[drago01]

On Thursday, October 3, 2013, Chuck Forsberg WA7KGX c...@omen.com wrote:
 TC1 netinst installation, booting, and initial operation nominal
 on a hardware E6550.  Gnuradio compiled in normal time and
 passed all but one self test (the usual).

 The TC1 USB stick netinst UEFI booted on an Asus P8z77v LE Plus was
 unable to modify the hard drive partitions.

 Is UEFI boot a requirement for Heisenbug?

No.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F20-rc3, gnome-shell logoff?

[drago01]

On Wed, Sep 18, 2013 at 3:49 PM, Gene Czarcinski g...@czarc.net wrote:
 OK, so we changed the interface yet again for the user in Gnome
 3/gnome-shell.  Just how does one logoff or do a switch user??  I can do a
 shutdown/restart.  I can suspend.  I can bring up the setting application.
 But logout and switch user seems to have gotten lost ... or if it is there
 it sure is not obvious!

Click on your name inside the top right menu. It should open a submenu
with the options in it.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: no login possible after installing gdm-3.8.4-1 and gdm-libs3.8.4-1

[drago01]

On Mon, Aug 12, 2013 at 8:59 AM, Adam Williamson awill...@redhat.com wrote:
 On Mon, 2013-08-12 at 07:24 +0200, Joachim Backes wrote:
 Hi all,

 anybody run an update in F19 using updates-testing? The update included
 gdm-3.8.4-1 and gdm-libs3.8.4-1. After having done the update, no more
 login for normal users is done: the gdm user automatically logs in
 after having booted or after having logged out, for other users it's
 only possible to login on a TTY.

 I could solve the problem by downgrading gdm and gdm-libs.

 Yikes! I'll try and test this here tomorrow. In the mean time, did you
 file -1 karma? We definitely don't want to push something like that out.
 Thanks!

It already has -3
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Youtube, not all songs-videos can be played, F19_64

[drago01]

On Friday, July 12, 2013, Michael Schwendt mschwe...@gmail.com wrote:
 On Fri, 12 Jul 2013 10:53:32 -0400 (EDT), Joerg Lechner wrote:

 Hi, I want to finish this discussion on what to report in this list.

 Lists like this one are not intended for reporting problem, but for
 discussing things.

 The Youtube video problem I could solve, I installed the rpm version,
 instead of yum version.

 That doesn't make much sense, since Yum also installs the rpm version.
 It installs RPM packages.


It probably makes sense this way he just installed the repo but not flash
itself. So any video that was not encoded as webm failed to play. Anything
else does not make sense.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F19: Galaxy Nexus not working with MTP, does work with PTP

[drago01]

On Mon, Jun 24, 2013 at 11:41 AM, Pedro Francisco
pedrogfranci...@gmail.com wrote:
 Gnome's MTP support is not working with my Galaxy Nexus. PTP does work.

Seems to work fine here with my Nexus 4
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Fedora 19 Final blocker status: fix and karma requests

[drago01]

On Mon, Jun 24, 2013 at 3:15 PM, Bill Nottingham nott...@redhat.com wrote:
 Bruno Wolff III (br...@wolff.to) said:
 On Sun, Jun 23, 2013 at 18:04:55 -0400,
   Matthias Clasen mcla...@redhat.com wrote:
 rpm db  82M

 I vaguely remember a discussion about dropping this for live images
 because it gets rebuilt every boot when needed. My memory is that we
 ended up removing this data while building live images, but haven't
 looked at it in a long time.

 It's useful in terms of having a RPM-based manifest of what's on
 the image, and if you're installing the image to disk, you're going
 to need it on the installed system...

And it allows stuff like yum install foo to work in the live environment.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: gnome-shell cpu usage during installation

[drago01]

On Fri, Jun 21, 2013 at 7:47 PM, Adam Williamson awill...@redhat.com wrote:
 On Fri, 2013-06-21 at 19:41 +0200, drago01 wrote:
 On Fri, Jun 21, 2013 at 6:14 PM, Chris Murphy li...@colorremedies.com 
 wrote:
 
  On Jun 21, 2013, at 9:56 AM, Chris Murphy li...@colorremedies.com wrote:
 
  F19:
  direct rendering: Yes
  OpenGL renderer string: Gallium 0.4 on NV84
 GL_MESA_texture_signed_rgba, GL_NV_conditional_render, 
  GL_NV_depth_clamp,
 GL_MESA_window_pos, GL_NV_blend_square, GL_NV_conditional_render,
 
  I'm unsure what it means for GL_NV_conditional_render to be listed twice, 
  and for GL_AMD_conservative_depth to be listed for F18 but not F19.
 
  It looks like conservative_depth is an optimization, but I have no idea if 
  it matters to gnome-shell.
  http://www.opengl.org/registry/specs/AMD/conservative_depth.txt

 This is completely irrelevant.

 Yes, well, we were only looking for the 'Gallium 0.4 on XX' bit to check
 whether he'd somehow wound up on software rendering on F19. Obviously he
 hasn't.

I know I was referring to the talk about the extensions.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: screengrabber istanbul in F19

[drago01]

On Wed, Jun 19, 2013 at 8:23 PM, Joachim Backes
joachim.bac...@rhrk.uni-kl.de wrote:
 On 06/19/2013 07:51 PM, Louis Lagendijk wrote:

 On Tue, 2013-06-18 at 14:58 +0200, Joachim Backes wrote:

 On 06/18/2013 02:30 PM, Ryan Lerch wrote:

 On Tue 18 Jun 2013 05:48:50 AM EDT, Joachim Backes wrote:

 Hi all testers,

 I'm running the screen capture program istanbul in F19/gnome3, but I
 don't see any istanbul icon on the screen, so I can't control it.

 On the other hand, if using mate or gnome classical, the istanbul
 icons appear in the notification area so I can manage the istanbul
 program.

 What I'm doing wrong?


 This application probably uses the deprecated trayicon that by default
 is not shown anymore. I installed the topicon plugin (not in Fedora but
 available from https://extensions.gnome.org/extension/495/topicons/)
 for another application that had the same problem

 kind regards, Louis



 Hi Louis,

 this solved my problem! Thank you very much!

GNOME has a built in screen recorder that you can start / stop using
Ctrl-Alt-Shift-R ... videos will be saved to ~/Videos.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: gnome-shell cpu usage during installation

[drago01]

On Thu, Jun 20, 2013 at 1:00 AM, Chris Murphy li...@colorremedies.com wrote:

 On Jun 19, 2013, at 3:53 PM, John Reiser jrei...@bitwagon.com wrote:

 Is there a more definitive way to tell if gnome-shell is or isn't 
 offloading onto the GPU?

 $  glxinfo  |  grep renderer
 OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.3, 128 bits)
llvmpipe is the software CPU (SSE2) renderer

 OpenGL renderer string: Gallium 0.4 on AMD REDWOOD
One of the hardware renderers.


 Fedora 18:
 [root@localhost ~]# glxinfo | grep renderer
 Error: unable to open display

1. You don't have to do it as root
2. X has to be running
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Late Gnome Test Day report

[drago01]

On Wed, Jun 12, 2013 at 4:00 AM, Adam Williamson awill...@redhat.com wrote:
 On Tue, 2013-06-11 at 10:22 -0400, Martin Holec wrote:
 Hi,

 this is quick summary of Fedora 19 Gnome[1] Test Day.
 Thanks to everybody who joined this event. Especially developers and QEs who 
 were available during all day on IRC and were assisting users with their 
 testing.

 [1] https://fedoraproject.org/wiki/Test_Day:2013-03-21_Gnome_3.8

 = Fedora 19 Gnome Test Day report =

 Please developers have a look at the following bugs (if you didn't
 yet) as one of motivations for users to attend Test Days is that found
 bugs will be fixed soon via updates after installation.

 Note, after almost 3 months there are lot of NEW bugs in Red Hat
 Bugzilla in contrast to many RESOLVED in Gnome Bugzilla. If you need
 any help with triaging bugs and testing bugfixes, feel free to contact
 me.

 Thanks Martin! I just did a quick triage run through the RH bugs, and
 now it looks like this:


 924266 NEW  - Cannot close an application in Activities if a modal window is 
 currently blocking it (for Shotwell and Revelation)

My other mail ended up empty for whatever reason (thanks google) ...
https://bugzilla.gnome.org/show_bug.cgi?id=650843
This is a complex issue wont be fixed in F19 (hopefully in 3.10 -
F20) but isn't a regression.

 924403 NEW  - dragging icon of running Firefox to new workspace creates and 
 destroys the workspace

Sounds like a firefox bug (not doing startup notification properly).

 924370 NEW  - combo box disappears after first click

Might be fixed with mutter 3.8.3 (assuming it has something to do with
the frame sync bug).
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Late Gnome Test Day report

[drago01]

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Gnome Software Update doesn't work

[drago01]

On Sun, Jun 2, 2013 at 8:30 PM, Chris Murphy li...@colorremedies.com wrote:

 On Jun 2, 2013, at 1:59 PM, Chris Murphy li...@colorremedies.com wrote:


 On Jun 2, 2013, at 1:50 PM, Adam Williamson awill...@redhat.com wrote:

 Right after clicking Install Updates a status bar appears that says
 Running, then Resolving Dependencies, then vanishes. There's no status
 bar after that, while it consumes CPU like mad.

 # pkmon
 Transaction:
 [none]
 daemon connected=1
 network status=wired

 After force quitting this, and rerunning it as root I get different 
 information, and totally different behavior from gpk-view-update, it starts 
 downloading packages. So something's still broken, but monitoring it causes 
 it to become unbroken.

 OK that was a one time event apparently. The next 8 times I've run pkmon, 
 consistently Software Update goes through a brief sequence of Running and 
 Resolving Decencies, then hangs. Nothing is updated.

Sounds like https://bugzilla.redhat.com/show_bug.cgi?id=909761

If you can reproduce it try adding the information requested in that
bug (https://bugzilla.redhat.com/show_bug.cgi?id=909761#c26)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Test-Announce] Fedora 19 Beta Release Candidate 3 (RC3) Available Now!

[drago01]

On Wed, May 22, 2013 at 10:12 PM, John Reiser jrei...@bitwagon.com wrote:
 On 05/22/2013 12:04 PM, Clemens Eisserer wrote:
 As UPX requires executeables to be decompressed during startup (and
 furthermore does not support ELF shared libraries),

 An executable main program which has been compressed by UPX
 *can* use ELF shared libraries, and nearly all programs on Linux
 that are compressed by UPX *do* use shared libraries.
 The execution-time difference between a compressed and a never-
 compressed program is that the Linux kernel loads the PT_INTERP for
 execve() of a regular program, while the UPX runtime stub loads the PT_INTERP
 for a compressed program.  With respect to byte values, there is essentially
 no difference in the memory image of the process.

 On a few platforms (including Linux i386 and x86_64) UPX also can
 compress a shared library itself.  You don't get any actual sharing
 of execution-time pages, but storage space in the filesystem is less.
 Compression is not as tight as with a main program, because in a shared
 library only instructions can be compressed: not symbol tables, not .data,
 etc, because these are needed by ld-linux to perform relocation
 which happens before UPX can gain control (which it does via DT_INIT.)

 its not a sane
 option for a distribution.

 It depends on the desired goals.  On distribution media, .rpm packages
 are compressed using xz (lzma2), and the space saved by xz compression
 often is similar to that saved by UPX.  Once installed, the UPX compression
 saves storage space in the filesystem at the cost of no sharing:
 not among multiple simultaneous processes, nor demand paged between
 the filesystem and process memory space.

Which means you'd be better off with file system level compression.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

F18: Request for testing / karma

[drago01]

Hi,

After upgrading to kernel 3.9.2 I have hit a rather bad bug where the
kernel exposes rfkill device types that gnome-bluetooth and
gnome-control-center do not know about causing gnome-shell to crash
with a fail whale on login.

I have fixed it upstream and backported the fixes to F18:
https://admin.fedoraproject.org/updates/gnome-bluetooth-3.6.1-3.fc18,control-center-3.6.3-2.fc18

I don't know how many devices (laptops) are affected by this but as
this is a very straight forward fix I want to get it in stable asap.
Please test the update and provide karma if it works for you. If you
are not affected by the bug you should not notice any difference after
installing the update.

Thanks
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Revised Beta criteria up

[drago01]

On Wed, Apr 24, 2013 at 7:23 PM, Adam Williamson awill...@redhat.com wrote:

 The recommend part should be stripped out of virtualization technology
 since we should cover both KVM and XEN ( we ship both )


 We ship lots of stuff that we don't block releases for. Just the fact that
 we ship it doesn't mean we must block the release on it. We cover Xen in the
 Final criteria, at present, and only as DomU, not Dom0. In theory it might
 be nice to have the 'virtualization' criteria combined, but as one is Beta
 and one is Final and the extent of functionality covered is different, it
 seems hard from a practical point of view.

We should just treat virt as any other hardware platform (they
basically are just that). Yes we cannot test all of them ... we can't
test every real hardware platform either.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: p7zip-plugins and rar extraction.

[drago01]

On Thu, Apr 25, 2013 at 1:35 AM, Rahul Sundaram methe...@gmail.com wrote:
 On 04/18/2013 01:45 AM, Rahul Sundaram wrote:

 Hi


 On Thu, Apr 18, 2013 at 12:31 AM, Rahul Sundaram  wrote:

 Red Hat bugzilla seems to be acting up.  I will file a review request when
 that problem is fixed


 Done

 https://bugzilla.redhat.com/show_bug.cgi?id=953384


 Changes have been pushed

 https://lists.fedoraproject.org/pipermail/desktop/2013-April/008060.html

Does it work with encrypted rar archives?
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: p7zip-plugins and rar extraction.

[drago01]

On Thu, Apr 25, 2013 at 10:23 AM, Rahul Sundaram methe...@gmail.com wrote:
 On 04/25/2013 03:36 AM, drago01 wrote:


 Does it work with encrypted rar archives?


 Yes.  Encrypted rar archives are supported and I have tested it explicitly
 as well

 https://code.google.com/p/theunarchiver/wiki/SupportedFormats

OK
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Wine and cpuinfo

[drago01]

On Sun, Apr 21, 2013 at 12:38 AM, Chuck Forsberg WA7KGX N2469R
c...@omen.com wrote:
 As reported previously, Fedora 19 wine cannot perform windows install

What does perform windows install mean ?

 on a Intel(R) Core(TM)2 Duo CPU E6550.  Wine can do this on a
 Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz.

 I have attached portions of cpuinfo from the two machines.

Does not matter ... the CPU is apparently not the only difference
between the two machines,

 Is there a difference in the CPU features that would explain
 the difference?

No.

 Would one expect Fedora 19 wine to work on the i5-3550 ?

Again this is odd conclusion. What exactly are you trying to do?
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Cursor moves to bottom-right after logging in in GDM

[drago01]

On Wed, Apr 17, 2013 at 12:12 AM, Ozan Çağlayan ozan...@gmail.com wrote:
 On Tue, Apr 16, 2013 at 11:32 PM, drago01 drag...@gmail.com wrote:
 On Tue, Apr 16, 2013 at 10:22 PM, Ozan Çağlayan ozan...@gmail.com wrote:
 Hi,

 I don't remember seeing this on F18 with gnome 3.6. After entering my
 password and clicking Enter in GDM for logging in, cursor always moves
 to a bottom-right position in the screen. This happens all the time
 and I think the position is always the same. Do you have this issue?

 Its not. It intentionally warps the pointer to this spot.


 Why?

https://bugzilla.gnome.org/show_bug.cgi?id=666121#c4
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Cursor moves to bottom-right after logging in in GDM

[drago01]

On Tue, Apr 16, 2013 at 10:22 PM, Ozan Çağlayan ozan...@gmail.com wrote:
 Hi,

 I don't remember seeing this on F18 with gnome 3.6. After entering my
 password and clicking Enter in GDM for logging in, cursor always moves
 to a bottom-right position in the screen. This happens all the time
 and I think the position is always the same. Do you have this issue?

Its not. It intentionally warps the pointer to this spot.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: First experiences with F19

[drago01]

On Fri, Mar 29, 2013 at 12:21 PM, Joachim Backes
joachim.bac...@rhrk.uni-kl.de wrote:
 Hi all,

 I installed the F19-Alpha-TC2/x86_64 from the Live-CD inside VirtualBox.

 My very first experiences:

 0. Install was done flawlessly inside VirtualBox

 1. Setting the keyboard to German-nodead-keys in the correpondent
 spoke during install, but if running the installed system on some tty,
 the keyboard is still US. I had to execute loadkeys de.

Sigh... new release new keyboard layout bugs. Please file a bug.

 2. I used gnome-shell as graphical desktop. Trying to logout from such
 an open gnome-shell session failed: No logout, the session remains open.
 A workaround was for me: pkill gdm.

What does failed mean? How did you log out?
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Is it a bug in rawhide's gnome?

[drago01]

On Sat, Mar 9, 2013 at 7:14 PM, Clyde E. Kunkel
clydekunkel7...@verizon.net wrote:
 The notification area seems to be missing.  On purpose, or is it a bug?

It isn't missing and it isn't a bug. You just have to push your mouse
against the bottom of the screen and the message tray will show up.
Just having the cursor sitting there isn't enough you have to push it in.

The purpose of that is that it can no longer be triggered by accident
like in gnome 3.6.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Settings panel for desktop file gnome-sound-panel.desktop could not be loaded!

[drago01]

On Sat, Feb 16, 2013 at 1:19 PM, Michael Schwendt mschwe...@gmail.com wrote:
 Feb 16 13:13:02 localhost /etc/gdm/Xsession[10257]: JS LOG: Settings panel 
 for desktop file gnome-sound-panel.desktop could not be loaded!
 Feb 16 13:13:09 localhost /etc/gdm/Xsession[10257]: JS LOG: Settings panel 
 for desktop file gnome-sound-panel.desktop could not be loaded!

 $ cat /usr/share/applications/gnome-sound-panel.desktop|grep Exec
 Exec=gnome-control-center sound

 Running it manually works.

 In case this is not known, hints on which component to choose when filing
 a bug report appreciated.

https://bugzilla.gnome.org/show_bug.cgi?id=694033
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Proposal: automatic blockers

[drago01]

On Sat, Feb 16, 2013 at 3:34 AM, Adam Williamson awill...@redhat.com wrote:
 Hey, folks. So here's another proposal from an idea that was mentioned
 during the F18 cycle.

 There's a few types of blocker bug that are basically no-brainers; it
 doesn't make a lot of sense to waste time in blocker meetings discussing
 them, and more importantly, sometimes they show up and we want to quickly
 accept them as blockers and get the fixes in, but we have to try and track
 down three people to vote +1 before they can be accepted.

 So I'm proposing we invent something called 'automatic blockers': a list of
 bug types that can be declared AcceptedBlocker by any single person in QA,
 releng or devel. That decision could of course be challenged and changed if
 needed.

Makes sense ... there is no point in discussion the obvious in
meetings ... the return of common sense ;)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Telnetd broken

[drago01]

On Thu, Jan 31, 2013 at 11:11 AM, Karel Volný kvo...@redhat.com wrote:
 Dne St 30. ledna 2013 10:03:57, drago01 napsal(a):
 On Tue, Jan 29, 2013 at 12:31 AM, Chuck Forsberg WA7KGX N2469R

 c...@omen.com wrote:
  The telnet service in Fedora 18 and Rawhide is broken.

  Here is output from telnet(1) on f18 calling a machine running Rawhide:
 Do yourself a favor and use ssh instead.

 do us a favor and refrain from such comments next time :-)

 we (RHEL QA) also have an use case for telnet, despite the fact that for day
 to day work everyone uses ssh (with keys) since the year dot

Using telnet over the internet is just not a good idea. PERIOD.

Yes there are usecases for telnet, the OP one isn't.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Telnetd broken

[drago01]

On Thu, Jan 31, 2013 at 12:05 PM, Karel Volný kvo...@redhat.com wrote:
 Dne Čt 31. ledna 2013 18:32:57, Ed Greshko napsal(a):
 On 01/31/2013 06:15 PM, drago01 wrote:
  Yes there are usecases for telnet, the OP one isn't.

 How do you know?  As far as I can tell from the thread, no one asked and he
 didn't state.

 from the original question:

 Trying 192.168.1.15...

 ... that doesn't look like in a public Internet address block ;-)

 telnet omen.com
Trying 70.89.176.169...
Connected to omen.com.
Escape character is '^]'.
Fedora release 18 (Spherical Cow)
Kernel 3.7.4-204.fc18.x86_64 on an x86_64 (9)
men login:

 looks very public to me ;)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Telnetd broken

[drago01]

On Tue, Jan 29, 2013 at 12:31 AM, Chuck Forsberg WA7KGX N2469R
c...@omen.com wrote:
 The telnet service in Fedora 18 and Rawhide is broken.
 Here is output from telnet(1) on f18 calling a machine running Rawhide:

Do yourself a favor and use ssh instead.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Proposed F19 Feature: Replace MySQL with MariaDB

[drago01]

On Thu, Jan 24, 2013 at 10:34 AM, Adam Williamson awill...@redhat.com wrote:
 On Thu, 2013-01-24 at 05:58 -0300, Fernando Cassia wrote:
 On Wed, Jan 23, 2013 at 12:20 PM, Karel Volný kvo...@redhat.com wrote:
 
  because resources are limited

 I´ll have to trust your word.

  do you volunteer to maintain and test MySQL?

 If I find a volunteer, will you continue shipping it?.

 I smell a proxy war against Oracle for their Oracle Linux efforts,
 totally politically motivated and with dubious technical reasons. But
 hey, that´s just me.

 I quote from the feature page:

 Recent changes made by Oracle indicate they are moving the MySQL
 project to be more closed. They are no longer publishing any useful
 information about security issues (CVEs), and they are not providing
 complete regression tests any more, and a very large fraction of the
 mysql bug database is now not public.

 Do you dispute the truth of any of these statements? If you accept them
 as truthful, do you consider them insignificant? If so, why?

The reply from Andrew renders this moot. If upstream is willing to
maintain MySQL in Fedora then the whole replace it because it is hard
to maintain does not make sense. We should either stay with MySQL or
ship both but there is no reason to replace it anymore.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Proposed F19 Feature: Replace MySQL with MariaDB

[drago01]

On Thu, Jan 24, 2013 at 12:31 PM, Frank Murphy frankl...@gmail.com wrote:
 On Thu, 24 Jan 2013 12:24:33 +0100
 drago01 drag...@gmail.com wrote:



 The reply from Andrew renders this moot. If upstream is willing to
 maintain MySQL in Fedora then the whole replace it because it is
 hard to maintain does not make sense. We should either stay with
 MySQL or ship both but there is no reason to replace it anymore.

 Sorry I can't find this reply?

http://lists.fedoraproject.org/pipermail/devel/2013-January/176778.html
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Proposed F19 Feature: Replace MySQL with MariaDB

[drago01]

On Thu, Jan 24, 2013 at 1:22 PM, Karel Volný kvo...@redhat.com wrote:
 Dne Čt 24. ledna 2013 12:24:33, drago01 napsal(a):
 On Thu, Jan 24, 2013 at 10:34 AM, Adam Williamson awill...@redhat.com
 wrote:
  I quote from the feature page:
 
  Recent changes made by Oracle indicate they are moving the MySQL
  project to be more closed. They are no longer publishing any useful
  information about security issues (CVEs), and they are not providing
  complete regression tests any more, and a very large fraction of the
  mysql bug database is now not public.
 
  Do you dispute the truth of any of these statements? If you accept them
  as truthful, do you consider them insignificant? If so, why?

 The reply from Andrew renders this moot.

 really?

 how does that reply provide the missing informations that Adam points out?

I doubt that it is hard to maintain for upstream ... that would be just odd.

 If upstream is willing to maintain MySQL in Fedora then the whole replace
 it because it is hard to maintain does not make sense. We should either
 stay with MySQL or ship both but there is no reason to replace it anymore.

 I guess no one opposes keeping both ... in fact, the feature page says:

 MySQL will continue to be available for at least one release,

I know it just does not make sense to remove something from the
distribution if there is someone (in this case even upstream) willing
to maintain it.

 as for choosing which one will be default ... it is nice that upstream wants
 to support us, but what were they doing those 10 years of Fedora development
 (or 13.5 years since first mysql rpm changelog entry)?

 are they interested only when they see they could lose marketshare?

I can't answer that ask them ;)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Proposed F19 Feature: Replace MySQL with MariaDB

[drago01]

On Thu, Jan 24, 2013 at 2:08 PM, Karel Volný kvo...@redhat.com wrote:
 Dne Čt 24. ledna 2013 13:25:08, drago01 napsal(a):
 On Thu, Jan 24, 2013 at 1:22 PM, Karel Volný kvo...@redhat.com wrote:
  Dne Čt 24. ledna 2013 12:24:33, drago01 napsal(a):
  On Thu, Jan 24, 2013 at 10:34 AM, Adam Williamson awill...@redhat.com
 
  wrote:
   I quote from the feature page:
  
   Recent changes made by Oracle indicate they are moving the MySQL
   project to be more closed. They are no longer publishing any useful
   information about security issues (CVEs), and they are not providing
   complete regression tests any more, and a very large fraction of the
   mysql bug database is now not public.
  
   Do you dispute the truth of any of these statements? If you accept them
   as truthful, do you consider them insignificant? If so, why?
 
  The reply from Andrew renders this moot.
 
  really?
 
  how does that reply provide the missing informations that Adam points out?

 I doubt that it is hard to maintain for upstream ...

 but hard to maintain is not what Adam said, right?

Oh missed the reference to Adam's mail ... yeah indeed that one did
not get addressed.

 that would be just odd.

 not that much - considering how many people have troubles to adhere to Fedora
 packaging rules :-)

;)

 I know it just does not make sense to remove something from the
 distribution if there is someone (in this case even upstream) willing
 to maintain it.

 there was no one willing to maintain it by the time the feature was proposed

 this has changed since

Yeah and that's what I am pointing out.

 have you seen anyone insisting on removing MySQL despite the fact there may be
 a new maintainer?

No.

 or what urges you to keep talking about the removal in such
 way?

Well am I just pointing out that the situation have or seems to be
changing since the feature has been proposed.
That's it. There is no conspiracy or any other motives behind my
mails. Oh and I don't work for Oracle ;)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test