Re: Arjan talk at the Linux Plumbers Conference
mike cloaked (mike.cloa...@gmail.com) said: > Are any Fedora developers going to be going to the talk by Arjan on > system updates > (https://plus.google.com/114657443111661859546/posts/MGuHZdw2L9R) > at the Linux Plumbers Conference? Sure, there's a bunch of people who develop stuff for Fedora here. There's nothing inherently bad or incorrect about what he's designed here, but the use cases that it's designed for would tend to break the administrators and certain usage cases of Fedora and derived distributions that we have, and so it may not be practical in a Fedora context. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
On 08/30/2012 08:55 AM, Bill Nottingham wrote: > Bill Nottingham (nott...@redhat.com) said: >> Olaf Kirch (o...@suse.de) said: >>> On Wednesday 29 August 2012 21:56:45 Jóhann B. Guðmundsson wrote: On 08/29/2012 11:58 AM, Olaf Kirch wrote: > Your feedback is very much welcome! The network management/solution of the future most likely ( at least will need to ) be something that is integrated into ( or with ) systemd/Core OS >>> >>> Indeed, and that's where I'd like to go. Which is one of the reasons >>> for choosing dbus as the transport. >> >> The systemd people do have some ideas they've already been kicking around >> for this already... have you seen it? > > To be clear, I'm not really convinced yet that this is something we need... > there is a lot of legacy admin overhead and infrastructure that is highly > resistant to change here. Speaking as an admin I think something needs to happen here. The current shell script/NetworkManager chimera is really ugly since they don't cooperate well I really wished things would go one way or the other or someone would come up with something that replaces both but I consider the current situation as a worst case scenario. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Reminder: Fedora 18 Alpha Go/No-Go Meeting #2, Thursday, August 30 @ 17:00 EDT
Join us on irc.freenode.net in #fedora-meeting for this important meeting, wherein we shall determine the readiness of the Fedora 18 Alpha. As previously announced last week, we moved Go/No-Go to Thursday. Thursday, August 30, 2012 @21:00 UTC (17:00 EDT/14:00 PDT/23:00 CEST) "Before each public release Development, QA and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the Go/No-Go Meeting." "Verifying that the Release criteria are met is the responsibility of the QA Team." For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime, keep an eye on the Fedora 18 Alpha Blocker list: http://qa.fedoraproject.org/blockerbugs/current Jaroslav -- Jaroslav Řezník Your schedule wrangler Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://www.redhat.com/ ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
On 08/29/2012 06:52 PM, Gerry Reno wrote: > (!) DirectFB/core/vt: Error opening `/dev/tty1'! > --> Permission denied > (!) DirectFB/Core: Could not initialize 'system_core' core! > --> A general initialization error occured > (#) DirectFBError [DirectFBCreate() failed]: A general initialization > error occured > Segmentation fault > > I set the perms in the udev rules to 0666 but the tty does not setup that > way for some reason. Did you reboot after setting the udev rules? My /dev/tty0 and /dev/tty1 are 0660. (I'm running Fedora 18). If you chmod 660 /dev/tty*, does it work? ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
On 08/28/2012 01:01 PM, Sebastian Dyroff wrote: > Hey, > > My name is Sebastian Dyroff. I am from Germany, Berlin. I've just > finished my studies of computer science. Welcome Sebastian. > > I am a Linux user for a decade or so and tried a lot of different > Distros. For a long time I used gentoo (don't know if it is a good > idea to tell here:-) ), but switched to Fedora a while ago. As a matter of fact I have never seen any animosity against any users/developers coming from any distribution. :-) > > I really would like to see wiki2beamer (Bug 851891) included in > fedora, an thought i should try to build a rpm for the package. It > converts wiki-like syntax to latex beamer syntax and is written in > python. > Currently I need to get some feedback, to get the spec-file meet the > fedora standards. > > I also built a rpm for lprof (Bug 851641), a colour management > profiler, but upstream seems dead and there are some problems that > might prevent that the package will be part of Fedora. But if someone > wants that package included and is willing to help me fixing the > issues or at least points me in the right direction I would continue > to work on this. > > > Best regards > > Sebastian Dyroff Regards, -- José Matos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
On 08/30/2012 09:00 AM, Tom Callaway wrote:
> On 08/29/2012 06:52 PM, Gerry Reno wrote:
>
>> (!) DirectFB/core/vt: Error opening `/dev/tty1'!
>> --> Permission denied
>> (!) DirectFB/Core: Could not initialize 'system_core' core!
>> --> A general initialization error occured
>> (#) DirectFBError [DirectFBCreate() failed]: A general initialization
>> error occured
>> Segmentation fault
>>
>> I set the perms in the udev rules to 0666 but the tty does not setup
>> that way for some reason.
> Did you reboot after setting the udev rules? My /dev/tty0 and /dev/tty1
> are 0660. (I'm running Fedora 18).
>
> If you chmod 660 /dev/tty*, does it work?
>
> ~tom
>
> ==
> Fedora Project
>
Yes, these settings have been through many reboots and they are not setting the
tty mode correctly.
When I chmod g+r tty{0,1} the permission error goes away but it has other
problems with setting 1024x768 for fbdev.
$ dfbinfo
~~| DirectFB 1.6.1 |~~
(c) 2001-2012 The world wide DirectFB Open Source Community
(c) 2000-2004 Convergence (integrated media) GmbH
(*) DirectFB/Core: Single Application Core. (2012-08-29 21:15)
(*) Direct/Memcpy: Using libc memcpy()
(*) Direct/Thread: Started 'Fusion Dispatch' (-1) [MESSAGING OTHER/OTHER
0/0] <8388608>...
(*) Direct/Thread: Started 'VT Switcher' (-1) [CRITICAL OTHER/OTHER 0/0]
<8388608>...
(*) Direct/Thread: Started 'VT Flusher' (-1) [DEFAULT OTHER/OTHER 0/0]
<8388608>...
(*) DirectFB/FBDev: Found 'inteldrmfb' (ID 0) with frame buffer at
0xc0064000, 8100k (MMIO 0x, 0k)
(*) Direct/Thread: Started 'Hotplug with Linux Input' (-1) [INPUT
OTHER/OTHER 0/0] <8388608>...
(*) DirectFB/Input: Hot-plug detection enabled with Linux Input Driver
(*) DirectFB/Input: Hot-plug detection enabled with Input Hub Driver
(*) Direct/Thread: Started 'Keyboard Input' (-1) [INPUT OTHER/OTHER 0/0]
<8388608>...
(*) DirectFB/Input: Keyboard 0.9 (directfb.org)
(*) DirectFB/Genefx: MMX detected and enabled
(*) DirectFB/Graphics: MMX Software Rasterizer 0.7 (directfb.org)
(*) DirectFB/Core/WM: Default 0.3 (directfb.org)
(!!!) *** ONCE [no mode found for 1024x768] *** [fbdev.c:1354 in
dfb_fbdev_find_mode()]
(*) FBDev/Mode: Setting 1024x768 RGB32
(*) FBDev/Mode: Switched to 1024x768 (virtual 1024x768) at 32 bit (RGB32),
pitch 7680
(!) DirectFB/FBDev: Could not set gamma ramp--> Invalid argument
(*) FBDev/Mode: Setting 1024x768 RGB16
(*) FBDev/Mode: Switched to 1024x768 (virtual 1024x768) at 16 bit (RGB16),
pitch 7680
(!) DirectFB/FBDev: Could not set gamma ramp--> Invalid argument
Screen (00) FBDev Primary Screen(primary screen)
Caps: VSYNC POWER_MANAGEMENT
Layer (00) FBDev Primary Layer (primary layer)
Type:GRAPHICS
Caps:SURFACE BRIGHTNESS CONTRAST SATURATION
Input (00) Keyboard(primary keyboard)
Vendor ID: 0x
Product ID: 0x
Type: KEYBOARD
Caps: KEYS
Min. Keycode: 0
Max. Keycode: 127
Gerry
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
If I run the command under root I see a more extensive output but having same problems w/1024x768: # dfbinfo ~~| DirectFB 1.6.1 |~~ (c) 2001-2012 The world wide DirectFB Open Source Community (c) 2000-2004 Convergence (integrated media) GmbH (*) DirectFB/Core: Single Application Core. (2012-08-29 21:15) (*) Direct/Memcpy: Using libc memcpy() (*) Direct/Thread: Started 'Fusion Dispatch' (-1) [MESSAGING OTHER/OTHER 0/0] <8388608>... (*) Direct/Thread: Started 'VT Switcher' (-1) [CRITICAL OTHER/OTHER 0/0] <8388608>... (*) Direct/Thread: Started 'VT Flusher' (-1) [DEFAULT OTHER/OTHER 0/0] <8388608>... (*) DirectFB/FBDev: Found 'inteldrmfb' (ID 0) with frame buffer at 0xc0064000, 8100k (MMIO 0x, 0k) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>... (*) DirectFB/Input: Power Button (1) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>... (*) DirectFB/Input: AT Translated Set 2 keyboard (2) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>... (*) DirectFB/Input: Hewlett-Packard HP f2100a Opti (3) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>... (*) DirectFB/Input: SynPS/2 Synaptics TouchPad (4) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>... (*) DirectFB/Input: Video Bus (5) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>... (*) DirectFB/Input: Logitech Logitech Illuminated K (6) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>... (*) DirectFB/Input: Logitech Logitech Illuminated K (7) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>... (*) DirectFB/Input: Video Bus (8) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>... (*) DirectFB/Input: ST LIS3LV02DL Accelerometer (9) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>... (*) DirectFB/Input: HP Truevision HD (10) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>... (*) DirectFB/Input: HP WMI hotkeys (11) 0.1 (directfb.org) (*) Direct/Thread: Started 'Hotplug with Linux Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>... (*) DirectFB/Input: Hot-plug detection enabled with Linux Input Driver (*) DirectFB/Input: Hot-plug detection enabled with Input Hub Driver (*) Direct/Thread: Started 'Keyboard Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>... (*) DirectFB/Input: Keyboard 0.9 (directfb.org) (*) Direct/Thread: Started 'PS/2 Input' (-1) [INPUT OTHER/OTHER 0/0] <8388608>... (*) DirectFB/Input: IMPS/2 Mouse 1.0 (directfb.org) (*) DirectFB/Genefx: MMX detected and enabled (*) DirectFB/Graphics: MMX Software Rasterizer 0.7 (directfb.org) (*) DirectFB/Core/WM: Default 0.3 (directfb.org) (!!!) *** ONCE [no mode found for 1024x768] *** [fbdev.c:1354 in dfb_fbdev_find_mode()] (*) FBDev/Mode: Setting 1024x768 RGB32 (*) FBDev/Mode: Switched to 1024x768 (virtual 1024x768) at 32 bit (RGB32), pitch 7680 (!) DirectFB/FBDev: Could not set gamma ramp--> Invalid argument (*) FBDev/Mode: Setting 1024x768 RGB16 (*) FBDev/Mode: Switched to 1024x768 (virtual 1024x768) at 16 bit (RGB16), pitch 7680 (!) DirectFB/FBDev: Could not set gamma ramp--> Invalid argument Screen (00) FBDev Primary Screen(primary screen) Caps: VSYNC POWER_MANAGEMENT Layer (00) FBDev Primary Layer (primary layer) Type:GRAPHICS Caps:SURFACE BRIGHTNESS CONTRAST SATURATION Input (10) Power Button Vendor ID: 0x Product ID: 0x0001 Type: Caps: KEYS Min. Keycode: -1 Max. Keycode: -1 Input (00) AT Translated Set 2 keyboard(primary keyboard) Vendor ID: 0x0001 Product ID: 0x0001 Type: KEYBOARD REMOTE Caps: KEYS Min. Keycode: 0 Max. Keycode: 127 Input (01) Hewlett-Packard HP f2100a Opti (primary mouse) Vendor ID: 0x03f0 Product ID: 0x2003 Type: MOUSE Caps: KEYS AXES BUTTONS Min. Keycode: -1 Max. Keycode: -1 Max. Axis: 2 Max. Button: 2 Input (11) SynPS/2 Synaptics TouchPad Vendor ID: 0x0002 Product ID: 0x0007 Type: MOUSE Caps: KEYS AXES BUTTONS Min. Keycode: -1 Max. Keycode: -1 Max. Axis: 1 Max. Button:
Re: F17: DirectFB
On 08/30/2012 09:26 AM, Gerry Reno wrote: > If I run the command under root I see a more extensive output but having same > problems w/1024x768: > (*) DirectFB/Core/WM: Default 0.3 (directfb.org) > (!!!) *** ONCE [no mode found for 1024x768] *** [fbdev.c:1354 in > dfb_fbdev_find_mode()] Gerry, what's the video card in that computer, and are you using an out-of-Fedora driver? ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
After manually setting tty0 and tty1 using the previous chmod command now when I reboot I get a strange mix of tty settings. Originally they would all have permissions like this: crw--w. 1 root tty 4, 10 Aug 30 2012 /dev/tty10 But now they are a mix of settings: # ls -l /dev/tty* crw-rw-rw-. 1 root tty 5, 0 Aug 30 2012 /dev/tty crw-rw. 1 root tty 4, 0 Aug 30 2012 /dev/tty0 crw-rw. 1 root tty 4, 1 Aug 30 2012 /dev/tty1 crw--w. 1 root tty 4, 10 Aug 30 2012 /dev/tty10 crw--w. 1 root tty 4, 11 Aug 30 2012 /dev/tty11 crw--w. 1 root tty 4, 12 Aug 30 2012 /dev/tty12 crw--w. 1 root tty 4, 13 Aug 30 2012 /dev/tty13 crw--w. 1 root tty 4, 14 Aug 30 2012 /dev/tty14 crw--w. 1 root tty 4, 15 Aug 30 2012 /dev/tty15 crw--w. 1 root tty 4, 16 Aug 30 2012 /dev/tty16 crw--w. 1 root tty 4, 17 Aug 30 2012 /dev/tty17 crw--w. 1 root tty 4, 18 Aug 30 2012 /dev/tty18 crw--w. 1 root tty 4, 19 Aug 30 2012 /dev/tty19 crw-rw. 1 root tty 4, 2 Aug 30 2012 /dev/tty2 crw--w. 1 root tty 4, 20 Aug 30 2012 /dev/tty20 crw--w. 1 root tty 4, 21 Aug 30 2012 /dev/tty21 crw--w. 1 root tty 4, 22 Aug 30 2012 /dev/tty22 crw--w. 1 root tty 4, 23 Aug 30 2012 /dev/tty23 crw--w. 1 root tty 4, 24 Aug 30 2012 /dev/tty24 crw--w. 1 root tty 4, 25 Aug 30 2012 /dev/tty25 crw--w. 1 root tty 4, 26 Aug 30 2012 /dev/tty26 crw--w. 1 root tty 4, 27 Aug 30 2012 /dev/tty27 crw--w. 1 root tty 4, 28 Aug 30 2012 /dev/tty28 crw--w. 1 root tty 4, 29 Aug 30 2012 /dev/tty29 crw-rw. 1 root tty 4, 3 Aug 30 2012 /dev/tty3 crw--w. 1 root tty 4, 30 Aug 30 2012 /dev/tty30 crw--w. 1 root tty 4, 31 Aug 30 2012 /dev/tty31 crw--w. 1 root tty 4, 32 Aug 30 2012 /dev/tty32 crw--w. 1 root tty 4, 33 Aug 30 2012 /dev/tty33 crw--w. 1 root tty 4, 34 Aug 30 2012 /dev/tty34 crw--w. 1 root tty 4, 35 Aug 30 2012 /dev/tty35 crw--w. 1 root tty 4, 36 Aug 30 2012 /dev/tty36 crw--w. 1 root tty 4, 37 Aug 30 2012 /dev/tty37 crw--w. 1 root tty 4, 38 Aug 30 2012 /dev/tty38 crw--w. 1 root tty 4, 39 Aug 30 2012 /dev/tty39 crw-rw. 1 root tty 4, 4 Aug 30 2012 /dev/tty4 crw--w. 1 root tty 4, 40 Aug 30 2012 /dev/tty40 crw--w. 1 root tty 4, 41 Aug 30 2012 /dev/tty41 crw--w. 1 root tty 4, 42 Aug 30 2012 /dev/tty42 crw--w. 1 root tty 4, 43 Aug 30 2012 /dev/tty43 crw--w. 1 root tty 4, 44 Aug 30 2012 /dev/tty44 crw--w. 1 root tty 4, 45 Aug 30 2012 /dev/tty45 crw--w. 1 root tty 4, 46 Aug 30 2012 /dev/tty46 crw--w. 1 root tty 4, 47 Aug 30 2012 /dev/tty47 crw--w. 1 root tty 4, 48 Aug 30 2012 /dev/tty48 crw--w. 1 root tty 4, 49 Aug 30 2012 /dev/tty49 crw-rw. 1 root tty 4, 5 Aug 30 2012 /dev/tty5 crw--w. 1 root tty 4, 50 Aug 30 2012 /dev/tty50 crw--w. 1 root tty 4, 51 Aug 30 2012 /dev/tty51 crw--w. 1 root tty 4, 52 Aug 30 2012 /dev/tty52 crw--w. 1 root tty 4, 53 Aug 30 2012 /dev/tty53 crw--w. 1 root tty 4, 54 Aug 30 2012 /dev/tty54 crw--w. 1 root tty 4, 55 Aug 30 2012 /dev/tty55 crw--w. 1 root tty 4, 56 Aug 30 2012 /dev/tty56 crw--w. 1 root tty 4, 57 Aug 30 2012 /dev/tty57 crw--w. 1 root tty 4, 58 Aug 30 2012 /dev/tty58 crw--w. 1 root tty 4, 59 Aug 30 2012 /dev/tty59 crw-rw. 1 root tty 4, 6 Aug 30 2012 /dev/tty6 crw--w. 1 root tty 4, 60 Aug 30 2012 /dev/tty60 crw--w. 1 root tty 4, 61 Aug 30 2012 /dev/tty61 crw--w. 1 root tty 4, 62 Aug 30 2012 /dev/tty62 crw--w. 1 root tty 4, 63 Aug 30 2012 /dev/tty63 crw-rw. 1 root tty 4, 7 Aug 30 2012 /dev/tty7 crw-rw. 1 root tty 4, 8 Aug 30 2012 /dev/tty8 crw-rw. 1 root tty 4, 9 Aug 30 2012 /dev/tty9 crw-rw. 1 root dialout 166, 0 Aug 30 2012 /dev/ttyACM0 crw-rw. 1 root dialout 4, 64 Aug 30 2012 /dev/ttyS0 crw-rw. 1 root dialout 4, 65 Aug 30 2012 /dev/ttyS1 crw-rw. 1 root dialout 4, 66 Aug 30 2012 /dev/ttyS2 crw-rw. 1 root dialout 4, 67 Aug 30 2012 /dev/ttyS3 Gerry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
On 08/30/2012 09:40 AM, Tom Callaway wrote: > On 08/30/2012 09:26 AM, Gerry Reno wrote: >> If I run the command under root I see a more extensive output but having >> same problems w/1024x768: >> (*) DirectFB/Core/WM: Default 0.3 (directfb.org) >> (!!!) *** ONCE [no mode found for 1024x768] *** [fbdev.c:1354 in >> dfb_fbdev_find_mode()] > Gerry, what's the video card in that computer, and are you using an > out-of-Fedora driver? > > ~tom > > == > Fedora Project > My laptop has one of the new Intel i7 Ivy Bridge CPU w/iGPU (Intel HD4000) plus Nvidia Geforce GT 650M Gerry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
On 08/30/2012 09:47 AM, Gerry Reno wrote: > On 08/30/2012 09:40 AM, Tom Callaway wrote: >> On 08/30/2012 09:26 AM, Gerry Reno wrote: >>> If I run the command under root I see a more extensive output but having >>> same problems w/1024x768: >>> (*) DirectFB/Core/WM: Default 0.3 (directfb.org) >>> (!!!) *** ONCE [no mode found for 1024x768] *** [fbdev.c:1354 in >>> dfb_fbdev_find_mode()] >> Gerry, what's the video card in that computer, and are you using an >> out-of-Fedora driver? >> >> ~tom >> >> == >> Fedora Project >> > My laptop has one of the new Intel i7 Ivy Bridge CPU w/iGPU (Intel HD4000) > plus Nvidia Geforce GT 650M > I did not install any third-party driver. Just installed and ran F17 as-is out of the box. > Gerry > > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
On 8/30/12 9:26 AM, Gerry Reno wrote: (*) DirectFB/FBDev: Found 'inteldrmfb' (ID 0) with frame buffer at 0xc0064000, 8100k (MMIO 0x, 0k) So this says you're using the intel drm driver... (*) DirectFB/Core/WM: Default 0.3 (directfb.org) (!!!) *** ONCE [no mode found for 1024x768] *** [fbdev.c:1354 in dfb_fbdev_find_mode()] (*) FBDev/Mode: Setting 1024x768 RGB32 (*) FBDev/Mode: Switched to 1024x768 (virtual 1024x768) at 32 bit (RGB32), pitch 7680 (!) DirectFB/FBDev: Could not set gamma ramp--> Invalid argument (*) FBDev/Mode: Setting 1024x768 RGB16 (*) FBDev/Mode: Switched to 1024x768 (virtual 1024x768) at 16 bit (RGB16), pitch 7680 (!) DirectFB/FBDev: Could not set gamma ramp--> Invalid argument ... and this I believe is saying that drm's emulation of an fbdev interface is rather incomplete. Which I believe means either directfb needs to be taught about KMS, or KMS's fbdev emulation needs to be better, or both. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 853147] New: Please drop redundant BR: perl(LWP::RobotUA)
https://bugzilla.redhat.com/show_bug.cgi?id=853147 Bug ID: 853147 QA Contact: extras...@fedoraproject.org Severity: unspecified Version: rawhide Priority: unspecified CC: mmasl...@redhat.com, perl-de...@lists.fedoraproject.org, ppi...@redhat.com Assignee: ppi...@redhat.com Summary: Please drop redundant BR: perl(LWP::RobotUA) Regression: --- Story Points: --- Classification: Fedora OS: Unspecified Reporter: p...@city-fan.org Type: Bug Documentation: --- Hardware: Unspecified Mount Type: --- Status: NEW Component: perl-WWW-RobotRules Product: Fedora A buildreq of perl(LWP::RobotUA) has recently been added to perl-WWW-RobotRules, and this causes a build dependency cycle between perl-libwww-perl and perl-WWW-RobotRules. Having looked at the WWW-RobotRules distribution, I believe that nothing there actually uses LWP::RobotUA (the only references seem to be in examples - t/misc/dbmrobot is more example code than test) and indeed a build without perl-libwww-perl in the buildroot passes without complaint. So please remove this redundant buildreq to resolve the build dependency cycle. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 849328] perl-Module-Build-0.4003 is available
https://bugzilla.redhat.com/show_bug.cgi?id=849328 Paul Howarth changed: What|Removed |Added CC||p...@city-fan.org --- Comment #4 from Paul Howarth --- This package has a buildreq of perl(Module::Build), i.e. itself, which is not good. It's not needed either because the package takes care to build against itself. Please remove this redundant buildreq that causes a build dependency cycle. -- You are receiving this mail because: You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
root password of Fedora-18-Alpha-TC3
Hi, After many work, I install Fedora-18-Alpha-TC3 in VirtualBox , but I don't have root password , don't remember ask me for that . this is correct ? Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
On 2012-08-29 22:43, Olaf Kirch wrote: Hi Adam, On Thursday 30 August 2012 04:16:23 Adam Williamson wrote: > *** Network Manager is just another daemon created for a task > which historically often did not need any daemons. It's almost as if > the new generation of Unix hackers wants to redo everything - > in x10 or x100 times bloated and more complex way than it was done > before. > One, a modern network management framework should run as a service. > The > kernel offers a plethora of notifications via rtnetlink, and > increasingly > expects user space to react to these (for instance in the IPv6 area). > Running a network management daemon allows us to track the state, > detect > changes, and react to them appropriately. There appears to be some cognitive dissonance in the document. It seems odd to criticize NetworkManager solely for being a bloated, complex daemon, and then, having dismissed NM, in describing the ideal next-generation network management framework, declare that it ought to be a bloated complex daemon... That dissonance is explained easily. Only the second section you quote was written by me, the other is a comment from Denis Vlasenko, actually :-) Ah, I was wondering about the strange layout of the mail, but didn't grok it was hum vs. you. Makes more sense now! Thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root password of Fedora-18-Alpha-TC3
Hi there, Seems to be a bug with the new features, details here https://bugzilla.redhat.com/show_bug.cgi?id=849250. You can reset the root password by following the steps outlined in the following guide: https://fedoraproject.org/wiki/How_to_reset_a_root_password . Basically boot to single user mode, passwd, reboot. Good luck. -- Original Message -- From: "Sérgio Basto" To: "Development discussions related to Fedora" Sent: 30.08.2012 21:22:56 Subject: root password of Fedora-18-Alpha-TC3 Hi, After many work, I install Fedora-18-Alpha-TC3 in VirtualBox , but I don't have root password , don't remember ask me for that . this is correct ? Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root password of Fedora-18-Alpha-TC3
On 2012-08-30 11:22, Sérgio Basto wrote: Hi, After many work, I install Fedora-18-Alpha-TC3 in VirtualBox , but I don't have root password , don't remember ask me for that . this is correct ? There isn't exactly a 'yes' or 'no' answer to that question, it's a bit complicated. The original design was for there to be no root password set: the idea is to use an Ubuntu-style model where the first created user is an 'admin user' who can perform all admin tasks - they can do admin tasks in apps that use PolicyKit by entering their own password rather than root's, and from the console they can run anything root-y via sudo with their own password. This system is actually already available - if you check the 'admin user' checkbox in firstboot when creating a user, all of the above is put in place. However, there are some holes in the plan. firstboot doesn't enforce creation of an an admin user, which it probably should in this design, and more importantly, there's no firstboot for non-graphical installs, so you need to be able to create a root password in that case, or else you'll be entirely unable to log in to the installed system without some kind of rescue operation (as root has no password and there are no user accounts): https://bugzilla.redhat.com/show_bug.cgi?id=849250 The short-term plan for Alpha is that there will be a root password 'spoke' in anaconda. It's optional, because making it mandatory would be tricky and not really fit into the new anaconda design. This should be implemented for TC4. This is just the easiest short-term solution, though, and anaconda team may come up with something different (hopefully, better...) for Beta / Final. (Of course, as in Ubuntu, if you don't like the model and want to stick with the old-school system instead, you can just do 'sudo passwd' to set a password for the root user and take your user out of the 'wheel' group so it can't use sudo any more, though I don't know a one-command way to make your user a non-admin user for PolicyKit, hence causing it to ask you for the root password rather than your own for admin operations). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Infrastructure announces status.fedoraproject.org
Greetings. I'm happy to announce the general availability of our status.fedoraproject.org site. This site provides an easy way for Fedora contributors and users to check on the status of services provided by Fedora Infrastructure. The site auto reloads every minute, and also provides a rss feed at http://status.fedoraproject.org/changes.rss of any changes. If you run into a problem or issue that is not reflected at status.fedoraproject.org, please do report it to us in #fedora-admin on irc.freenode.net or via ticket at https://fedorahosted.org/fedora-infrastructure/newticket We update the site status information manually so we need to be aware of the issue in order to keep the site accurate. As with everything in Fedora Infrastructure, this application is open source. Source is available from: http://git.fedorahosted.org/git/fedora-status.git and is released under a GPLv2+ license. This application is hosted at https://openshift.redhat.com to avoid any issues with outages in our infrastructure affecting status reporting. kevin signature.asc Description: PGP signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Infrastructure announces status.fedoraproject.org
Great, but the link under "Fedora Packages App" should be either undefined or https://apps.fedoraproject.org/packages/, not the current 404-pointing value of "UNKNOWN". BTW, http://www.smolts.org/ returns 503 currently, but I do not know if this is somehow related with "Everything seems to be working" textual status (probably "working" is about the real service, not the front-page which fails at the moment) Kind Regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root password of Fedora-18-Alpha-TC3
On Thu, Aug 30, 2012 at 12:03:39PM -0700, Adam Williamson wrote: > bit complicated. The original design was for there to be no root > password set: the idea is to use an Ubuntu-style model where the > first created user is an 'admin user' who can perform all admin > tasks - they can do admin tasks in apps that use PolicyKit by I call that a "BU Linux style model". :) -- Matthew Miller Senior Systems Architect -- SEAS Computing Harvard School of Engineering & Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root password of Fedora-18-Alpha-TC3
On Thu, Aug 30, 2012 at 12:03:39PM -0700, Adam Williamson wrote: > (Of course, as in Ubuntu, if you don't like the model and want to > stick with the old-school system instead, you can just do 'sudo > passwd' to set a password for the root user and take your user out > of the 'wheel' group so it can't use sudo any more, though I don't > know a one-command way to make your user a non-admin user for > PolicyKit, hence causing it to ask you for the root password rather > than your own for admin operations). Removing yourself from wheel should do that too, shouldn't it? (I believe it's implemented by "AdminIdentities=unix-group:wheel".) Or am I missing something? -- Matthew Miller Senior Systems Architect -- SEAS Computing Harvard School of Engineering & Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root password of Fedora-18-Alpha-TC3
On 2012-08-30 14:50, Matthew Miller wrote: On Thu, Aug 30, 2012 at 12:03:39PM -0700, Adam Williamson wrote: (Of course, as in Ubuntu, if you don't like the model and want to stick with the old-school system instead, you can just do 'sudo passwd' to set a password for the root user and take your user out of the 'wheel' group so it can't use sudo any more, though I don't know a one-command way to make your user a non-admin user for PolicyKit, hence causing it to ask you for the root password rather than your own for admin operations). Removing yourself from wheel should do that too, shouldn't it? (I believe it's implemented by "AdminIdentities=unix-group:wheel".) Or am I missing something? You're very probably right, I hadn't looked into exactly how it's implemented in PK. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
On 08/30/2012 06:55 AM, Bill Nottingham wrote: Bill Nottingham (nott...@redhat.com) said: Olaf Kirch (o...@suse.de) said: On Wednesday 29 August 2012 21:56:45 Jóhann B. Guðmundsson wrote: On 08/29/2012 11:58 AM, Olaf Kirch wrote: Your feedback is very much welcome! The network management/solution of the future most likely ( at least will need to ) be something that is integrated into ( or with ) systemd/Core OS Indeed, and that's where I'd like to go. Which is one of the reasons for choosing dbus as the transport. The systemd people do have some ideas they've already been kicking around for this already... have you seen it? To be clear, I'm not really convinced yet that this is something we need... there is a lot of legacy admin overhead and infrastructure that is highly resistant to change here. I dont need convincing integrating network handling into systemd/Core OS only makes sense to me diversity in this area however does not and never has... Of what legacy admin overhead are you referring to that would/might come by that? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
On 08/30/2012 11:16 AM, Adam Jackson wrote: > On 8/30/12 9:26 AM, Gerry Reno wrote: > >> (*) DirectFB/FBDev: Found 'inteldrmfb' (ID 0) with frame buffer at >> 0xc0064000, 8100k (MMIO 0x, 0k) > > So this says you're using the intel drm driver... > > >> (*) DirectFB/Core/WM: Default 0.3 (directfb.org) >> (!!!) *** ONCE [no mode found for 1024x768] *** [fbdev.c:1354 in >> dfb_fbdev_find_mode()] >> (*) FBDev/Mode: Setting 1024x768 RGB32 >> (*) FBDev/Mode: Switched to 1024x768 (virtual 1024x768) at 32 bit >> (RGB32), pitch 7680 >> (!) DirectFB/FBDev: Could not set gamma ramp--> Invalid argument >> (*) FBDev/Mode: Setting 1024x768 RGB16 >> (*) FBDev/Mode: Switched to 1024x768 (virtual 1024x768) at 16 bit >> (RGB16), pitch 7680 >> (!) DirectFB/FBDev: Could not set gamma ramp--> Invalid argument > > ... and this I believe is saying that drm's emulation of an fbdev interface > is rather incomplete. > > Which I believe means either directfb needs to be taught about KMS, or KMS's > fbdev emulation needs to be better, or both. > > - ajax > Opened bug: https://bugzilla.redhat.com/show_bug.cgi?id=853268 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Network configuration future
"Jóhann B. Guðmundsson" (johan...@gmail.com) said: > I dont need convincing integrating network handling into > systemd/Core OS only makes sense to me diversity in this area > however does not and never has... > > Of what legacy admin overhead are you referring to that would/might > come by that? There are 15+ years of legacy implementations of the old configuration format and tools expectations. It has been wired into existing documentation, and multiple tools in the existing OS. This says nothing of administrator's kickstart scripts, deployment tools, and existing brains, all of which are highly resistant to change that merely impacts them in the form of swapping config format A for config format B. (Seriously, as Miloslav said - the configuration format is the least interesting part of any change here.) I'm not saying you *can't* do it, but it's also not something to do lightly. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaned packages
Due to lack of time, I am dropping my maintainership for the following: - bouncycastle, bouncycastle-mail, bouncycastle-tsp: New version available, but not API compatible with the itext version (2.1.7) we have. I have an almost complete patch for itext-2.1.7 for the API changes for those who are interested. But itext build fails in tho GCJ AOT bits compilation phase. - calf: No releases for a while but the trunk is active. - clementine: Very cooperative upstream. They have a constant habit of bundling 3rd party libraries. But they gladly accept patches to factor those out. So every clementine release comes with a debate with upstream, exchanging patches etc. - faust - itext: Cannot update to 5.x due to license issues. also see above at bouncycastle. - kde-plasma-yawp - libechonest: needed by clementine - libfreebob: this is an obsolete library, replaced by libffado - libqxt: needed by clementine - lv2-zynadd-plugins - lv2dynparam - lxsplit - qjson: needed by clementine - qtiocompressor: needed by clementine - qtlockedfile: needed by clementine - qtsingleapplication: needed by clementine - sha2: needed by clementine Additionally I am dropping my comaintainership for the following. These packages still have primary maintainers but I am sure these maintainers won't mind additional help: - ladspa-amb-plugins - ladspa-cmt-plugins - ladspa-fil-plugins - ladspa-swh-plugins - lv2-invada-plugins - kmplayer - pdfmerge - pdftk - raptor - rasqal - redland - redland-bindings - rosegarden4 Feel free to take anything you need. Best, Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Infrastructure announces status.fedoraproject.org
On Fri, 31 Aug 2012 00:19:15 +0300 Alek Paunov wrote: > Great, but the link under "Fedora Packages App" should be either > undefined or https://apps.fedoraproject.org/packages/, not the > current 404-pointing value of "UNKNOWN". Fixed. Thanks. > BTW, http://www.smolts.org/ returns 503 currently, but I do not know > if this is somehow related with "Everything seems to be working" > textual status (probably "working" is about the real service, not the > front-page which fails at the moment) Sadly, the web frontend does that when the backend is generating stats. We really need to set a sunset date and retire smolt. I was hoping the new census project would be up and running before then, but we can't keep smolt really limping along forever. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Infrastructure announces status.fedoraproject.org
On Aug 30, 2012 7:30 PM, "Kevin Fenzi" wrote: > We really need to set a sunset date and retire smolt. I was hoping the > new census project would be up and running before then, but we can't > keep smolt really limping along forever. Tomorrow. Ok that might be unreasonable. Make it Monday. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
