Re: Intent to package GNOME Shell frippery
Hi, On 07/29/2011 09:47 AM, David Woodhouse wrote: On Wed, 2011-06-01 at 10:48 +0200, Hans de Goede wrote: Just a quick heads-up that I plan to look unto packaging the gnome shell frippery extensions this weekend, if you've the same plans or are already working on this, please let me know. So we can avoid doing double work. Did you do this? It's the only thing that makes GNOME shell usable for me. I've been holding off on updating too many machines to F15 until it's properly available; I prefer not to install the package from elsewhere. I don't even see a review request in bugzilla yet... I'm afraid I never got around to it, I still intend to do it, but likely not before LinuxCon Vancouver, so if anyone wants to beat me to the punch that would make me very happy :) I'll gladly review it once packaged. As discussed before I think it would be best to package this with subpackages with each containing one of the frippery extenstions, and then have the main package be an empty package which just requires all the others, so that people who want to can easily install the entire bundle. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning / looking for new owner for monkey-bubble
Hi, On 08/01/2011 03:01 PM, Vinzenz Vietzke wrote: Am 26.07.2011 13:57, schrieb Bruno Wolff III: Even though I normally like to save games, I think letting this one go is probably a good idea. Upstream is really gone. +1 IMHO it doesn't make sense to put efforts in fixing and maintaining a package that has no backing from upstream. Ok, since no one has stepped forward I've retired monkey-bubble. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PokerTH orphaned
Hi, On 08/01/2011 09:44 PM, Ryan Rix wrote: On Mon 1 August 2011 19:43:37 Tomas Mraz wrote: On Mon, 2011-08-01 at 10:29 -0700, Ryan Rix wrote: On Mon 1 August 2011 11:46:00 Jussi Lehtola wrote: Hi, I've just orphaned PokerTH, since I'm trying to free myself some time and I don't use it myself. PokerTH does not currently build on rawhide, since OpenSSL support has been dropped from GnuTLS a week ago (BZ #726697). Getting it to build again would then require building against OpenSSL (and asking upstream for a GPL license exception), or shipping a private copy of GnuTLS. I picked up rawhide through F-14. If I cant get this building, I'll orphan it again in a week's time. Shipping a private copy of GnuTLS would have to get an exception I do not think such exception should/would be granted. I can only recommend you to look at the NSS OpenSSL compatibility support library and patching PokerTH to use it instead of the GnuTLS. I've talked to a few people about this now, including some folks at PokerTH about it, and they're confused as to why this change is happening in GnuTLS at all, and your comment in the bug report did not seem to explain it to them; could you (or anyone) explain better why OpenSSL support in gnutls is a Bad Thing? Ryan, have you read the initial description of: https://bugzilla.redhat.com/show_bug.cgi?id=460310 ? The problem is that gnutls's openssl compatibility uses the same symbol names as openssl itself thus polluting the dynamic linker symbol namespace. So if an application uses a library which is linked against openssl (for example ldap libs through pam) and uses gnutls-openssl then the ldap libraries will end up calling functions inside gnutls-openssl rather then inside openssl, since the gnutls-openssl symbols are already present in the dynamic linkers symbol namespace. This then goes boom big time, since the 2 are not ABI compatible. Since gnutls-openssl is not ABI compatible it should not be using the same function / variable names. Tomas has chosen to fix this problem by simply disabling the openssl compat part of gnutls (which as the above bug shows is broken by design) given that only 3 apps use this, this seems like a sane choice to me. The best way forward is probably to ask PokerTH upstream to add the standard openssl license exception boilerplate to their license, I did so successfully with gkrellm and switched to simply using the real openssl. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
Hi, On 08/24/2011 04:56 PM, Simo Sorce wrote: On Wed, 2011-08-24 at 15:10 +0100, Matthew Garrett wrote: On Wed, Aug 24, 2011 at 09:06:22AM -0400, Simo Sorce wrote: On Tue, 2011-08-23 at 14:37 -0700, Adam Williamson wrote: Why not? If the service is enabled but the daemon not currently running, is it so terrible for a connection test to cause the daemon to start? Remember, in systemd logic 'service enabled with socket activation, daemon not currently running' is effectively an 'on' state, not an 'off' state. If you wanted the database to be 'off' you should have the service disabled, and in that case, the ping test wouldn't cause the daemon to start. It generally is a bad idea to automatically restart a database based on a random connection. There many reasons why you may have stopped the db (or it may have stopped itself) and requires inspection before attempting a new restart. Having to battle with socket activation while in a critical situation is not a good idea. You'd have the same problem with any init system that supports automatic service restarting. You can easily disable the service via systemctl. You can do that if you are doing a planned outage. But not for unplanned ones. I am not saying automatic restarts should never be employed, only that not all software should be automatically restarted. I think databases shouldn't in most cases. But that's just my opinion on the specific case. That doesn't mean socket-activation shouldn't be employed in other cases. So maybe we need a socket-activate-once attribute for .service files, which makes systemd do the socket activation only once, hmm thinking of it, doesn't it do that already in the form of handing the listening fd over? So if a service is set to not auto restart the service I would expect the order would be: 1) systemd starts 2) systemd creates listening socket 3) connection comes in 4) systemd starts foodb, hands overlistening socket 5) foodb crashes 6) db is dead, no one listening to socket. Right? I guess that unless auto-restart is set for the service, systemd won't re-create the listening socket and start listening itself again on step 6. If it does I'm sure that the systemd authors are very reasonable people and we can tell them that socket activation should not imply auto-restart on daemon crash / exit (unless explicitly requested). Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
Hi, On 08/30/2011 10:22 PM, Chris Adams wrote: Once upon a time, Simo Sorces...@redhat.com said: They do not 'hang', they just take longer to boot, sometimes a lot longer. How much longer? Much much longer, when I was still on the anaconda team we had numerous bug reports about this (esp during RHEL-6 testing), in many cases people filed bugs with a description along the lines of: Installation DVD does not boot, because it took so long they thought the install was just hanging forever. How many such machines? I've no hard numbers but enough to generate numerous bug reports during the non public testing phase of RHEL-6 alone. Also see: https://bugzilla.redhat.com/show_bug.cgi?id=565693 https://bugzilla.redhat.com/show_bug.cgi?id=587909 https://bugzilla.redhat.com/show_bug.cgi?id=682426 http://lists.fedoraproject.org/pipermail/kernel/2010-April/002394.html http://lists.fedoraproject.org/pipermail/kernel/2010-April/002420.html http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/index.html And search for IBM ThinkPad T43 notebook Note this is in no way an exhaustive list of all bugs about this, just something a really really quick search turned up. Again, I've booted systems without floppy drives but with floppy support loaded, and I haven't seen any significant hang. Yes the hang is not guaranteed to be there, or to take very long, but often it is there, and sometimes it takes very long (which is the real problematic case). If you're really interested in seeing this fixed go talk to the kernel guys: anaconda loads the floppy driver by default when booting of the install DVD, because of driverdisk support, thus the anaconda team has been getting its share of bug reports wrt this. But AFAIK there are no such issues in RHEL-5, where we auto-load the floppy driver too, so something has changed in the kernel causing the hang when no drive is attached to the controller. I could swear I filed a bug against the kernel about this regression, but I cannot find it. Leaving known-working hardware unusable at install is just rude and irritating when it is needed. There should be good justification, not just a bunch of developers don't use it anymore, so we don't think anybody else needs it. Is it delays bootup by up to 10-30 minutes on various modern systems a good enough justification? Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
Hi,
On 08/31/2011 05:41 AM, Bruno Wolff III wrote:
Below is a proposed specfile for the floppy case. (Analog joystick would be
very similar.) I haven't tested the package for functionality yet, but did
test it with rpmbuild and rpmlint. Is this what we want?
I don't know about others, but I love it. Actually a constructive solution
to the problem being discussed, we could even put it in comps (as not enabled
by default) :)
Is this ready
for a formal review?
Putting it up for formal review gets my vote, but first lets see what other
think
for a bit.
As always many thanks for you excellent and constructive work on Fedora.
Regards,
Hans
Name: floppy-support
Version:1.0
Release:1%{?dist}
Summary:Load floppy driver at boot time
Group: System Environment/Kernel
License:MIT
# The package is built just using this specfile.
#URL:
#Source0:
Requires(post): module-init-tools
BuildArch: noarch
%description
By default the floppy driver is not loaded at boot time. Installing this
package will load the floppy driver as part of the install and will set
things so that it will be loaded during future boots.
%prep
#No setup, since no source outside the specfile.
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT%{_libdir}/modules-load.d
echo floppy $RPM_BUILD_ROOT%{_libdir}/modules-load.d/floppy.conf
%files
%{_libdir}/modules-load.d/floppy.conf
%post
/sbin/modprobe floppy
%changelog
* Tue Aug 30 2011 Bruno Wolff IIIbr...@wolff.to 1.0-1
- Initial package creation
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
bluez and hci's which initially come up as hid (was Re: Some days it just doesn't pay to update)
please keep the CC list intact, not all are subscribed to fedora-test resend with the fedora-devel list added to the to list, something which I intended to do from the start sorry for the double mail Hi Jonathan, Adam, et all, Wed Aug 31 Jonathan Corbet wrote: So, I thought...LWN writing is almost done for the day, why not do an update and see what happens? What happened: - My Logitech bluetooth keyboard, which has Just Worked for years, doesn't work anymore. Grub still sees it fine, but the running system does not. Sometimes unplugging and replugging the USB receiver makes it come back. Usually not. That would be caused by a bluez update I pushed, this is actually something I knew which would happen (and once you know what is going on the fix is simple), but I didn't think it would be a big deal since AFAIK we've had this issue for years already, so I'm really really surprised about the has Just Worked for years bit. I started looking into this when I upgraded my Dell laptop to F-16 alpha and my bluetooth mouse stopped working. It turns out that there are some bluetooth adapters (technically speaking hci-s), which for compatibility reasons do not initially identify themselves in their usb descriptors as a bluetooth hci, but instead as 2 hid devices (a keyboard and a mouse). I know of 2 vendors shipping with these Dell has them in almost all their bluetooth enabled laptops, and logitech uses them for the bluetooth dongle shipped with their bluetooth wireless desktop (keyb + mouse) sets. The idea behind these adapters is that they come pre-programmed to automatically pair with the mouse and/or keyboard they ship with, and will pass through events from these through to 2 emulated HID devices, as if the keyb + mouse are regular USB models, so that they will also work in for example the BIOS and the bootloader. Logitech actually ships them like this, no idea why Dell has chosen this adapter model, since AFAIK they never use this feature (as they typically don't ship their laptops with a bluetooth keyboard and/or mouse). So Linux has this tool called hid2hci, to turn the bluetooth HCI into an actual HCI. This has been shipping with udev for a while up to the udev in F-15, the udev in F-16 no longer has this, causing my dell bluetooth to stay in HID emulation mode and thus not work. The reason F-16 udev no longer has it, is because udev + bluez upstream have decided to move it to bluez. And to avoid conflicts when using an older udev with a new bluez, bluez needs to be passed --enable-hid2hci when running ./configure to actually get it. So F-16 alpha was shipping without hid2hci (and the matching udev rules) where as F-15 was shipping with hid2hci. After tracking this down I talked to Bastien (the bluez maintainer) and did a new build of bluez with --enable-hid2hci. Note that to me this was restoring the default F-15 behavior, so I went ahead with this despite knowing that for some people it causes problems, something which I accidentally found out while searching bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=635244 Which is in essence the problem you are seeing here Jonathan, after my bluez update, your bluetooth dongle is actually being out into HCI mode, so that it can for example also be used to sync with your phone, use a bluetooth headset, etc. IOW this is a feature not a bug but this does mean that in order to use your bluetooth mouse / keyboard, you need to explicitly pair them with the bluetooth HCI once, which will require the use of a regular usb keyboard, which is, erm, not so good, one could even argue this is a bug after all. This also brings us back to my: I'm really really surprised about the has Just Worked for years bit, since we've been shipping hid2hci + udev rules for years (and this issue has been reported by others long before). The questions is how do we want to handle this? At least we should release note this I guess, but perhaps we can do something smarter? Under Windows Logitech has its own bluetooth stack, which I guess not only does the hid2hci thing, but also auto-pairs with the keyboard + mouse, hopefully by reading some data from the bluetooth dongle, or maybe it just autopairs with any logitech keyb + mouse? Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bluez and hci's which initially come up as hid (was Re: Some days it just doesn't pay to update)
Hi, On 09/02/2011 05:37 PM, Bastien Nocera wrote: If we wanted to do things properly, we'd use the specs so that the transition between HID and HCI was invisible to the user. Except that we don't have the specs (or it would be fixed already, it's one of my major gripes for a number of years, and I've nagged Dell, Logitech and Broadcom a number of times for access to those). Hans, we need to make the switching opt-in. If you don't have time to work on it, I'd rather you reverted your last patch for now. Hmm, may I point out that making the switching opt-in would be deviating from our default behavior from F-12 onwards, as documented here: http://fedoraproject.org/wiki/Documentation/Bluetooth#Frequently_Asked_Questions With that said, you're the Fedora bluetooth maintainer, so you are the boss. The easiest way to make this opt-in, and I think also a good one, is to just move the udev-rules and the hid2hci binary to their own bluez-hid2hci sub-package. People who want to have their hid proxying adapters to actually show up as HCI instead of HID can then do yum install bluez-hid2hci We could even have a %post script doing a udevadm trigger subsys=to-be-figured-out To avoid people needing to reboot / unplug the adapter after installing the package. If you think this is a good plan, let me know and I'll implement it. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bluez and hci's which initially come up as hid (was Re: Some days it just doesn't pay to update)
Hi, On 09/03/2011 12:22 PM, Bastien Nocera wrote: On Sat, 2011-09-03 at 10:10 +0200, Hans de Goede wrote: With that said, you're the Fedora bluetooth maintainer, so you are the boss. The easiest way to make this opt-in, and I think also a good one, is to just move the udev-rules and the hid2hci binary to their own bluez-hid2hci sub-package. People who want to have their hid proxying adapters to actually show up as HCI instead of HID can then do yum install bluez-hid2hci We could even have a %post script doing a udevadm trigger subsys=to-be-figured-out To avoid people needing to reboot / unplug the adapter after installing the package. If you think this is a good plan, let me know and I'll implement it. Sounds like a good plan to me. Thanks for looking into it. Ok, the plan has been executed now and the result works for me :) Jonathan, can you give bluez-4.96-3.fc17 a spin? It should fix your mouse + keyboard issue. For those interested in this, the F-16 update is here: https://admin.fedoraproject.org/updates/bluez-4.96-3.fc16 Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Warning todays F-16 updates-testing breaks gnome3, both glibc and glib2 are bad!
Hi, This took me some time to figure out, so I hope this mail will save others some grieve. After installing the glib2 update from todays updates-testing: glib2-2.29.90-1.fc16.x86_64 The following happens: [hans@shalem gspca]$ ldd -r /usr/libexec/e-addressbook-factory linux-vdso.so.1 (0x7d3c7000) snip libfreebl3.so = /lib64/libfreebl3.so (0x003c4100) /usr/bin/ldd: line 118: 5142 Segmentation fault (core dumped) LD_TRACE_LOADED_OBJECTS=1 LD_WARN=yes LD_BIND_NOW=yes LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= $@ Nasty! Downgrading glibc yields: [hans@shalem watchdog]$ ldd -r /usr/libexec/e-addressbook-factory linux-vdso.so.1 = (0x7fff2f9ff000) snip libfreebl3.so = /lib64/libfreebl3.so (0x003c4100) undefined symbol: g_unix_signal_add_watch_full (/usr/libexec/e-addressbook-factory) Downgrading also glib2 returns the system to working order, maybe only downgrading glib2 is enough, but the seg fault in ldd -r does not look good, so I've downgraded glibc too. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Warning todays F-16 updates-testing breaks gnome3, both glibc and glib2 are bad!
Hi, On 09/09/2011 06:31 PM, Hans de Goede wrote: Hi, This took me some time to figure out, so I hope this mail will save others some grieve. After installing the glib2 update from todays updates-testing: glib2-2.29.90-1.fc16.x86_64 The following happens: [hans@shalem gspca]$ ldd -r /usr/libexec/e-addressbook-factory linux-vdso.so.1 (0x7d3c7000) snip libfreebl3.so = /lib64/libfreebl3.so (0x003c4100) /usr/bin/ldd: line 118: 5142 Segmentation fault (core dumped) LD_TRACE_LOADED_OBJECTS=1 LD_WARN=yes LD_BIND_NOW=yes LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= $@ Nasty! Downgrading glibc yields: [hans@shalem watchdog]$ ldd -r /usr/libexec/e-addressbook-factory linux-vdso.so.1 = (0x7fff2f9ff000) snip libfreebl3.so = /lib64/libfreebl3.so (0x003c4100) undefined symbol: g_unix_signal_add_watch_full (/usr/libexec/e-addressbook-factory) Downgrading also glib2 returns the system to working order, maybe only downgrading glib2 is enough, but the seg fault in ldd -r does not look good, so I've downgraded glibc too. Replying to myself: As an alternative to downgrading glib2, one can also get a new evolution-data-server from koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=262721 Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaned packages
Hi, On 09/17/2011 12:26 AM, Stepan Kasal wrote: Hello, snip Here is the list of orphaned packages: Xaw3d -- A version of the MIT Athena widget set for X fig2ps -- Utility for converting xfig pictures to PS/PDF I've taken these 2. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Critpath updates process broken for certain components
Hi All, Please note that I'm not claiming that the critpath process is broken in general. But it does not work for certain components. To be specific it does not work for Xorg drivers for non common hardware. This morning bodhi send me 3 mails with the following subjects: [Fedora Update] [CRITPATH] [old_testing_critpath] xorg-x11-drv-qxl-0.0.21-3.fc14 [Fedora Update] [CRITPATH] [old_testing_critpath] xorg-x11-drv-qxl-0.0.21-5.fc15 [Fedora Update] [CRITPATH] [old_testing_critpath] xorg-x11-drv-qxl-0.0.21-5.fc16 Of which the first update has been in updates-testing since 2011-04-23 !!! I know that Adam Williamson uses spice enabled vm's and thus the qxl driver for various QA tasks. I've asked him repeatedly to look at these, but all to no avail. Note I'm not blaming Adam for this, we all need to prioritize our time, so I completely understand that he has not gotten around to looking at these. I'm merely trying to documents my efforts to make the critpath procedure work for the qxl driver. So there you have it, I hope that an update being stuck in updates-testing for 4+ months clearly show that some parts of the critpath process need to be re-thought. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in
Hi All, The subject more or less says it all. When I startup my desktop machine (which thus is always on AC), and leave it at the gdm screen it will suspend after being left alone for 30 minutes. This is not good, since I only leave it powered on when I intend to access it remotely. I would like to suggest to change the default power policy to never suspend while on AC power. Another reason for this is that suspend simply does not work on this (very recent) desktop machine. And I can honestly say I've never seen a desktop machine where suspend worked with Linux, so suspending desktop machines by default seems like a bad idea. Note I've also filed a bug for this: https://bugzilla.redhat.com/show_bug.cgi?id=742685 But since this more of a policy thing then really a bug I thought it would be good to discuss this on the list. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in
Hi, On 10/01/2011 05:07 PM, Martin Langhoff wrote: On Sat, Oct 1, 2011 at 7:02 AM, Hans de Goedehdego...@redhat.com wrote: The subject more or less says it all. When I startup my desktop machine (which thus is always on AC), and leave it at the gdm screen it will suspend after being left alone for 30 minutes. This is not good, since I only leave it powered on when I intend to access it remotely. If it supports LAN-triggered wakeups, I don't see why it should be fully on :-) Not sure if Fedora 16 has the infra, but in my OLPC-tinted-glasses view, power mgmt / NM should allow you to say wake-on-LAN on this interface, then set the WOL bits when it's going down. (Note! The WOL bits need to be frobbed every time the system goes to sleep. They get cleared on wakeup.) It would then also need to identify the NIC as a stay awake source, and only suspend after 30 minutes of no network activity. Imagine I'm running a screen session with my irc client in there on my Fedora box, and 30 minutes after the last resume it suspends while I'm midway typing a sentence, then it wakes up again because of the network activity. Power management win 0, likely even a loss (disks spinning up which may have stayed spun down otherwise, etc. User experience suck, since I all of a sudden get a multiple seconds latency while typing. I would like to suggest to change the default power policy to never suspend while on AC power Thanks for helping keep the Earth warm! :-/ Well there are 2 use cases to consider here: 1) The machine has a desktop function - just turn it off when it is not used My desktop rarely gets an uptime 4 hours since I even turn it off when I go to lunch, and it has a master/slave powerstrip to also power down the printer, display, speaker, etc. One could even argue that suspending here will lure people in to the false sense that it is ok to leave it on since it will go into low power mode anyways, while in reality it is still using a significant amount of power. I'm pretty sure that if we were to bet and measure the poweruse of my desktop once for a week using my power regime, and once more using an always on, but suspend after 30 minutes of idle power regime, that my power regime is significantly more efficient. 2) The machine has a server function. In this case working wake on lan and stay active on lan are a must have and until we have those it should not auto suspend. Once we do then it becomes a question of the latency increase caused by this is acceptable by the use case. suspending desktop machines by default seems like a bad idea. That's such a 90's thinking :-) At this stage, and looking forward, suspending on idle is a good idea on /servers/, where you save power at the server and at the AC. There is work to do across the stack to make S/R work smoothly and transparently. OLPC is doing much of it -- help us getting it into mainstream code (and thinking!). I for one would argue that system suspend itself is 90's thinking, and that we should get better at dynamic powermanagement with things like powergating and dynamic clockspeed support becoming pretty common in all hardware one could argue that system suspend is the powersaving answer of the 90's and that of the 2010's is becoming better at dynamic pm. I think that a system with its disks spun down, cpu clocked down and in its lowest powerstate, unused usb controllers in suspend, display engine in its lowest powerstate and display pipes + connectors turned off, etc. will come pretty close to a fully suspended system. The last big power eater is RAM and that will be active in both scenarios. Or join the greenpeace in teaching polar bears about the wonders of tropical climates... sigh I was already afraid people would come up with this totally uncalled for global warming arguments /sigh You're barking up the wrong tree here, as described above I'm pretty aggressive about powermanagement for my desktop machine, and I don't even have a server at home. But sometimes I work a couple of hours from the laptop in the living room and I need access to my desktop, so then the desktop is on (with the display turned off, really off) untill now this worked fine, with F-16 it no longer works fine. We've a name for that it is called a regression and it needs to be fixed. At a minimum there should be an easy way to configure the powermanagement policy under gdm which there currently is not. Things like Network-Manager and the Region and Language setting already allow configuring gdm / system wide settings from there gnome-3 user session control panel, if we want to do powermanagement from gdm we need the same for gdm. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Critpath updates process broken for certain components
Hi, On 10/01/2011 11:13 AM, Peter Robinson wrote: On Sat, Oct 1, 2011 at 9:29 AM, Hans de Goedehdego...@redhat.com wrote: Hi All, Please note that I'm not claiming that the critpath process is broken in general. But it does not work for certain components. To be specific it does not work for Xorg drivers for non common hardware. This morning bodhi send me 3 mails with the following subjects: [Fedora Update] [CRITPATH] [old_testing_critpath] xorg-x11-drv-qxl-0.0.21-3.fc14 [Fedora Update] [CRITPATH] [old_testing_critpath] xorg-x11-drv-qxl-0.0.21-5.fc15 [Fedora Update] [CRITPATH] [old_testing_critpath] xorg-x11-drv-qxl-0.0.21-5.fc16 Of which the first update has been in updates-testing since 2011-04-23 !!! I know that Adam Williamson uses spice enabled vm's and thus the qxl driver for various QA tasks. I've asked him repeatedly to look at these, but all to no avail. Note I'm not blaming Adam for this, we all need to prioritize our time, so I completely understand that he has not gotten around to looking at these. I'm merely trying to documents my efforts to make the critpath procedure work for the qxl driver. So there you have it, I hope that an update being stuck in updates-testing for 4+ months clearly show that some parts of the critpath process need to be re-thought. There is a ticket open with fesco to improve the critpath process. You can see the proposed changes on the link below. https://fedorahosted.org/fesco/ticket/667 Thanks for the link I've added my 2 cents to the ticket. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in
Hi, On 10/02/2011 10:13 PM, Jason D. Clinton wrote: On Sun, Oct 2, 2011 at 02:02, Hans de Goedehdego...@redhat.com wrote: Imagine I'm running a screen session with my irc client in there on my Fedora box, There has perhaps never been a better sentence written demonstrating why software engineers are not the target audience of any software development. :-) Hehe, actually I don't do that, I always use xchat this just was an example of something I know some people do :) and 30 minutes after the last resume it suspends while I'm midway typing a sentence, then it wakes up again because of the network activity. Power management win 0, likely even a loss (disks spinning up which may have stayed spun down otherwise, etc. User experience suck, since I all of a sudden get a multiple seconds latency while typing. Your desktop is now a server and the power policy should reflect that it's offering up network services. Agreed, so we need a way to set that powerpolicy, esp. since Fedora still had a server installation profile last time I checked. Well there are 2 use cases to consider here: 1) The machine has a desktop function - just turn it off when it is not used My desktop rarely gets an uptime 4 hours since I even turn it off when I go to lunch, and it has a master/slave powerstrip to also power down the printer, display, speaker, etc. One could even argue that suspending here will lure people in to the false sense that it is ok to leave it on since it will go into low power mode anyways, while in reality it is still using a significant amount of power. I'm pretty sure that if we were to bet and measure the poweruse of my desktop once for a week using my power regime, and once more using an always on, but suspend after 30 minutes of idle power regime, that my power regime is significantly more efficient. People are not like machines, we don't always know that we're not coming back to our computers and we forget to turn them off. We're also lazy. Agreed this was just to show there are otherways to save power and to debunk the whole not autosuspending makes the polarcaps melt argument. Anyways auto-suspending for the desktop case is fine. 2) The machine has a server function. In this case working wake on lan and stay active on lan are a must have and until we have those it should not auto suspend. WOL for a network server is madness. If you say so :) I had the same feeling but I'm not that deep into recent pm advances. Note that this also makes autosuspend for servers madness - we need an user/admin friendly way to configure this. It shouldn't have been suggested. If you really want to save power, move your IRC client to a shared shell server somewhere so that the power consumption of an always-on server is aggregated across all those who use it. That really gets to the heart of the argument for cloud computing: economies of scale. I for one would argue that system suspend itself is 90's thinking, and that we should get better at dynamic powermanagement with things like powergating and dynamic clockspeed support becoming pretty common in all hardware one could argue that system suspend is the powersaving answer of the 90's and that of the 2010's is becoming better at dynamic pm. I think that a system with its disks spun down, cpu clocked down and in its lowest powerstate, unused usb controllers in suspend, display engine in its lowest powerstate and display pipes + connectors turned off, etc. will come pretty close to a fully suspended system. A fully power-saved Sandy Bridge laptop in the state you lay out above is around 7W. A suspended laptop from the same generation consumes roughly 0.4W of power. Stand-by is 0.1W. Desktop systems from the same generation tend to be on the order of 1-2W while suspended and consume 30-35W while power-saved. Stand-by is 1-2W. Servers from the same generation tend to be on the order of 6-8W while suspended and consume around 90-120W while power-saved (assuming a dual socket mobo with no disk idle behavior and dual GigE NIC's). Right, I do hope that you see here that no disk idle behavior is not really a fair comparison. If you get the 30 minutes of inactivity which is needed for auto-suspend, surely you can also makes the disk spin down. Also as you set before wol is not the answer for servers, so we really need to get better at this dynamic pm stuff. There's some variability here based on the number of DIMM's. Stand-by is 1-4W. As you can see, suspending is the right thing to do. 1) Not for servers 2) This is todays hardware and with every generation the gap is getting smaller between dyn pm savings and suspend savings. But sometimes I work a couple of hours from the laptop in the living room and I need access to my desktop, so then the desktop is on (with the display turned off, really off) untill now this worked fine, with F-16 it no
Re: [ACTION REQUIRED, v2] orphaned packages in F-14
Hi, On 08/20/2010 10:25 PM, Bill Nottingham wrote: The attached list shows currently orphaned packages in F-14. If they are not claimed by the end of next week, they will be blocked, potentially breaking dependencies (and causing more things to be blocked...) If you already co-maintain the package, please step up and take it. (If you don't, it may be assigned to you anyway.) Otherwise, volunteers would be appreciated for those packages that other things require. Bill I've taken dom4j and requested c-maintainership for libsigc++, as these both are deps for packages I own. Regards, Hans Orphan JSDoc Orphan bzr-gtk comaintained by: shahms Orphan cdf Orphan classworlds comaintained by: dbhole Orphan crun Orphan django-authopenid Orphan dom4j comaintained by: dbhole Orphan drgeo Orphan drgeo-doc Orphan drpython Orphan dtdparser comaintained by: dbhole Orphan fet comaintained by: fab Orphan fish comaintained by: oliver Orphan gg2 Orphan gnome-vfsmm26 Orphan gnomecatalog Orphan gperiodic Orphan hsqldb comaintained by: fnasser Orphan impressive Orphan isorelax Orphan jlex Orphan jrefactory Orphan jzlib Orphan kasablanca comaintained by: tuxbrewr rdieter Orphan kflickr Orphan ldapjdk Orphan libgnomecanvasmm26 Orphan libgnomemm26 Orphan libgnomeuimm26 Orphan libmspack Orphan libpanelappletmm Orphan libsigc++ Orphan lucene Orphan mapbender Orphan mapserver comaintained by: devrim oliver Orphan mediawiki-HNP Orphan mediawiki-StubManager Orphan minirpc Orphan nettle Orphan nodm Orphan objectweb-anttask Orphan ogdi Orphan pAgenda Orphan papercut Orphan pastebin Orphan php-channel-phpdb Orphan php-pear-Phlickr Orphan php-pear-creole Orphan php-pear-pake Orphan php-pear-propel_generator Orphan php-pear-propel_runtime Orphan pitivi Orphan plexus-ant-factory Orphan plexus-appserver Orphan plexus-bsh-factory Orphan plexus-compiler Orphan plexus-runtime-builder Orphan plexus-xmlrpc comaintained by: fnasser Orphan poker-engine Orphan poker-eval Orphan poker-network Orphan poker2d Orphan poker3d Orphan poker3d-data Orphan pycairo Orphan pyfacebook Orphan pyorbit Orphan pypoker-eval Orphan python-numarray Orphan python-urllib2_kerberos Orphan python-zc-lockfile comaintained by: cheeselee Orphan python-zdaemon comaintained by: cheeselee Orphan python-zope-event comaintained by: cheeselee Orphan python-zope-testing comaintained by: cheeselee Orphan qosmic Orphan relaxngDatatype comaintained by: dbhole Orphan ruby-activerecord Orphan spambayes Orphan stardict-dic-en comaintained by: kaio Orphan stardict-dic-ja comaintained by: kaio Orphan stardict-dic-ru comaintained by: kaio Orphan stardict-dic-zh_CN comaintained by: kaio Orphan stardict-dic-zh_TW comaintained by: kaio Orphan taipeifonts comaintained by: kaio Orphan tanukiwrapper comaintained by: devrim Orphan tinyows Orphan tomcat6 comaintained by: dwalluck akurtakov dknox Orphan tpb Orphan tremfusion Orphan twitux Orphan vgabios Orphan windowlab Orphan ws-jaxme comaintained by: dbhole Orphan x2vnc Orphan xenwatch Orphan xjavadoc Orphan xmldb-api comaintained by: dbhole Orphan xmlrpc comaintained by: devrim Orphan xom comaintained by: dbhole Orphan xpp2 comaintained by: dbhole Orphan xpp3 comaintained by: dbhole Orphan xwnc List of deps left behind by orphan removal: Orphan: classworlds intellij-idea requires classworlds = 1.1-4.fc12 maven-doxia requires classworlds = 1.1-4.fc12 maven-doxia-sitetools requires classworlds = 1.1-4.fc12 maven-surefire requires classworlds = 1.1-4.fc12 maven-wagon requires classworlds = 1.1-4.fc12 maven2 requires classworlds = 1.1-4.fc12 mercury requires classworlds = 1.1-4.fc12 modello requires classworlds = 1.1-4.fc12 plexus-ant-factory requires classworlds = 1.1-4.fc12 plexus-appserver requires classworlds = 1.1-4.fc12 plexus-archiver requires classworlds = 1.1-4.fc12 plexus-bsh-factory requires classworlds = 1.1-4.fc12 plexus-compiler requires classworlds = 1.1-4.fc12 plexus-container-default requires classworlds = 1.1-4.fc12 plexus-i18n requires classworlds = 1.1-4.fc12 plexus-resources requires classworlds = 1.1-4.fc12 plexus-velocity requires classworlds = 1.1-4.fc12 plexus-xmlrpc requires classworlds = 1.1-4.fc12 Orphan: dom4j bolzplatz2006 requires dom4j = 1.6.1-5.fc12 eclipse-checkstyle requires dom4j = 1.6.1-5.fc12 freemarker requires dom4j = 1.6.1-5.fc12 itext requires dom4j = 1.6.1-5.fc12 itext-rups requires dom4j = 1.6.1-5.fc12 jaxen requires dom4j = 1.6.1-5.fc12 json-lib requires dom4j = 1.6.1-5.fc12 logback requires dom4j = 1.6.1-5.fc12
Re: Linux and application installing
Hi, On 09/08/2010 02:43 PM, Richard Hughes wrote: On 8 September 2010 13:16, Adam Williamsonawill...@redhat.com wrote: First off, I think this is a great idea and very much needed, thanks for working on it. Cool, thanks. Some positive feedback at last! Too... much... stop... energy... Oh, But Adam is not the only one I love this idea too! And I would like to think there are other silent admirers of this idea too! I've even considered taken the review for the app data package and approving it, but then decided that would only raise the controversy surrounding the app data part. FWIW I agree with you that for this to be truely user friendly the app data needs to be present on the system when the user first starts the app installer. Not sure if dropping it in a package is the best thing to do though. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broadcom wifi drivers in F-14?
Hi, On 09/14/2010 01:31 PM, David Woodhouse wrote: On Tue, 2010-09-14 at 00:40 -0700, Jesse Keating wrote: IIRC they require a firmware blob that has a license that we cannot distribute unlike say the Intel firmwares. I could be wrong though. That's still true of the b43 firmware for older (pre-802.11n) devices, but the firmware to go with their new driver is now in linux-firmware.git. Hmm, now that they are trying to be opensource friendly, can't we get them to license the old firmware under the same license as the new one? It would be great to be able to ship the old firmware and haver older broadcom cards work out of the box. David do you have a contact inside Broadcom to talk to about this, and could you ask? Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pushing updates for FTBFS
Hi, On 09/22/2010 07:37 PM, Toshio Kuratomi wrote: On Tue, Sep 21, 2010 at 03:25:25PM -0600, Kevin Fenzi wrote: On Tue, 21 Sep 2010 10:06:09 -0700 Eric Smithe...@brouhaha.com wrote: A bug was filed against meshlab because of an FTBFS for Fedora 14. I added a patch to resolve it and submitted an update. After seven days with no feedback, I was able to push it to stable. Were there reports of the existing build causing problems? Personally, I would check such changes in, but only push out an update in f14 if there were other changes that made it worthwhile, or the existing build caused issues. Rawhide of course you should build for for these issues. For an FTBFS for a new Fedora release, does it really make sense to have the seven day delay? I don't see what the downside would be of allowing it to be pushed to stable immediately. Even if there's something wrong with the update, it isn't going to replace a working package. I don't see the point of pushing it as an update at all, unless it's fixing some bad behavior in the existing build or there are other reasons (upstream update, etc). For (unreleased) F14, I think that the arugment that future work on the package is better off starting with something that works than to start off with something that's broken by new gcc, boost, etc is very valid. If I get a time-sensitive security bug about foo in Fedora 14, I want to have as few extraneous issues as possible so I can hunt down and fix the bug quickly. Right, and on top of that, fixing ftbfs woth an update (for unreleased versions only) also makes live a lot easier for secondary archs if it does not build on i386 chances are almost 100% it won't build no ppc / arm / alpha / sparc / s390 / whatever either. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning some packages
Hi All, Unfortunately I don't have the time to proper maintain the packages below. So I believe it is better to orphan them, and have just done so. If you're interested in any of these feel free to pick them up bochs - Portable x86 PC emulator I believe everyone is pretty much using qemu now. If not I hope someone else will pick this up crystalspace - 3d engine I packaged this for 2 reasons: 1. so that people who wanted to develop code with it could do so easily on Fedora 2. to maybe package some games which use this 2. never happened due to lack of good candidates. Currently upstream has version 1.4, and we are shipping 1.2.x, so for 1. this package also is useless unless upgraded (bug 585439). cel - Crystal Entity Layer (CEL) A scripting language for crystalspace TnL - A futuristic action flight simulator game Dead upstream, never really finished / completed by upstream TnL-data - data files for TnL Io-language - programming language I packaged this as a dep for TnL. Could also be useful to some people by itself, needs an update to latest upstream (bug 597451). Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Bringing a retired package (tritonus) back from the dead?
Hi, I would like to bring tritonus back from the dead (as it is a dependency for vorbisspi, which is needed to be able to playback .ogg files under java). I'm pretty sure this has been discussed before, but there does not seem to be anything written about it on the wiki (or I cannot find it). So iirc the procedure is to just file a review request as of it is a new package, skip the cvs^w git module creation step and ask rel-eng to unblock once the review + new builds are done, right ? Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages in need of new maintainers
Hi, On 10/03/2012 08:23 PM, Jon Ciesla wrote: As a result of FESCO ticket 952*, Lubomir Rintel's 200+ packages are in need of new maintainers. Under normal circumstances we'd simply orphan them all, but given the large number we want to handle this in a more orderly fashion. Please reply to the list with any requests for ownership changes, and I'll complete them on a first-come, first-served basis. The current list: opengl-games-utils -- Utilities to check proper 3d support before launching 3d games As the author of this mini package, I'll take this one :) co-maintainers welcome plee-the-bear -- 2D platform game And I'll also take this one. pulseaudio -- Improved Linux sound server ??? !!! yofrankie-bge -- 3D Game with characters from Big Buck Bunny movie And I'll also take this one. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: anacanda: should we ignore the bios raid information on a disk when the raid is broken?
Hi, On 10/15/2012 09:23 AM, Joshua C. wrote: I have a broken fake raid on my machine (intel p67 chipset with one of the disks missing) and when trying to install F17 yesterday (with up-to-date respin done with pungi) I was greeted with the following message disk sdXXX has bios raid information and. blah. is part of a broken raid, ignoring sdXXX. After ignoring the message later on I wasn't given the chance to use the spare disk. I thought of patching anaconda to ignore the bios-raid-information and to allow me to use the disk as I single HDD but I was wondering if there are any side effects out of this? Yes, the side effect of this is that if we wrongly detect an array as being broken and allow the user to use it, we will destroy the array, nuking any data on it. IOW ignoring this error is simply not an acceptable option. What you can do is remove the bios raid metadata from the disk by going into a rescue shell on the system and run wipefs on the disk in question Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: anacanda: should we ignore the bios raid information on a disk when the raid is broken?
Hi, On 10/15/2012 10:41 AM, Joshua C. wrote: 2012/10/15 Hans de Goede hdego...@redhat.com: Hi, On 10/15/2012 09:23 AM, Joshua C. wrote: I have a broken fake raid on my machine (intel p67 chipset with one of the disks missing) and when trying to install F17 yesterday (with up-to-date respin done with pungi) I was greeted with the following message disk sdXXX has bios raid information and. blah. is part of a broken raid, ignoring sdXXX. After ignoring the message later on I wasn't given the chance to use the spare disk. I thought of patching anaconda to ignore the bios-raid-information and to allow me to use the disk as I single HDD but I was wondering if there are any side effects out of this? Yes, the side effect of this is that if we wrongly detect an array as being broken and allow the user to use it, we will destroy the array, nuking any data on it. IOW ignoring this error is simply not an acceptable option. What you can do is remove the bios raid metadata from the disk by going into a rescue shell on the system and run wipefs on the disk in question Regards, Hans I don't want to remove the bios data because this is the only way to rebild the raid when the next disk arrives. Currently I'm using the disk under Linux/Windows without any problems (in AHCI mode). Wipping the bios data will remove anything when later I build (re-build) the raid with the intel orom... Can I just install anaything on the second disk and then manually adjust the fstab file to automount the disk from the broken raid? Assuming your raid array is a mirror, and that you won't be partitioning it or something similar, just adding the existing /home partition to your fstab yes that should work. Although anaconda will not let you touch the mirror member during the install, if you've another disk, putting Fedora 17 on that other disk should work fine, and after that pointing fstab the disk will work. BUT *IMPORTANT IMPORTANT IMPORTANT* you MUST remove the entry from fstab, before rebuilding the array, and then after the rebuild re-add the entry put now pointing to the raid and not to the single disk, otherwise Linux will keep using the single disk for your /home !!! Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: gtk v4l2 (webcam) control panel app + applet
Hi, On 01/12/2010 02:30 PM, Fabian Deutsch wrote: Hello, Am Dienstag, den 12.01.2010, 12:39 +0100 schrieb Hans de Goede: For Fedora-14 (to be released November 2010) it would be nice to have a gtk application for controlling various camera settings (brightness, contrast, etc.) *and* a small applet which shows a webcam icon next to the clock when a webcam is present. Very nice idea, also providing it as a capplet seems to make sense. There already is an existing graphical v4l2 control panel application (v4l2ucp), which can be used to model the gtk application after. This application is not suitable as it is using the QT GUI toolkit, which does not integrate well into the default Fedora desktop. Looking at v4l2ucp it does not seem to be that hard. So might this be a potential GSOC project? If I don't get any students from the local University to work on this, yes it could be turned into a GSCO project. Btw.: ekiga (http://www.ekiga.org) is also tinkering around with v4l to adjust brightness and stuff. Once this is in place, webcam using apps really should stop doing this theirselves, esp. as they get it completely wrong. Ekiga iirc just assumes there will be a contrast, brightness, whiteness and saturation control, without checking what the cam actually has. Once could argue ekiga should be fixed, but the real answer is these apps should stop handling this themselves. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
Hi, On 01/16/2010 12:14 AM, Jesse Keating wrote: On Fri, 2010-01-15 at 22:58 +0100, Till Maas wrote: But what about the other packages by these maintainers that do not fail to build but are probably as unmaintained as the packages that fail to build? Because this isn't a fully proper non-responsive maintainer approach, we felt it was only necessary to orphan the particular packages in question. These maintainers may have been active elsewhere, and wholesale orphaning with very little notice does not seem appropriate. I don't see who the orphaning without following proper procedure is appropriate at all. Simply blocking the ones which FTBFS bugs were not fixed from F-13 inclusion would have been the appropriate response (as documented in our procedures), not some adhoc almost random response. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning Candidate packages for removal due to FTBFS, implications
Hi, On 01/15/2010 08:17 PM, Matt Domsch wrote: On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote: The following 30 packages, with respective FTBFS bugs, have been open since the Fedora 11 time frame, and continue to fail to build. These are the oldest non-building packages in the distribution, everything else (over 8800) managed to build for Fedora 12 or newer already. At today's FESCo meeting, it was agreed that all the below packages would be marked orphan. I know several of these have been fixed by provenpackagers already - you are welcome to un-orphan and maintain them going forward, or the original package owner may choose to do so. awn-extras-applets-0.3.2.1-8.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511628 evolution-brutus-1.2.35-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511451 geronimo-specs-1.0-2.M2.fc10.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511494 gmfsk-0.7-0.6.pre1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511780 gnome-scan-0.6.2-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511591 Io-language-20071010-10.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511617 knm_new-fonts-1.1-5.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=555487 libFoundation-1.1.3-11.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511470 ohm-0.1.1-9.39.20091215git.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539200 perl-AnyEvent-XMPP-0.4-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511749 perl-Class-InsideOut-1.09-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539136 perl-Jemplate-0.23-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=538984 perl-MooseX-Traits-Attribute-CascadeClear-0.03-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511570 perl-RRD-Simple-1.43-3.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=464964 perl-SVN-Mirror-0.75-2.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511770 perl-SVN-Simple-0.27-7.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511729 prctl-1.4-5.2.1.src.rpm (last built July 12, 2006, ExclusiveArch ia64) python-openhpi-1.1-3.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511675 qtiplot-0.9-11.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511688 recordmydesktop-0.3.8.1-1.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=538931 skychart-3.0.1.5-6.20081026svn.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539202 smarteiffel-2.3-2.fc9.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511362 synce-kde-0.9.1-4.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=539195 unifdef-1.171-8.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511553 widelands-0-0.13.Build13.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511430 xpilot-ng-4.7.2-16.fc11.src.rpm https://bugzilla.redhat.com/show_bug.cgi?id=511717 Ah, how nice, these 2 are orphaned now and I cannot take ownership due to a pkgdb bug, just great! Can some pkgdb admin please make me (jwrdegoede) the owner of xpilot-ng and widelands for devel ? Thanks, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Desktop categories
Hi, On 01/16/2010 02:43 AM, Adam Williamson wrote: On Sat, 2010-01-16 at 02:25 +0100, Alain Portal wrote: mode l10n=French Putain ! Mais c'est pas possible ! C'est à se cogner la tête contre les murs !!! Un vrai dialogue de sourds... /mode Please, is there a french speaking fedora developer to contact me and who could help me to tell what I want to tell. It is now clear to me that I'm not understood... Um. We understand you perfectly well. So, you understand french? Particulary this? ;-) Damnit! This is impossible! It's like banging your head against a wall! dialogue de sourds is hard to translate literally ;) We're just explaining that you do not need to add extra non-standard fields to .desktop files to make it possible to have these extra menu levels. It's entirely possible without having non-standard .desktop fields at all. Alors... Why I get no submenu in the Utility menu? Pourtant... cat /usr/share/applications/kde4/kcalc.desktop | grep Categories Categories=Qt;KDE;Utility;X-KDE-Utilities-Desktop; cat /usr/share/applications/kde4/kwrite.desktop | grep Categories Categories=Qt;KDE;Utility;TextEditor; cat /usr/share/applications/kde4/kbackup.desktop | grep Categories Categories=KDE;X-KDE-Utilities-File;Utility; Three applications, no relationship between its, but in the same (and only) menu, no submenu available... Because we don't set up Fedora's menu structure to have submenus, at present. But if we _did_, then you can see that kwrite could go into a 'Text Editors' submenu. kcalc and kbackup could both stand to have a standard subcategory beyond just 'utility' added to their .desktop files, I guess. The point is that the existing fd.o standard categories already have enough granularity to allow a distro to construct submenus _if it chooses to_. Exactly. Note that we had the same issue (too many apps in one menu) with the Games SIG and I created a special games-menus package, which when installed adds some additional configuration files which do sub-menu the games menu in both kde and gnome (a must have if you install lots of games). Alian, take a look at games-menu, and perhaps you can create the same for the utilities menu ? Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
No mouse + keyb in X in latest rawhide + fix (selinux)
Hi, This might be a dup, and I'm a bit under the weather so in no mood to search BZ. Anyways for other people who might hit this if your mouse and keyb in X in rawhide all of a sudden are gone, this is due to haldaemon not starting, which is caused by some selinux issue. Setting selinux to permissive works around this for me. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora Linux Format software review: January 2010
On 12/31/2009 04:31 PM, Tom spot Callaway wrote: On 12/30/2009 02:15 AM, Hans de Goede wrote: It would be nice if others could join in (be it virtual not necessarily physically). So are there any takers for this ? It might be useful to have a wiki page listing out the specific content items which need to be replaced. Ok, Wiki pages have been created for tracking this, see: http://sourceforge.net/apps/mediawiki/blobwars/index.php?title=Main_Page http://sourceforge.net/apps/mediawiki/blobandconquer/index.php?title=Main_Page Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HALL-MONITORED] Update threads are now hall-monitored
Hi, On 03/03/2010 10:30 PM, Doug Ledford wrote: On 03/03/2010 02:27 PM, Tom spot Callaway wrote: Okay. This has gone on long enough. The signal is gone from the following threads: The signal is not entirely gone, although it is getting weaker. * FESCo wants to ban direct stable pushes in Bodhi (urgent call forfeedback) * Worthless updates * Refining the update queues/process Accordingly, I'm marking those threads as Hall-Monitored. Please stop posting in them. If you have a concrete suggestion on how to improve Fedora updates, please write it in a wiki page, open a FESCo trac ticket, and they will consider it. The problem is that having a concrete suggestion of how to improve fedora updates requires knowing whether we want a more stable update cycle or a more semi-rolling update style. It would be easy for us to carte blanch hand down an edict on this, but that would also be wrong. This is a community driven distribution, and by my count the number of people that stood up in favor of semi-rolling updates was not that different from the number of people that stood up for stable updates (I have something like 4 for semi-rolling and 6 for stable, but many people didn't make their preferences perfectly clear, and this count is from my admittedly worthless memory of those that were explicit in their desires). I think the whole stable update cycle versus semi-rolling update style is too black and white. For core packages / major desktop packages clearly a stable update cycle is the right thing to do. But for packages which are more nice packages, the right thing to do may vary. What for example for a package which is not only added recently to Fedora, but came into existence recently in general. There might be some new upstream releases there which are not bugfix only but still very good to have (think pre-alpha - alpha - beta steps). Another example against having a hardcoded stable update cycle is multiplayer games. In quite a few online gaming communities, most of the community moves over to the latest release once it is sanctioned stable by upstream. If the client - server version need to be in sync (which they often do because they need the exact same maps), then this means that our stable version in F-released might become worthless pretty quickly as there are no or very little stable version servers available to play on. Also some upstreams do much much better QA then others, or are in general not as fast moving as others. In these cases it might make sense to do a semi-rolling update style for these packages, even if the upstream releases are not purely bugfix releases. So I think in the end this should preferably be left to the maintainer. And if FESco decides that a stable update cycle is what we want, can they *please* make this a not one size does not fits all policy. I would like to see a split somewhere, say included in standard insert desktop environment here install, versus the rest. With less strict checks at the *tool* level for the rest ? The idea here is that the policy prescribes a stable update cycle, but leaves room for maintainers to make exceptions when they believe they have good reasons to do so, and that the tools (bodhi, autoqa) allow for maintainers for packages outside the core group to override the tool, without needing FESco / rel-eng permission first. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: To semi-rolling or not to semi-rolling, that is the question...
Hi, On 03/04/2010 09:59 PM, Doug Ledford wrote: Obviously, some people want this and some don't. It isn't appropriate to simply hand down an edict that things will be one way or the other if we truly consider Fedora a community run project. It must be a community decision. That means, as Adam Williamson pointed out, this is likely a decision to be made by the board, based upon what the community wants and what's best for Fedora. But let's be clear. That's a *policy* decision. One of the things that got very confusing in the previous thread(s) was the intermixing of policy decisions and technical issues. For instance, Kevin's response to my proposal was all about technical issues he saw. Technical issues are almost always solvable if you have a specific policy you are trying to implement. So one thing I think people should keep in mind is that policy decisions should always lead to technical decisions, *not* the other way around. We should decide what we want ourselves to be and what our policies are, and then that should guide our infrastructure, our tools, our work flows, and our processes. We should never allow things to flow in the reverse direction. We should never allow a current tooling limitation to set our policy, modulo that our policy should acknowledge and accommodate for the time necessary for tooling changes to take place or for the limitations of our resources. So, I'm going to reiterate my policy suggestion: Make Fedora releases (all of them) stable in nature, not semi-rolling. One size does still not fit all, although this is a great idea for most packages in Fedora for packages in certain niches this is a bad idea. I've said this before (and got 0 response), I believe there should be some divide made between core packages (with core being quite big, not the bare essentials, but also most of all desktop environments, etc.) and non core packages. For example I really see no reason not to upgrade some EDA tool to the latest and greatest if the maintainer thinks that there are good reasons to do this, because the group of EDA users bitten by potential regressions is small and EDA users are highly technical skilled, so know how to downgrade if needed. Another example is multiplayer games. In quite a few online gaming communities, most of the community moves over to the latest release once it is sanctioned stable by upstream. If the client - server version need to be in sync (which they often do because they need the exact same maps), then this means that our stable version in F-released might become worthless pretty quickly as there are no or very little stable version servers available to play on. I strongly urge FESco to come up with a policy which is flexible enough to handle these kind of special cases, without requiring going to rel-eng for an exception each and every time. And to mandate that the tools are flexible enough too. Also I cannot get rid of the collective punishment feeling here, because a few people do crazy things, ALL of us loose the right to apply common sense and have to adhere to strict policy and jump to even more hoops to get updates out there. How about a FAS flag which decides if a maintainer can skip updates-testing, which default to yes, and take this away from people who show to little restraint in skipping updates-testing ? Make rawhide consumable as a semi-rolling release itself. We already have this it is called early branching of the next release. I would fully agree with you if it were not for the early branching feature, which means we effectively already have such a release, except the first 2 months or so after a release, at which time rawhide tends to be very volatile in general (*), so a stabilized rawhide would pretty much boil down to the latest release anyways. Given that we pretty much already have this my reaction to this is please not another tree! * (we still need to see if no frozen rawhide changes this) Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora has become fat!
Hi, Maybe somehow fluid-soundfont-gm or fluid-soundfont-lite-patches is getting dragged in ? Those are quite big. Regards, Hans On 03/22/2010 01:50 AM, Christoph Wickert wrote: Why has Fedora become so fat in the F13 development cycle? * The LXDE Spin has grown from 464 MB to 509 MB [1] without a single change in the Spin. There actually was a change, SLIM was replaced with LXDM, but LXDM is actually smaller because it doesn't require the desktop-brackgrounds package * The Xfce spin has grown from 697 MB to 744 MB [2] without major changes. In fact, we dropped totem and gftp, which is at least 10 MB. Any ideas what made Fedora become so fat or how to further investigate this? Regards, Christoph [1] http://alt.fedoraproject.org/pub/alt/nightly-composes/lxde/logs/SIZEHISTORY-i386 [2] http://alt.fedoraproject.org/pub/alt/nightly-composes/xfce/logs/SIZEHISTORY-i386 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Headsup new soname changing parted coming to rawhide
Hi, I'm updating parted to the 2.2 release. This is mostly a bugfix update. But one of the fixes is a change in the soname, the soname now no longer is in the form of parted-2.x.so, but instead has become a regular versioned soname. The positive side of this is that we no longer will need to rebuild all parted users each time parted gets rebased, as the soname will now only change when their actually is an ABI break. The bad news is that we will need to rebuild all parted users one last time. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: urgent testing call: F13 kernel-2.6.33.1-24.fc13
Hi, kernel-2.6.33.1-24.fc13 works for me (amd64 system with nvidia chipset). Regards, Hans On 04/06/2010 11:53 PM, Adam Williamson wrote: Hi, everyone. We're looking at pulling kernel-2.6.33.1-24.fc13 into Fedora 13 Beta, quite late, because current Beta candidate builds include kernel-2.6.33.1-19.fc13 which is known to include a severe bug that breaks boot on systems with Broadcom wired ethernet adapters supported by the b44 module. However, -24 has other changes from -19, including to the nouveau (NVIDIA graphics) and iwlwifi (Intel wifi) drivers. We really need as many people as possible to test kernel -24, which you can get at http://koji.fedoraproject.org/koji/buildinfo?buildID=164598 , and confirm that it works okay on your systems. To install it, use 'rpm -ivh' for the kernel and -devel packages. If you have kernel-headers installed, 'rpm -Uvh' that first. Then reboot to the kernel and check that it boots up okay. Please reply to this thread with your results. Thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Two new applications to package and add to Fedora
Hi, On 04/07/2010 02:34 PM, Damian Brasher wrote: Hi List I'm new to this list, a brief intro - I currently work for the University of Southampton (ECS) as a systems administrator / programmer and also run my small development company, Interlinux Ltd. See LinkedIn http://www.linkedin.com/in/dbrasher 'to the chase: I have coded two projects (beta1 and beta2) that I would like to package and add to Fedora (extras?). I hope this archive this over several weeks and I (my company) will be the long-term maintainer. 1) DIASER (2005-2010) - Long-term geo-redundancy archiving software [for the cloud] written in Perl. https://sourceforge.net/projects/diaser/ 2) DSI (2001-2010) - Pristine (code) Space Invaders clone written in C and recently revived for fun and to support DIASER. You will want to rename that, at least for Fedora, but since you are upstream you may want to give it a different name upstream too, see: https://fedoraproject.org/wiki/Packaging/Guidelines#Trademarks_in_Summary_or_Description Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [linux-sunxi] Re: Announcing Fedora 19 ARM remix for Allwinner SOCs release 1, now with A20 support
Hi, On 08/30/2013 07:24 PM, elias@gmail.com wrote: Op vrijdag 19 juli 2013 00:12:35 UTC+2 schreef Hans de Goede: The following has been ported / is supported: -sound: analog in/out Fedora 19 ARM should also work on the following devices: * A13-OLinuXino (Olimex) Hi, thanks very much for the release! I've already tested the Fedora 18 remix on my A13-OLinuXino (even with WIFI working!), but I can't get the audio to work: ALSA reports that no soundcards could be detected. However using the Debian image of Olimex, I was able to get audio through my headphones and the mic worked also. I looked up the driver, and it appeared to be sun5i-CODEC. On the rootfs of the Fedora image, I looked into /lib/modules/sun5i-kernel/kernel/sound/soc/, but I only could see a sun4i directory, even without a sun4i-CODEC counterpart. I read somewhere else that code of /sound/soc/sun5i was merged with /sound/soc/sun4i, but I tried to modprobe each driver in /sound/soc/sun4i without success. Do I have to recompile the whole kernel, or just compile the sun5i-CODEC module, or do I have to do something different to get audio working? Thank you very much! You're not seeing the sun4i-codec module (which works for sun5i too) because it is build into the kernel. You should see some audio devices under /dev/snd and /sys/class/sound While checking things work with Fedora 19 ARM remix for Allwinner SOCs release 1 I did notice that there is an error in the fex file for the A13-OLinuXino, causing only audio-out to be present, I've just pushed an updated fex file here: https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a13/a13-olinuxino.fex If you save this file, convert it to a script.bin file using the fex2bin utility from here: https://github.com/linux-sunxi/sunxi-tools And then overwrite script.bin in the uboot partition of your sdcard with the new one you should also get a capture device. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [linux-sunxi] Re: Announcing Fedora 19 ARM remix for Allwinner SOCs release 1, now with A20 support
Hi, On 09/12/2013 04:27 PM, hmandevt...@gmail.com wrote: Hi Hans, i tryed to use your fedora 19 remix on my Olinuxino A20 Rev.D but don't start, there is only red and green leds power on static (no blink) but i have always hdmi signal off (i verified that script is for hdmi). Have you tried hooking up the uart to a serial port / usb - serial convertor too see if there are any kernel boot messages? Various people have been successfully using the image with hdmi out on the Olinuxino A20 Rev.D, without any issues. How are you powering the board ? Note that the board has an onboard regulator, so it needs 6V as a minimum input voltage. Also try replacing the sdcard and the hdmi cable. If that all fails, try another Linux distro, ie olimex's official images, if that fails too, it could be your board is broken. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Announcing Fedora 19 ARM remix for Allwinner SOCs release 2
Hi All, I'm very happy to announce the second release (r2) of my Fedora 19 ARM remix images for Allwinner A10, A10s, A13 and A20 based devices. This release is based on the official Fedora 19 Final for ARM images, with u-boot and kernel(s) from the linux-sunxi project: http://linux-sunxi.org/ Here is what is new in r2: New features: -Added support for the buttons on various olinuxino boards -Added support for using 7 or 10 lcd module with various olinuxino boards -Added spi support (except on A20) -Added pwm support -Added support for power buttons connected to an AXP152 pmic -Improved A20 support, adding kernel support for the following pheriphals: -usbc0 / otg usb controller -nand -mali (*) -g2d (*) -cedar (*) -resistive touchscreen (sun4i-ts) -gpio -ir receiver -leds *) kernel driver only, needs userspace blobs New boards: -Marsboard A10 -Sanei N90 Bug fixes: -Fixed USB-1 device support (OHCI) controller on A10s / A13 -Fixed reboot being unreliable on A10s / A13 -Fixed the power button on AXP209 + A20 not working -Fixed 6 second bootup delay when going from uboot to kernel on A20 -Fixed invalid reporting of high load on some boards You can download it here: http://scotland.proximity.on.ca/contrib-images/hansg/Fedora-19-a10-armhfp-r2.img.xz sha1sum: 2c633c84d5b0c9d0f6118e9a8217395d45978d8 It is important to read the README, the image standard comes without u-boot pre-loaded since u-boot is board specific. The image includes a user-friendly simple script to install the right u-boot for your board, but if you simply xzcat the image to an sdcard, and then boot your device with the sdcard, things will *not* work. See the README for a list of currently supported boards. Known Issues: -Many boards don't have an rtc (A10 and A20 have a builtin one), or at least no battery backup for it, resulting in the date + time being wrong. -If the date is of by more then a couple of months, yum update won't work because certificate validation fails for the https connection yum tries to make. So if yum fails to get its repodata first check (and fix) your date -The wifi chip on the Auxtek-T004 hdmi-stick is unsupported atm Enjoy, Hans And to make sure everyone reads the README, let me print it here in full: Fedora 19 ARM for Allwinner A10, A10s, A13 and A20 devices README - Quickstart guide 1) Insert an sdcard, note any data on the card will be destroyed! 2) Make sure the card is not mounted, run mount and if the card shows up in the output umount its partitions 3) Write the img file to the card, ie as root do: xzcat Fedora-19-a10-armhfp-r2.img.xz /dev/mmcblk0 sync 4) The card is not yet ready for use! Since the A10 u-boot is board specific, the image comes without any uboot install, follow the next steps to install the right u-boot for your board 5) Remove the card, and re-insert it. The uboot partition should get automatically mounted, if not mount it manually, 6) As root (or through sudo) run: uboot-part-mount/select-board.sh, ie: sudo /run/media/hans/uboot/select-board.sh If you've dialog installed the select-board.sh script will prompt for your board. If you don't have dialog installed, it will print the list of supported boards. Lookup your board and re-run the script with the shortname for your board as argument, ie: sudo sh /run/media/hans/uboot/select-board.sh mk802 7) umount the uboot and rootfs partitions, ie: umount /run/media/hans/uboot umount /run/media/hans/rootfs 8) Your sdcard is now ready for use 9) *Before* powering up your A10 device connect it to an hdmi or dvi monitor 10) When first booting from the sdcard inserted Fedora will automatically reboot once, this is part of the process to resize the root partition to fill the entire sdcard and is normal behavior. 11) After the automatic reboot Fedora will start with the initial-setup wizard: 11a) Configure networking, note: * If you've an A10 board with wired ethernet and you want to use dhcp you don't need to do anything. * If you've an A20 board, your ethernet may have a random mac-address, so if you want to configure a static ip-address and want it to stick across reboots, go to the ethernet-tab, select the mac-address field and delete its contents, so that the static ip address you're configuring does not get tied to the random mac-address. 11b) Setup the time zone 11c) Set a root password 11d) Create a user 12) Log in as the just created user 13) Enjoy Fedora on your A10 device Supported Devices: -- Fedora 19 ARM for Allwinner A10 has been tested with the following devices: * A10s-OLinuXino-MICRO (Olimex) * A13-OLinuXino (Olimex) * A13-OLinuXino-MICRO (Olimex) * A20-OLinuXino-MICRO (Olimex) * Auxtek T003 hdmi tv stick * Auxtek T004 hdmi tv stick * BA10 TV Box * Cubieboard development board 1024
Re: mc alternative: Double Commander
Hi, On 09/23/2013 11:44 AM, Christopher Meng wrote: Side note: I've also sent review request to the BZ. If someone can give me a better solution of gtk/qt widgetset, which means keeping these 2 in 1 package, welcome. Yes, do the build twice, including running %configure twice with a make distclean in between. IE something like %configure --with-qt4 make mv doublecmd doublecmd-qt4 make distclean %configure --with-gtk2 make And then in %install manually install the binary you saved from getting nuked by make distclean by moving it out of the way. This way you can have one srpm, named simply doublecmd, with -qt4 and -gtk2 sub-packages. You can then use the main package to store common files and make both require it, or simple don't have a %files only a %files qt4 and %files gtk2 and then rpmbuild won't create a main binary package, only the 2 subpackages (while still creating a single src rpm named after the main package). This seems like the best way to deal with this to me (and is how things like this are done in numerous other packages). Please try this, if you get stuck, send me a link to an srpm with your attempts and I'll try to fix it, I might even review this :) Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [linux-sunxi] Announcing Fedora 19 ARM remix for Allwinner SOCs release 2
Hi, On 09/28/2013 08:17 PM, jonsm...@gmail.com wrote: On Sat, Sep 14, 2013 at 3:55 PM, Hans de Goede hdego...@redhat.com wrote: Hi All, I'm very happy to announce the second release (r2) of my Fedora 19 ARM remix images for Allwinner A10, A10s, A13 and A20 based devices. This release is based on the official Fedora 19 Final for ARM images, with u-boot and kernel(s) from the linux-sunxi project: http://linux-sunxi.org/ Runs for me but don't do a 'yum update'. Update will make the system unbootable. Yes, my bad the kernel package name of the base image has changed, so the exclude I'm adding to yum.conf no longer works with F-19. You can still use yum update like this: yum update --exclude=kernel* It looks like there are some other issues with release 2 too, so I will likely do a release 3 including a fix for this. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [linux-sunxi] Announcing Fedora 19 ARM remix for Allwinner SOCs release 2
Hi, On 09/30/2013 03:20 AM, jonsm...@gmail.com wrote: snip I didn't know about the command line option. This looks like the problem Kernel command line: console=tty0 root=/dev/mmcblk0p3 ro rootwait loglevel=5 panic=10 console=ttyS0,115200 disp.screen0_output_mode=EDID:1280x720 p60 hdmi.audio=EDID:0 sunxi_g2d_mem_reserve=0 sunxi_ve_mem_reserve=0 sunxi_fb_me m_reserve=20 sunxi_no_mali_mem_reserve Might make sense to set it so that mali/cedar can load. That way people will be able to work on them. The idea is to give people the largest amount of free RAM possible in the default config, this is esp. important for 256MB RAM boards. People who want to use cedar / mali will need to do all kind of reconfiguration themselves anyways. I'll add something about needing to tweak the kernelcmdline for this to the README. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gnome-boxes downgrade in F-19
Hi, On 10/09/2013 01:08 PM, drago01 wrote: On Tue, Oct 8, 2013 at 10:38 PM, M A Young m.a.yo...@durham.ac.uk wrote: On Tue, 8 Oct 2013, Dan Williams wrote: On Tue, 2013-10-08 at 08:42 -0600, Jerry James wrote: Do you remember when I ranted about lack of communication between provenpackagers and the maintainers of the packages they touch [1]? Here is another case of lack of communication between people touching the same package. On Aug 8, Zeeshan Ali built gnome-boxes-3.8.4-1.fc19 and submitted update FEDORA-2013-14567. On Aug 9, Christophe Fergeau built gnome-boxes-3.8.4-2.fc19. Instead of editing the existing update, Christophe chose to create a competing update, FEDORA-2013-14530. Seems like there's something wrong with Bodhi here, because every time I create an update when there's already an older update pending, Bodhi obsoletes the old one and adds all the bugs from the old one to the new update. Even if somebody else filed the older update and I'm creating the new one. AFAIK, normal procedure is that you *don't* edit the old update at all, but each package NVR should get a new Bodhi update (so Christophe was correct in creating a new competing one) but that Bodhi takes care of obsoleting the old one. I have had this sort of thing happening to me a few times. From what I remember, Bodhi doesn't seems to obsolete packages that are in the pending state for updates-testing, so if you submit a new build within a day or so of the previous one (for example if a security update comes out just after another build) then bodhi may not obsolete the older build automatically. This sounds broken ... have you filed a bodhi ticket? +1 I've been bitten by this too, and I too consider this a bodhi bug and would like to see it fixed. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [linux-sunxi] Re: Announcing Fedora 19 ARM remix for Allwinner SOCs release 1, now with A20 support
Hi, On 09/19/2013 03:47 PM, davide.soldan.kynet...@gmail.com wrote: Hi Hans, I'm having a problem testing your fedora 19 remix on Olinuxino a10s. The board boot well, and I can login from the serial port, but Xorg crashes with these outputs: at boot: http://pastebin.com/PEZf9eKq after boot if I login and try startx: http://pastebin.com/HateKEi8 the board/sdcard/hdmi cable works well as I can run the base debian distro from olimex with the same components. Also the various script.bin, uImage ecc should be ok as I checked that were the one's for sun5i. Can you help me with this problem? Yes, there was an error in the fex / script.bin file for the Olinuxino a10s causing it to not send video to the hdmi output with Fedora 19 ARM remix for Allwinner SOCs release 1. This is fixed in release 2, but in release 2 I ended up picking a bad u-boot snapshot (and doing a bad QA job as well), so that one does not boot on sun5i devices at all. Attached is a good script.bin for the Olinuxino a10s, if you drop this in the u-boot partition of your sdcard the hdmi out should work. Regards, Hans script.bin Description: Binary data -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] Announcing Fedora 19 ARM remix for Allwinner SOCs release 2
Hi, On 10/01/2013 07:10 PM, Niels de Vos wrote: On Sat, Sep 14, 2013 at 09:55:38PM +0200, Hans de Goede wrote: Hi All, I'm very happy to announce the second release (r2) of my Fedora 19 ARM remix images for Allwinner A10, A10s, A13 and A20 based devices. This release is based on the official Fedora 19 Final for ARM images, with u-boot and kernel(s) from the linux-sunxi project: http://linux-sunxi.org/ Thanks for the new image! I've tried to run it on my Cubieboard (1024MB) but it fails to boot. This seems to be the same on the 1st image, sorry I did not check that earlier :-/ There seems to be an issue with the 'spl', and maybe something more. Attached is a capture from the serial port showing the reboot-loop that uboot does. Yes I made a bad mistake in r2 adding some a20 u-boot fixex at the last moment which break booting on the a10s The attched logs don't seem to be from this problem though, is this with r1 ? How are you powering the board ? Powering it on the uarrt connector (through a usb - serial convertor) generally leads to quite unreliable operation. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Announcing Fedora 19 ARM remix for Allwinner SOCs release 3
Hi All, I'm very happy to announce the third release (r3) of my Fedora 19 ARM remix images for Allwinner A10, A10s, A13 and A20 based devices. This release is based on the official Fedora 19 Final for ARM images, with u-boot and kernel(s) from the linux-sunxi project: http://linux-sunxi.org/ New this release: 1) Fix the bad brown paper bag bug in r2 which caused it to not boot on sun4i (A10) and sun5i (A13/A10s) devices 2) Support for the cubietruck (except for the wifi module) 3) Support for the Megafeis A08 and Mini-X with A10s You can download it here: http://people.fedoraproject.org/~jwrdegoede/a10-images/Fedora-19-a10-armhfp-r3.img.xz sha1sum: a57e5897e0c6047dbb473c438016d6364fd0709f It is important to read the README, the image standard comes without u-boot pre-loaded since u-boot is board specific. The image includes a user-friendly simple script to install the right u-boot for your board, but if you simply xzcat the image to an sdcard, and then boot your device with the sdcard, things will *not* work. See the README for a list of currently supported boards. Known Issues: -Many boards don't have an rtc (A10 and A20 have a builtin one), or at least no battery backup for it, resulting in the date + time being wrong. -If the date is of by more then a couple of months, yum update won't work because certificate validation fails for the https connection yum tries to make. So if yum fails to get its repodata first check (and fix) your date -The regular (host not otg) usb-port on A10s based boards can be a bit quirky. It is best to plug in a hub even when using only one device, otherwise the device may not be recognized. If this happens, after adding a hub, often a power-cycle is needed too. -The wifi chip on the Auxtek-T004 hdmi-stick and on the cubietruck are unsupported atm Enjoy, Hans And to make sure everyone reads the README, let me print it here in full: Fedora 19 ARM for Allwinner A10, A10s, A13 and A20 devices README - Quickstart guide 1) Insert an sdcard, note any data on the card will be destroyed! 2) Make sure the card is not mounted, run mount and if the card shows up in the output umount its partitions 3) Write the img file to the card, ie as root do: xzcat Fedora-19-a10-armhfp-r2.img.xz /dev/mmcblk0 sync 4) The card is not yet ready for use! Since the A10 u-boot is board specific, the image comes without any uboot install, follow the next steps to install the right u-boot for your board 5) Remove the card, and re-insert it. The uboot partition should get automatically mounted, if not mount it manually, 6) As root (or through sudo) run: uboot-part-mount/select-board.sh, ie: sudo /run/media/hans/uboot/select-board.sh If you've dialog installed the select-board.sh script will prompt for your board. If you don't have dialog installed, it will print the list of supported boards. Lookup your board and re-run the script with the shortname for your board as argument, ie: sudo sh /run/media/hans/uboot/select-board.sh mk802 7) umount the uboot and rootfs partitions, ie: umount /run/media/hans/uboot umount /run/media/hans/rootfs 8) Your sdcard is now ready for use 9) *Before* powering up your A10 device connect it to an hdmi or dvi monitor 10) When first booting from the sdcard inserted Fedora will automatically reboot once, this is part of the process to resize the root partition to fill the entire sdcard and is normal behavior. 11) After the automatic reboot Fedora will start with the initial-setup wizard: 11a) Configure networking, note: * If you've an A10 board with wired ethernet and you want to use dhcp you don't need to do anything. * If you've an A20 board, your ethernet may have a random mac-address, so if you want to configure a static ip-address and want it to stick across reboots, go to the ethernet-tab, select the mac-address field and delete its contents, so that the static ip address you're configuring does not get tied to the random mac-address. 11b) Setup the time zone 11c) Set a root password 11d) Create a user 12) Log in as the just created user 13) Enjoy Fedora on your A10 device Supported Devices: -- Fedora 19 ARM for Allwinner A10 has been tested with the following devices: * A10s-OLinuXino-MICRO (Olimex) * A13-OLinuXino (Olimex) * A13-OLinuXino-MICRO (Olimex) * A20-OLinuXino-MICRO (Olimex) * Auxtek T003 hdmi tv stick * Auxtek T004 hdmi tv stick * BA10 TV Box * Cubieboard development board 1024 MB RAM * Cubieboard2 (A20) development board * Cubietruck development board * Gooseberry development board * Mele A1000G/A2000G 1024 MB RAM * Mini-X 1024 MB RAM * mk802 (with female mini hdmi) 512 MB RAM * mk802 with A10s (s with a circle around it on the barcode label) * mk802ii (with male normal hdmi) 1024 MB RAM * r7 hdmi tv stick * UHost
Re: prelink performance gains
Hi, On 10/17/2013 04:54 PM, Paul Wouters wrote: On Thu, 17 Oct 2013, Daniel P. Berrange wrote: There's no reason to kill the package entirely. Some people still want to use it despite the current issues. So just don't install it by default. Reducing everything down to absolutes isn't helpful. Agreed, there's no reason to kill it entirely. Let people opt-in if they wish to install it later understand the cost/benefit tradeoff. How do we make it go away on the installs it currently affects badly? Do we add Conflict: to some packages (eg FIPS capable ones) ? We could change the default /etc/sysconfig/prelink to default to no prelinking, then for people with an unmodified /etc/sysconfig/prelink, this will become the new /etc/sysconfig/prelink and the first time the cronjob runs after the update it will unprelink all binaries (and I hope it is smart enough to not run any more after that). Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: bcache-tools and bcache support in other linux packages
Hi, On 10/18/2013 11:56 AM, Rolf Fokkens wrote: Hi all, We've been waiting to see if other people who couldn't make on Sunday would also do some testing. That hasn't happened, so a few words on my impressions on the test day are appropriate indeed. First of all not many people really did some testing. We didn't expect many people to participate, but the 3 people who did (many thanks to them!) were the bare minimum we anticipated. This was probably caused by the following: - SSD caching may need more explanation, not many people understand what it is and what the benefits are - Because it's hard to change an existing partition to a 'bcached' partition, it's not really tempting to test (there's a blocks utility under development that may help, currently backup-restore is the only way). - Not many people have the required resources available to do testing. Even when testing in a VM not many people have the required 10GB available (The requirements could be lowered top about 6GB, so that might help) - Installing F20 as requested in the prerequisites was harder to the testers than we anticipated. Specifically planning a specific partition layout in Anaconda requires a lot of attention (I could upload a VM image somewhere to facilitate that). About the testing itself: - the alignment of the tools (bcache-tools, kernel, util-linux and dracut) is really good now, people were able to do the testcases (1.A and 1.B) without a hitch. - nobody tested the LVM integration (testcases 2.A and 2.B), so no test results on that part. - Unfortunately kernel 3.11.4 (which was the latest version on Sunday) exhibited a bug during stress testing (https://bugzilla.redhat.com/show_bug.cgi?id=1018615), but that bug is supposed to be fixed in kernel 3.11.5 which was released later this week. So I think SSD Caching (using bcache) is in a good shape, but I would like to encourage people to do some more testing. Of course other feedback is also appreciated. Good work, and thanks for the detailed summary! Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [linux-sunxi] Re: Announcing Fedora 19 ARM remix for Allwinner SOCs release 1, now with A20 support
Hi, On 11/11/2013 07:56 PM, Roman Mamedov wrote: On Mon, 11 Nov 2013 10:01:05 -0800 (PST) deasy ledesillusionni...@gmail.com wrote: Mele A1000G support ? Sure ? It's with an A31 right ? As someone asked on the channel linux-sunxi for linux distro on a1000g(a31) and we have answered there is no distro for it. There was Mele A1000G with A10 and 1GB of RAM: http://dx.com/p/mele-a1000g-android-4-0-google-tv-player-w-wi-fi-sd-1gb-ram-8gb-rom-vga-black-161823 Right, that is what the A1000G support is for. The A31 one is called A1000G Quad. http://www.aliexpress.com/store/product/Quad-Core-Mele-A1000G-Quad-Mini-PC-Android-4-1-TV-Box-Allwinner-ARM-CortexA7-2GB/715968_818962879.html And not for this one. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [linux-sunxi] Re: Announcing Fedora 19 ARM remix for Allwinner SOCs release 1, now with A20 support
Hi, On 11/11/2013 09:44 PM, Richard W.M. Jones wrote: On Mon, Nov 11, 2013 at 08:43:48PM +, Richard W.M. Jones wrote: On Mon, Nov 11, 2013 at 08:11:35PM +0100, Hans de Goede wrote: Hi, On 11/11/2013 07:56 PM, Roman Mamedov wrote: On Mon, 11 Nov 2013 10:01:05 -0800 (PST) deasy ledesillusionni...@gmail.com wrote: Mele A1000G support ? Sure ? It's with an A31 right ? As someone asked on the channel linux-sunxi for linux distro on a1000g(a31) and we have answered there is no distro for it. There was Mele A1000G with A10 and 1GB of RAM: http://dx.com/p/mele-a1000g-android-4-0-google-tv-player-w-wi-fi-sd-1gb-ram-8gb-rom-vga-black-161823 Right, that is what the A1000G support is for. The A31 one is called A1000G Quad. http://www.aliexpress.com/store/product/Quad-Core-Mele-A1000G-Quad-Mini-PC-Android-4-1-TV-Box-Allwinner-ARM-CortexA7-2GB/715968_818962879.html And not for this one. Aren't those two the same thing? Obviously I see they're not the same. How hackable is the A31-based box? AFAIK it is similar to other allwinner devices and it is reasonable hack-able, (ie not locked down, most source code available in the form of android kernels) but no one really is working on it. AFAIK there is some rudimentary support in the upstream kernel. Assuming this soc uses the same ip-blocks for mmc and network as the A10 / A20 it could be that support for it will get better as those get better support upstream. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Should /usr/bin/Xorg (still) be setuid-root?
Hi, On 01/09/2014 12:09 AM, Andrew Lutomirski wrote: On Wed, Jan 8, 2014 at 2:58 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Wed, Jan 08, 2014 at 01:14:08PM -0800, Andrew Lutomirski wrote: /usr/bin/Xorg is, and has been, setuid-root just about forever. I'm wondering whether there's any good reason for it to remain setuid-root. http://fedoraproject.org/wiki/Changes/XorgWithoutRootRights This isn't actually the same thing. That proposal suggests running Xorg as a non-root user. I'm proposing dropping the setuid bit on the binary, which will have no effect on the uid of the running server. (Of course, my suggestion will interact w/ that change, since the process that starts Xorg will no longer be root.) I don't think that that will be very useful, it will likely cause more breakage then you think, as various display-managers may already start Xorg inside the user session, at which point the suid bit is needed, and as you already said it will break xinit and friends. Besides that almost every Fedora system already has a copy of the X server running as root ready to be exploited. The attack service of X is not its cmdline or attacks through environment settings (2 vectors your suggestion would close), but rather the gargantuan API it exposes over the X protocol itself. It may be that XorgWithoutRootRights will clear the setuid bit as well, though. Hopefully, either clear it completely or drop root rights very early on on startup. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Should /usr/bin/Xorg (still) be setuid-root?
Hi, On 01/09/2014 09:52 PM, Andrew Lutomirski wrote: On Thu, Jan 9, 2014 at 11:43 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 01/09/2014 12:09 AM, Andrew Lutomirski wrote: On Wed, Jan 8, 2014 at 2:58 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Wed, Jan 08, 2014 at 01:14:08PM -0800, Andrew Lutomirski wrote: /usr/bin/Xorg is, and has been, setuid-root just about forever. I'm wondering whether there's any good reason for it to remain setuid-root. http://fedoraproject.org/wiki/Changes/XorgWithoutRootRights This isn't actually the same thing. That proposal suggests running Xorg as a non-root user. I'm proposing dropping the setuid bit on the binary, which will have no effect on the uid of the running server. (Of course, my suggestion will interact w/ that change, since the process that starts Xorg will no longer be root.) I don't think that that will be very useful, it will likely cause more breakage then you think, as various display-managers may already start Xorg inside the user session, at which point the suid bit is needed, and as you already said it will break xinit and friends. This is an empirical question :) gdm on F20, at least, can still switch users with the setuid bit cleared. I'll try to test some more display managers. Well starting X inside the user session is necessary for the systemd-logind integration I'm working on, which in turn is necessary to be able to completely run X without any root rights at all. So this quite likely is going to be how X will be started in F-21. I hope it clears the bit -- I really don't like the fact that 'X :1' screws with the display. I'm not sure yet if it will clear the bit, I'm pretty sure I can get things to work without any root rights for kms drivers (not 100% sure yet), but ums drivers will fail hard without the suid bit, the ums part of this needs some thinking (and needs me to dig up a card actually using it). I might end up deciding to just kill ums support and then see what happens, but I would rather not, and if I get enough pushback I might revert on such a decision :) Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Why should I ever bother filing another bug?
Hi, On 11/09/2010 07:14 PM, Adam Williamson wrote: On Tue, 2010-11-09 at 11:49 -0600, Michael Cronenworth wrote: Adam Williamson wrote: Only point to note is that it would definitely be a good thing to fix Bugzilla to merge the CC lists, I'll file a bug on that. =) Filed 9 years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=108983 Or 1 year ago: https://bugzilla.redhat.com/show_bug.cgi?id=523634 well hey, that saves me the trouble. :/ I completely understand the :/ I myself haver filed a bug about bugzilla setting a mime type which browsers don't recognize rather then text/plain, which would be correct: https://bugzilla.redhat.com/show_bug.cgi?id=555677 I cannot help but notice a trend here, that our bugzilla is not getting the love it needs :( Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fixing the glibc adobe flash incompatibility
Hi all, For those who do not know it yet, recent Fedora glibc updates include an optimized memcpy (which gets used on some processors) which breaks the 64 bit adobe flash plugin. The problem has been analyzed and is known, as well as a fix for it, see: https://bugzilla.redhat.com/show_bug.cgi?id=638477 The problem still exists however. The glibc developers say that this is not a glibc bug, but a flash plugin bug. And technically they are 100% correct, and the adobe flash plugin is a buggy (no surprise there). To be specific the flash plugin is doing overlapping memcpy-s which is clearly not how memcpy is supposed to be used. But the way the flash plugin does overlapping memcpy's happens to work fine as long as one as the c library does the memcpy-s in forward direction. And the new memcpy implementation does the memcpy in backward direction. The glibc developers being technically 100% correct is not helping our end users in this case though. So we (The Fedora project) need to come up with a solution to help our end users, many of whom want to use the adobe flash plugin. This solution could be reverting the problem causing glibc change, or maybe changing it to do forward memcpy's while still using the new SSE instructions, or something more specific to the flash plugin, as long as it will automatically fix things with a yum upgrade without requiring any further user intervention. I would also like to point out that if this were to happen in Ubuntu which we sometimes look at jealously for getting more attention / users then us, the glibc change would likely be reverted immediately, as that is the right thing to do from an end user pov. I've filed a ticket for FESCo to look into this, as I believe this makes us look really bad, and the glibc maintainers do not seem to be willing to fix it without some sort of intervention: https://fedorahosted.org/fesco/ticket/501 Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swaps
Hi, I'm looking for someone to swap 2 reviews with, I would like to see the following reviewed: cortado - Java media framework: https://bugzilla.redhat.com/show_bug.cgi?id=649781 CEGUI library 0.6 for apps which need this specific version: https://bugzilla.redhat.com/show_bug.cgi?id=650643 Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
Hi, On 11/19/2010 10:39 AM, Richard Zidlicky wrote: On Thu, Nov 18, 2010 at 06:28:58PM +0100, Kevin Kofler wrote: thanks for looking at it. However for some of the reports it is only the matter of someone looking at them as they contain the obvious solution to the problem. https://bugzilla.redhat.com/show_bug.cgi?id=595165 https://bugzilla.redhat.com/show_bug.cgi?id=582013 The solution is not obvious at all: to include firmware, we need a license which allows that in the first place. The Ubuntu mailing list link you posted to one of your reports does not include any actual license, only talks about some license existing somewhere (which don't even tell us whether that license is acceptable for Fedora in the first place – we're quite tolerant when it comes to firmware licenses, but there are some restrictions which are unacceptable even for firmware, e.g. forbidding any commercial use). Plus, this is not actually an issue with Free Software, but with the lack of some proprietary firmware. it is against free in kernel drivers and the bugs have been rotting in bugzilla for the lifecycle of F11 and F12 without anyone even asking for info or anything. And finally, those bugs should be filed against linux-firmware, not kernel. I will file it with the correct package the next time when I confirm this is still an issue. Note, I've mailed Steven Toth (the owner of the website where the firmware is hosted) asking him if he can provide us with a clear license document for these firmwares. I've also indicated that it would be even better if the could get them into linux-firmware upstream. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora release model (was Re: Plan for tomorrow's FESCo meeting (2010-11-17))
Hi, On 11/22/2010 12:59 AM, Adam Williamson wrote: On Sun, 2010-11-21 at 23:04 +0100, Kevin Kofler wrote: In short: Want higher-quality updates for previous releases? Then push version upgrades wherever possible (even and especially for libraries, as long as they're ABI-compatible or can be group-pushed with a small set of rebuilt reverse dependencies)! I don't agree with this at all. It's just abusing a stable release cycle to try and make it into something it isn't. I should probably clarify where I'm coming from on this, as my position is probably more nuanced than my mails so far would seem to suggest. I don't necessarily think Fedora works best as a project which does stable releases every six months and supports at least two of them at a time (and often three). As I've written elsewhere, I'd very much like to look into the possibility of changing that. snip It seems like what you want is actually not to have three releases at a time at all but to have one and update it constantly. And I actually rather suspect that would be a model that would work well for Fedora, and I'd like to look into adopting it. Interesting topic (much more so then flaming about the updates policy) I think that we can (and sort of do already) have both. The way I see it, is we have: rawhide (and for a part of the cycle Fedora #+1 testing) Fedora # Fedora #-1 Fedora #-2 Fedora #+1 is for people who want the bleeding edge Fedora # is for people who want the latest and greatest without too much bleeding Fedora #-1 is for people who want it relatively safe and slow Fedora #-2 Does not fit into this picture So taking for example the much much discussed KDE rebases. I think that doing a KDE rebase for Fedora #+1 is a no brainer, for Fedora # is fine as long as it is properly tested and for Fedora #-1 KDE should NOT be rebased. This also matches well with what the KDE people have been reporting, were they can get plenty of testing on Fedora # but all most none on Fedora #-1. I think that the few KDE users which remain on Fedora #-1, do so because they appreciate some stability, and thus should not get (a largely untested) KDE rebase. This is also how I in practice deal with must updates for packages I maintain I try to fix any serious bugs reported against Fedora # and am a lot more conservative when it comes to Fedora #-1. Note that Fedora #-2 does not fit into this view for things at all, Fedora #-2 is meant to allow people to skip a Fedora release. But in practice I think this works out badly, because a relatively new Fedora release like Fedora 14 tends to still have some rough edges and get lots of updates/churn (and thus possible regressions, despite our best effords). This is not at a good point in its cycle to upgrade to for people who like it stable (and sticking with 1 release for an entire year to me sounds like liking it stable). Where as the one which has already been out for 5-6 months (Fedora 13) has seen most rough edges polished away with updates, and the updates rate will have slowed. So maybe it is time we dropped the support duration for a release from 13 to 11 months, and make clear that people should not skip releases. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
Hi, On 11/24/2010 12:45 AM, Jesse Keating wrote: On 10/5/10 3:27 PM, Jesse Keating wrote: snip Here is a list of the current known potentially bad builds and what action could be or has been taken: wildmidi - my rebuild can be tagged tecnoballz - my build can be tagged These 2 are mine and FWIW, I'm ok with directly tagging the rebuilds into updates Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora default services (was: Re: F15 Feature - convert as many service init files as possible to the native SystemD services)
Hi, On 12/06/2010 06:34 AM, Michał Piotrowski wrote: Hi, W dniu 3 grudnia 2010 09:14 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: [..] What services are installed by default when installong form Live GNOME/KDE/etc and DVD? Ok, let's ask the question differently - what services should be run by default to provide working system for desktop user? IMO ssh can be off by default and should be started only if user tries to connect over port 22. Do we really need to install iptables/ip6tables by default (it's in core group)? Do we really need a firewall configured ? Yes we do because of blinkbSECURITY/b/blink I'm sorry but asking if we really need iptables by default is just stupid! Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding ARM Cross generation patch to gcc and binutils specfiles
Hi, On 12/24/2010 01:43 PM, Andy Green wrote: Hi - snip I see Hans looks after arm-gp2x-linux-gcc which is also stuck in a gcc-4.1.2 timewarp that maybe my uplevelled patch can also help. arm-gp2x-linux-gcc is deliberately stuck at 4.1.2, because that is the version the gp2x community has settled at as using as a toolchain. With that said the arm-gp2x-linux-* packages could use some love, which I've been failing to give them due to lack of time. Mostly what they need is packaging of some more cross-compiled libs (like SDL_mixer and other SDL_foo's) to make the chain usable to compile a wider range of gp2x programs. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning packages
Hi, On 12/29/2010 08:04 PM, Jon Ciesla wrote: Johan Cwiklinski wrote: Hi, I'm going to orphan following packages: - BackupPC ([1], [2], [3], [4]) - childsplay ([5], [6]) - gcompris (several open bugs, see [7]) - homebank ([8], [9]) - php-pear-MDB2-Driver-mysqli (no open bugs) - php-pear-MDB2-Driver-pgsql (no open bugs) - php-pecl-solr (no open bugs) - pyfribidi - required for childsplay([10], [11]) - tuxmath ([12]) I'd like to take tuxmath. Thinking about childsplay, gcompris and the like, but don't release those yet. I can take childsplay, gcompris and pyfribidi, but I certainly would not mind someone else taking them. Jon, How about we co-maintain them? I would be happy to be the primary owner (for whatever that may mean). Johan, can you please release these 3 packages? Thanks Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in rawhide
Hi, On 02/07/2011 09:59 PM, Bill Nottingham wrote: Each release, we undergo the effort to track down owners for orphaned packages in the release, and block those orphaned packages where necessary. It's that time again for Fedora 15. The following packages are currently orphaned and exist in F-15. As you can see, there are a lot of dependencies on these packages. Please pick up these packages if you have a need for them. Orphan atomix I've taken atomix, co maintainers welcome. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: v4l1 (linux/videodev.h) and libv4l
Hi, On 02/09/2011 09:11 AM, Kevin Kofler wrote: Hi, several of the build failures in Rawhide are due to the removal of v4l1 from the kernel, which manifests itself as a missinglinux/videodev.h header. (I think there was a thread about that on this list already, but I can't find it now.) My questions: * Couldn't v4l1-only apps be made to work with minimal porting effort through libv4l's libv4l1compat, without v4l1 support in the kernel? Yes, libv4l's libv4l1compat was extended recently to no longer rely on the in kernel compat at all. * libv4l's libv4l1compat itself also fails to build due to a missing linux/videodev.h. It obviously needs the #defines there to emulate the API. Should libv4l ship that header now? That header should be integrated into the libv4l1 header, this is on my to do list. * It's quite embarassing to have libv4l be one of the packages failing to build due to a kernel v4l change. Why wasn't this change coordinated with libv4l? It was (I'm the libv4l author / maintainer and knew this was coming for months) yet when it actually happened it still managed to catch me by surprise :) I plan to have a fixed libv4l package out soon. All apps which break because of this should already be using libv4l1 (purely relying on kernel v4l1 compat has not been a good idea for ages), so they should already be including libv4l1.h in all the right places, all that should be needed once libv4l is fixed is no longer also including linux/videodev.h. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: v4l1 (linux/videodev.h) and libv4l
Hi, On 02/09/2011 09:11 AM, Kevin Kofler wrote: Hi, several of the build failures in Rawhide are due to the removal of v4l1 from the kernel, which manifests itself as a missinglinux/videodev.h header. (I think there was a thread about that on this list already, but I can't find it now.) My questions: * Couldn't v4l1-only apps be made to work with minimal porting effort through libv4l's libv4l1compat, without v4l1 support in the kernel? * libv4l's libv4l1compat itself also fails to build due to a missing linux/videodev.h. It obviously needs the #defines there to emulate the API. Should libv4l ship that header now? * It's quite embarassing to have libv4l be one of the packages failing to build due to a kernel v4l change. Why wasn't this change coordinated with libv4l? A new version of libv4l fixing this has just finished building. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Package review swaps
Hi, I've a package in need of a review, I'll happily swap another review in return: https://bugzilla.redhat.com/show_bug.cgi?id=671883 Bug 671883 - Review Request: v4l-utils - Utilities for video4linux and DVB devices Thanks Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swaps
Hi, I've been working on packaging lcd4linux (to use together with the digital picture frames I also wrote a libgphoto driver for a while ago). The packaging is complete and now I'm looking for reviewers for the following 3 packages. As usual I'll gladly swap a review for a review. Note that the first 2 are deps of the lcd4linux. 678887 - Review Request: libst2205 - Library for accessing the display of hacked st2205 photo frames 678889 - Review Request: serdisplib - Library to drive serial displays with built-in controllers 678891 - Review Request: lcd4linux - Display system state on an external LCD display Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File SDL_Perl-v2.2.6.tar.gz uploaded to lookaside cache by jwrdegoede
A file has been added to the lookaside cache for perl-SDL: 445950ca7b9991f34ec792bbac8386b6 SDL_Perl-v2.2.6.tar.gz -- 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
Re: 42 Orphaned packages
Sven Lankes s...@lank.es wrote: basket I'll take this. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: 42 Orphaned packages
Hi, On 03/10/2011 09:16 AM, Hans de Goede wrote: Sven Lankess...@lank.es wrote: basket I'll take this. Ugh, I mistakenly confused this with bastet, untaking it, sorry for the pkgdb acl change spam to those involved. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shared library permissions in Debian-land and Red Hat-land
Hi, On 03/28/2011 10:11 PM, Nathaniel McCallum wrote: On Mon, 2011-03-28 at 16:05 -0400, Przemek Klosowski wrote: On 03/24/2011 02:49 PM, Kevin Kofler wrote: On Thursday 24 March 2011, you wrote: Hmm, I thought there'd be a catch. What's executable permission needed for? Isn't that just reading/parsing? I can do some work but I am totally unfamiliar with this area. Files which aren't executable aren't even considered as candidates for being ELF files to extract debuginfo from. Without execute permission, you'd have to check EVERY SINGLE installed FILE for being ELF, that might be a significant performance hit. It'd have to be tried at least. OK, so executable permission is used as a tag for identifying ELF files. It's a little inelegant because there are some negative side effects from executing those non-executable files. If, hypothetically, we wanted to change that, is there any other way to reliably mark ELF files? I could think of those: - extended filesystem attributes? works but might be FS-dependent - make the files owned by a special ELF group - a system-level directory of ELF files maintained by e.g. RPM Well, technically you could still use +x for other non-shared library ELF files, you'd just also need to look for .so files. That seems to me the simplest solution and should still be fast since the filename is in the directory inode (which you have to read anyway). Note that while discussing things it would be good to fix the long standing rpm feature of auto generating provides for .so files even though they are intended for dl-opening only. Currently rpm needs to know if something is an elf shared object for 2 reasons: 1) To generate debuginfo 2) To generate an auto provides of the soname If we're going to make changes here I would really to see the heuristic for 2 changed from is it executable to does it live under /lib[64] or /usr/lib[64]. This will remove the need to add tons of provides filters to perl or python packages which contain some native bits. Yes this will break the provides generation for packages which install real / normal libraries under a different dir. Well good for them that moves the pain of dealing with special cases wrt auto Provides to the special cases, rather then making any packages which has plugins or other wise dlopen only shared objects deal with it. Also note that packages installing libraries under a different dir often do so, because they offer replacement libs for a system library (ie libGL from the binary nvidia driver from a 3th party repo) and in this case actually not having the Provides for the soname is the right thing to do! Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
Hi, On 04/26/2011 11:47 AM, Martin Cermak wrote: Hi all, I'm a RH QA engineer located in Brno. Nice to meet you. I'm a long time Fedora contributor, and since 2.5 years a software engineer for RH :) I searched the web for some nice command line calendar which could track events and I found pal [1]. It is practical and I'm using it. It is a simple piece of code, included in Debian, but not yet in Fedora. So for me this looks not only like a useful piece of code, but also as a piece of code suitable for my educational purposes ;) I pinged the upstream (Scott Kuhl, Martijn van Oosterhout) and they are both fine with adding pal to Fedora under my maintenance. So I created a review request [2] and now I'm looking for a sponsor. I'm a sponsor and I would be happy to sponsor you. But first I would like to see slightly more of your packaging skills / understanding of the Fedora packaging guidelines (I already took a quick look at your pal package). There are 2 ways to show your package ninja skills, you can create 1 or 2 more packages (which I will then review together with pal), see here for a list of potential candidates: http://fedoraproject.org/wiki/PackageMaintainers/WishList If you would be interested in packaging up a game or 2 let me know and I'll update the Games SIG wishlist page, as I think that needs some love :) Also we can always use some more nice fonts in Fedora, see the fonts wishlist, and also: http://mairin.wordpress.com/category/unpackaged-font-of-the-week/ Or instead of doing some more packages, you could do some unofficial reviews, also described here: http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self (Re)Introduction
Hi, On 04/29/2011 01:19 AM, Andy Grimm wrote: Hello, all. A brief bio on me: I started using Red Hat Linux in college in 1997. I spent half a decade as a Linux sys admin, and long ago I used to lurk in #redhat and #fedora giving tech support to new users. I first met some of these fine Fedora folks at FUDCon 2005. I finally signed up to be a Fedora contributor while at Ingres in 2007, but that didn't go quite as I expected, and I never submitted packages for review. I left Ingres for rPath, where I spent four years doing support and sustaining engineering for rPath Linux, Conary, and other rPath software; related to that, I've run Foresight Linux on my laptop for a while, so I'm still catching up on some the changes in the world of Fedora since 2007. This month, I joined Eucalyptus as a release engineer, and Garrett Holmstrom and I plan to co-maintain various Eucalyptus-related packages and their dependencies. I also hope to make other contributions as time permits. Welcome! Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New packager introduction
Hi, On 04/29/2011 12:37 AM, Richard Shaw wrote: Hello, I've been a Fedora user since FC6 and a little RH6 before that. Our family pretty much uses Fedora exclusively, including my desktop, MythTV box, and wife's laptop. The wife's laptop can still dual boot Vista, but she never uses it. I've been lurking on the devel mailing list for a while but now I'm officially a Fedora packager, my first package being openCOLLADA[1]. Actually, technically my first package was openshot on RPMFusion and then shortly thereafter picked up avidemux. If only I knew what I was signing up for with that one! :) I look forward to taking on another couple of packages once I get the handle on the process and time permits. Welcome :) Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Self Introduction
Hi, On 04/29/2011 06:53 PM, John Brier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm new to contributing but not new to Linux. I started on RHL 7.1 around 2000 and have used Slackware, Gentoo and Debian in the past. I was active at my university LUG and Gaming Club (running the game servers on Slackware) and now I work for Red Hat since August 2007 in support. Nice to meet you. I'm a long time Fedora contributor, and since 2.5 years a software engineer for RH :) I have been building RPMs for myself on and off almost since I started at Red Hat and switched from Debian to Fedora. I built RPMs for Rivendell [1] which is a large radio automation suite and some recommended getting that into Fedora but at the time it seemed too daunting. Now I am getting into DJing and in particular using FOSS to do it. I have used Mixxx and xwax. I am becoming the co-maintainer of Mixxx in rpmfusion [2] and have just submitted my first package review request for Fedora for xwax. [3] I would like to make Fedora a good platform for digital DJing. Cool! (making Fedora a good platform for digital DJing) In the past I've worked on getting as many packages as possible from planet ccrma into Fedora to make it a better audio production platform. I've stopped half way through because of lack of time though :| I'm a sponsor and I would be happy to sponsor you. But first I would like to see slightly more of your packaging skills / understanding of the Fedora packaging guidelines (I already took a quick look at your xwax package). There are 2 ways to show your package ninja skills, you can create 1 or 2 more packages (which I will then review together with pal), see here for a list of potential candidates: http://fedoraproject.org/wiki/PackageMaintainers/WishList If you would be interested in packaging up a game or 2 let me know and I'll update the Games SIG wishlist page, as I think that needs some love :) Also we can always use some more nice fonts in Fedora, see the fonts wishlist, and also: http://mairin.wordpress.com/category/unpackaged-font-of-the-week/ Or instead of doing some more packages, you could do some unofficial reviews, also described here: http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: illegal instruction - create compile variants ?
Hi,
On 05/01/2011 09:56 AM, David Timms wrote:
On 01/05/11 17:41, Hans de Goede wrote:
Erm, specifying a minimum support CPU in the package description is
not acceptable IMHO. The fix here is to patch the packages buildsystem,
so that it gets build for the minimum cpu level which is supported by
Fedora, and thus will work out of the box on all systems Fedora
supports.
Where is that stated currently, and for older releases ?
I was hoping someone who knows the exact answer knows... All I can give
you is:
http://docs.fedoraproject.org/en-US/Fedora/13/html/Release_Notes/index.html#sect-Release_Notes-Hardware_Requirements
Which is not really exact...
No tricks / hacks with multiple compilation, cpu detect scripts, etc.
will be necessary then.
Though it comes at the cost of audio lag/latency increase when we are
trying to achieve near real time (eg live guitar input to sound effect
generation output). Even on the my machine (4x core amd 3Ghz), the
calculations the app performs for difficult presets (convolution) can
cause jack to abort because rakarrack didn't finish it's calculations
before it was required to deliver data.
Should I be suggesting to upstream to attempt to detect CPU before
running non-available instructions, eg as part of app startup ?
Can that even be done (reliably) ?
As already answered by others ideal would be one binary, which runtime
chooses between normal C and mmx/sse#/whatever variants based
on CPU capabilities.
This is definitely something to ask to upstream, as this won't
be trivial.
In the mean time, you need to patch the build-system so that
you can control what cpu features it will enable, then you
can build a number of variants, install them as
/usr/libexec/%{name}-$cpufeaturepostfix
And make /usr/bin/%{name} a shell script which checks
/cpu/procinfo for features and then executes the right
binary (passing through all cmdline args using the
$@ magic var for proper quoting)
For which variants it makes sense to build, you would
need to talk to someone who is more of a cpu head then me,
try starting a new thread, with an appropriate $subject.
Note that all of this is only really needed on 32 bits,
on 64 bit I believe (*) all cpu's have at least sse2, so unless
you want to use sse3 you'll only need 1 binary there.
Which brings us to a simpler alternative, build a no cpu
specific optimizations 32 bit version and use sse2 on x86_64,
which is nice and simple.
You could then add a README.fedora advising people to use
the 64 bit version.
Regards,
Hans
*) Still no CPU head, better verify this with someone who is.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Intent to package GNOME Shell frippery
Hi all, Just a quick heads-up that I plan to look unto packaging the gnome shell frippery extensions this weekend, if you've the same plans or are already working on this, please let me know. So we can avoid doing double work. I plan to use 1 subpackage per extension of the frippery extension collection, so that people can install only those which they want without automatically getting all of them. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
system-config-keyboard needs some loving, any takers?
Hi All, The mass posting of please check if this bug still happens with newer versions to F-13 bugs made me look at: https://bugzilla.redhat.com/show_bug.cgi?id=545738 Which sadly still has not been fixed yet. While trying to reproduce 545738 I hit: https://bugzilla.redhat.com/show_bug.cgi?id=646041 Which basically means that system-config-keyboard is not functional at all in F-14 and F-15, so it looks like s-c-k needs a new [co-]maintainer to give it some much needed loving, any takers? Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Installing bash-completion by default in F-16
Hi, I somehow missed the top post, so sorry for replying in the middle of the thread. Adding bash-completion by default gets a +1 from me. Note that Ubuntu has been doing this for ages AFAIK, so it is being used by a large group of users without very vocal complaints for years now. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F15 / VirtualBox
Hi, On 06/10/2011 06:12 PM, Thomas Sailer wrote: snip - USB is not really workable. Trying it just now with up2date F15 crashed qemu (guest rawhide) when trying to assign a host USB device to the guest If you're seriously interested in usb redirection, I'm working on seriously improving that and will continue to work on that for a while to come. I would love some feedback wrt my current code. Note that I'm mainly focusing on usb redirection over the network, so that the redirected device does not need to be on the same machine as where the vm is hosted (think viewing a vm from another machine with vnc/spice and then wanting to redirect a usb device from the vnc client machine). Currently my network redirection code is already working in a few scenarios where direct host usb redirection is not working I do plan to eventually fixup direct host usb redirection too (by rewriting it to use libusb and essentially be the same as the network redir variant). But for now you will get the best experience with the network redirection, even if you use it over localhost. For some instructions on setting up a test environment with my latest wip, see: http://hansdegoede.livejournal.com/9682.html Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
scorched3d needs a new owner
Hi, I've not been able to give scorched3d the attention it deserves lately. Specifically it is lagging with upstream for a while now and really needs to be rebased to upstream latest. Is anyone willing to become a new (co)-maintainer for scorched3d and do the rebase? Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: scorched3d needs a new owner
Hi, On 06/18/2011 02:23 PM, Bruno Wolff III wrote: On Sat, Jun 18, 2011 at 08:16:26 +0200, Hans de Goedehdego...@redhat.com wrote: Hi, I've not been able to give scorched3d the attention it deserves lately. Specifically it is lagging with upstream for a while now and really needs to be rebased to upstream latest. Is anyone willing to become a new (co)-maintainer for scorched3d and do the rebase? I signed up to be a co-maintainer. I should be able to work on a rebase over the next week or so. Great, thanks! I've granted you commit and approve acl rights. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: scorched3d needs a new owner
Hi, On 06/18/2011 02:34 PM, Bruno Wolff III wrote: On Sat, Jun 18, 2011 at 08:16:26 +0200, Hans de Goedehdego...@redhat.com wrote: Hi, I've not been able to give scorched3d the attention it deserves lately. Specifically it is lagging with upstream for a while now and really needs to be rebased to upstream latest. Is anyone willing to become a new (co)-maintainer for scorched3d and do the rebase? I see that the latest build is not compatible with previous versions. Probably this is good for playing other people, but bad for previously saved games. How far back do we want to push the update once it's ready? I think we want the update just for F-15. So that people who prefer to stick on the conservative side of things, who will likely still be running F-14, won't get it. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages that will be orphaned
Hi, On 06/20/2011 07:34 PM, Toshio Kuratomi wrote: Due to the requirement for contributors to sign the FPCA by Thursday of last week, certain package owners who haven't yet signed will be removed from the packager group soon. When that happens, the packages that they own will be orphaned. To try and minimize the problems this could cause, I'm publishing the current list of packages to be orphaned and will start reassigning owners if someone asks to take them over. We want to make sure that important packages are not going to be orphaned by this change. We're planning on removing people from packager and orphaning packages on Thursday if all goes well. The list of packages being orphaned are listed below and the list of packages with first level dependencies will be attached. Note that the dependency list could be incomplete in two ways: 1) Since I'm using source package names, we don't capture things that dep on a subpackage. 2) The list does not follow the dep chain out to see if something relies on something that relies on something that relies on a package that's being orphaned. Please reply to this thread if you'd like to take any packages or ping me on IRC and I'll reply to this thread with what packages have been taken. (Needed since we aren't orphaning in the pkgdb until Thursday so you need a cvsadmin to reassign ownership for now). http://toshio.fedorapeople.org/fpca/packages_losing_owners.txt: snip I'll take: adanaxisgpl zvbi And I've also taken the liberty of sending a personal mail to nim (Nicolas Mailhot) pointing out that he needs to sign the new CLA, to stop all the font packages he is the owner of getting orphaned. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive Package Maintainer - Jeroen van Meeuwen
Hi, Good to have you back! On 06/27/2011 01:53 PM, Jeroen van Meeuwen wrote: Vít Ondruch wrote: I'm following the procedure at: http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers Does anyone know how to contact Jeroen van Meeuwen? He is not answering e-mails at his listed address or the following Bugzilla reports: https://bugzilla.redhat.com/show_bug.cgi?id=707934 https://bugzilla.redhat.com/show_bug.cgi?id=707937 There is also many other Jeroen's packages which would need some maintenance. Boo. Hmm, not really helpful, and I'm also not sure if this falls under be excellent to each other Perhaps you coulb so kind as to respond to the request others have made to become co-maintainers of your packages? Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Poll: Does ACPI lid state work on your Linux laptop?
Hi, On 07/13/2011 04:11 PM, Adam Jackson wrote: On Wed, 2011-07-13 at 15:22 +0300, Pasi Kärkkäinen wrote: On Tue, Jul 12, 2011 at 10:01:25PM +0100, Matthew Garrett wrote: Please don't. ACPI lid state is not reliable on a range of hardware for a bunch of reasons, ranging from open events that are never fired to query methods that read from the wrong register. We can't pay attention to it by default, and running a survey doesn't change that. Ok. Do you know if there are other (better working) methods to get the lid state info? If we knew of any, they'd be implemented in the kernel, and we'd be using them. I know this is a frustrating thing to hear, and I empathize, I really do. But the state of the art right now is that there's one interface for laptop lids, it's in ACPI, and it's not reliable. Once upon a time there was an effort to make a Linux-based test kit for firmware [1], so vendors could run it before releasing hardware and verify that the Linux interfaces function. Lid state and lid events could have been one such test case. Sadly the effort seems to have stagnated; it could really use a revival. But even such a test kit would only fix new hardware, existing machines will continue to be as broken as they currently are forever. Maybe it it is an idea to build a whitelist for machines which do have working ACPI lid support? I realize maintaining such a list is a pain, but this way people who care and are lucky enough to have actually working hardware can at least use this ? Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Poll: Does ACPI lid state work on your Linux laptop?
Hi, On 07/13/2011 07:47 PM, Adam Williamson wrote: On Wed, 2011-07-13 at 11:35 -0400, Adam Jackson wrote: On Wed, 2011-07-13 at 16:57 +0200, Hans de Goede wrote: Maybe it it is an idea to build a whitelist for machines which do have working ACPI lid support? I realize maintaining such a list is a pain, but this way people who care and are lucky enough to have actually working hardware can at least use this ? It's an idea, but not one I'd do. Either a whitelist or a blacklist would be oppressively large. I suppose a whitelist has the advantage that it can't hurt anything compared to the current state, and no matter how short it is, it benefits *some* people. Yeah, that is my main reason for suggesting this, thanks for wording it so eloquently for me :) Note I'm not volunteering to do the work -ENOTIME. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
orphaning / looking for new owner for monkey-bubble
Hi, I've been thinking about orphaning monkey-bubble for a while now, mostly because it is dead upstream and it is using various obsolete gnome technologies (esound, libgnomeui, bonobo). Yesterday it came to my attention that monkey-bubble also contains at least 1 sound sample which we should not be re-distributing, as well as various sound samples from unclear origin. This has helped me make up my mind, and unless someone else jumps in to take it over (and fix the sound sample situation) I'm going to orphan it. So anyone want to take over monkey-bubble? Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Eliminating automatic provides on private libs
Hi, On 04/27/2012 10:13 AM, Panu Matilainen wrote: I started once again looking at ways to eliminate the unwanted provides on private libs such as dlopen()'ed modules with minimal fuss and breakage. Been down this route more than once but I suspect the last time was before the major dependency generator changes in rpm-4.9.x, which made tweaking these things a good deal easier, so time for another round: The short background is that for libraries which dont have a SONAME, rpmbuild fakes one based on the file name. The rationale for this has been that since the linker permits linking to libraries without sonames, rpm must permit this too. The downside is that for the 1% corner cases that need this, we end up polluting the provides namespace with thousands of unnecessary and unwanted names, names that have not been picked up with a global namespace in mind. To get a rough idea just how much of this unwanted junk exists, using a slightly modified elfdeps generator on my system: This is how we currently generate the provides: [root@localhost rpm]# find /lib64/ /usr/lib64/ -type f |./elfdeps -P --soname-only --fake-soname|wc -l 3875 And this is without faked soname provides: [root@localhost rpm]# find /lib64/ /usr/lib64/ -type f |./elfdeps -P --soname-only |wc -l 2816 So... about a third of the soname provides are faked by using library basename for its provide name, and almost all of them are for no good reason. The three general cases that something actually depends on are 1) libreoffice sub-packages depending on its internal libraries from libreoffice-core 2) a handful of packages depending on llvm libraries 3) bigger pile of packages depending on libperl.so Of these at least 2) does look like a bug really, and in fact has been fixed upstream: http://llvm.org/bugs/show_bug.cgi?id=12334. Dunno about 3), perl is... what it is. 1) might well classify as an inevitable special case (there will always be those), dunno. Obviously this is just a fairly small sample of the entire Fedora package set, there are bound to be many more special cases, buggy libraries which do not have SONAME when they should and stuff that falls into gray areas. I can try to provide more comprehensive stats based on current rawhide if needed. I'm going to add a switch to allow packages to control the behavior anyway. Whether rpm upstream defaults to the traditional behavior for compatibility reasons or not is another question, but Fedora is obviously free to override that. Given the packaging guideline mandate to eliminate private soname provides from packages it seems like a no-brainer to disable faked sonames by default, and require the handful of special cases to work around it (adding enable-switches to specs) instead of adding disable-switches to possibly hundreds of packages to cater for the special cases needs. Thoughts? This would obviously only change in rawhide. Great! Can we disable these bogus provides starting tomorrow please? :) Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Eliminating automatic provides on private libs
Hi, On 04/29/2012 05:13 PM, Panu Matilainen wrote: On 04/27/2012 07:36 PM, Toshio Kuratomi wrote: On Fri, Apr 27, 2012 at 11:13:47AM +0300, Panu Matilainen wrote: I'm going to add a switch to allow packages to control the behavior anyway. Whether rpm upstream defaults to the traditional behavior for compatibility reasons or not is another question, but Fedora is obviously free to override that. Given the packaging guideline mandate to eliminate private soname provides from packages it seems like a no-brainer to disable faked sonames by default, and require the handful of special cases to work around it (adding enable-switches to specs) instead of adding disable-switches to possibly hundreds of packages to cater for the special cases needs. Thoughts? This would obviously only change in rawhide. Oh and of course eliminating the faked soname provides does not eliminate all unwanted provides, eg libtool adds a soname even when -module is used. But ... you need to start someplace. Will the toggle to turn it on and off work for those libtool generated modules (as long as there's not public libraries in the same package)? Is it possible to turn this on and off per subpackage or is that along the lines of asking for pretty pink ponies with wings? For now, I'm only talking about a switch that stops faking a soname provide when an ELF DSO does not provide one, nothing more. Also that switch is going to be a global macro to avoid spec syntax compatibility issues, at least for now. As for the other issues like libtool generated modules, the question is: why does libtool insist on creating a soname for them, and could we get libtool changed not to do that? Also it might be possible to come up with heuristics to detect (some of) such modules based on the data in elf headers. If we go the heuristics way, why not do heuristics based on the location of the library? If the .so sits directly in a standard libdir it is likely something other packages can depend on / link against. If it sits in a subdir it is likely not. You can extend this heuristic by adding dirs found in $RPM_BUILD_ROOT/etc/ld.so.conf.d/*.conf to the standard libdirs before running this heuristic. This should give a pretty good score both wrt filtering out unwanted provides as well as not having any false positives. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: TnL
Hi, On 05/10/2012 03:26 PM, Jon Ciesla wrote: I recently updated Io-language to the current release. Finally. Anyway, TnL, which requires it, had been unable to run, at least for me, and now I can't even get it to build. So unless someone else wants to take a crack at it and fix it up, I'm going to retire it in a few days. I'll be happy to provide everything I've got to interested parties, but I can't spend any more time on it. As the guy who originally packages TnL I say just drop it, it is pretty much an unfinished game, and thus not very interesting. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Replacing libusb1 with libusbx
Hi All, I plan to replace libusb1 with libusbx, libusx is a fork of and a drop in replacement for libusb1. The libusbx fork was started by various libusb-1.0 developers (almost all of them *), because the official maintainer of libusb-1.0 refused to do any stable / tarbal releases for over 18 months and in general was very slow with merging new developments and fixes. Don't be fooled by the recently done libusb-1.0.9 release, that was done by the libusb-1.0 maintainer *after* the libusbx fork was announced and had already done 2 releases. The fact that this release only happened after the fork went public, despite various people including me asking for a release for ages (**) shows that forking was necessary. Anyways, I just included this tidbit to explain why I'm replacing libusb1 with libusbx for Fedora-18 and later. Lets not look backwards, but forwards towards what looks to be a bright future with libusbx :) A rename review request can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=823886 Reviews appreciated! Regards, Hans *) Full disclosure: I'm one of the libusb developers behind the fork **) I was originally promised a 1.0.9 release in time for inclusion into Fedora 16 gold! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing libusb1 with libusbx
Hi, On 05/22/2012 02:55 PM, Bastien Nocera wrote: On Tue, 2012-05-22 at 13:44 +0200, Hans de Goede wrote: Hi All, I plan to replace libusb1 with libusbx, libusx is a fork of and a drop in replacement for libusb1. The libusbx fork was started by various libusb-1.0 developers (almost all of them *), because the official maintainer of libusb-1.0 refused to do any stable / tarbal releases for over 18 months and in general was very slow with merging new developments and fixes. I'm guessing you're talking about Daniel Drake. Why didn't you ask him if you could get commit access instead? I took over libfprint and fprintd releases, and got them moved to freedesktop.org last year. No, Daniel handed it over to Peter Stuge about 18 months ago (give or take), and that didn't work out to well. I (and others) have tried pretty much every everything to avoid having to fork, but to no result. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Kernel 3.4 behaves weirdly with flash drives
Hi, On 06/19/2012 11:22 AM, Ankur Sinha wrote: Hi folks, In kernels 3.4 and 3.4.2, the kernel gets the size of my pen drives wrong: it thinks they're EB[1] in size, when they're actually only 4GB and 8GB. This issue is not present in the 3.3 kernel. I was wondering if any one else is facing the same issue? This is a known issue in the 3.4 kernel, a fix is being worked on upstream, see: http://permalink.gmane.org/gmane.linux.usb.general/65976 I think it is worth considering adding the proposed fix to the Fedora 3.4 kernels for now, as it seems a lot of people are bitten by this, and the proposed fix is pretty save. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 18
Hi, On 07/06/2012 10:55 PM, Bill Nottingham wrote: Package vorbisspi (fails to build) Fixed. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Vacation hansg July 13th - July 20th
Hi All, I'm going on vacation for a week starting tomorrow, and I will *not* be reading email, etc. during that time. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18
Hi, On 08/03/2012 11:27 AM, Nicolas Chauvet wrote: 2012/7/31 Bill Nottingham nott...@redhat.com: Before we branch for Fedora 18, as is custom, we will block currently orphaned packages and packages that have failed to build since Fedora 16. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. If no one claims any of these packages, they will be blocked before we branch for Fedora 18. We will block these packages on Monday, August 06. Note that if you're receiving this mail directly, it's because you are a co-maintainer of one of these packages. Please work with your comaintainers to take up maintenance. ... Package libcrystalhd (fails to build) comaintained by: kwizart Hi have a fix ready for primary arches, and finally succeeded to do runtime test with the hardware. Now I cannot fix it because I'm not really a co-maintainer yet as I'm still in the 'awating review' state https://admin.fedoraproject.org/pkgdb/acls/name/libcrystalhd The bugzilla where the FTBFS was discussed is here: https://bugzilla.redhat.com/show_bug.cgi?id=716154 What is the process I can follow to take over maintenance of the package ? If you can send me a git format-patch formatted patch for master (*), I can use my proven packager rights to at least fix it for now, that way it won't get blocked and you save a significant amount of work to get it unblocked later. Regards, Hans *) Or some other way I can make the changes without needing to think too much :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18
Hi, On 07/31/2012 07:11 PM, Bill Nottingham wrote: Before we branch for Fedora 18, as is custom, we will block currently orphaned packages and packages that have failed to build since Fedora 16. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. If no one claims any of these packages, they will be blocked before we branch for Fedora 18. We will block these packages on Monday, August 06. Note that if you're receiving this mail directly, it's because you are a co-maintainer of one of these packages. Please work with your comaintainers to take up maintenance. snip Package libhid (fails to build) I've fixed the FTBFS for libhid. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18
On 31 July 2012 18:11, Bill Nottingham nott...@redhat.com wrote: Package libcrystalhd (fails to build) Fixed (thanks to kwizard for providing the fix, I just committed it). Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
