Re: Intent to retire python-jinja
On Wed, Sep 25, 2013 at 5:58 AM, Thomas Moschny thomas.mosc...@gmail.com wrote: See https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Done Daniel -- 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: Intent to retire python-jinja
Hi, On Tue, Sep 17, 2013 at 11:10 AM, Thomas Moschny thomas.mosc...@gmail.com wrote: I'd like to retire the python-jinja package, containing the Jinja1 template engine, which has been superseded by Jinja2 for a very long time. Jinja2 is packaged as python-jinja2 in Fedora. However, there's one package left that depends on it: olpc-library. Can anyone comment on the status of that package, and if it would be possible to switch over to Jinja2? olpc-library just got obsoleted (nothing uses it now, the functionality got moved elsewhere), so if you could point me at how to drop this package from rawhide I will get it out of your way. Thanks Daniel -- 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: Graphics driver support in F21+
On Tue, Aug 27, 2013 at 9:30 AM, Peter Robinson pbrobin...@gmail.com wrote: xorg-x11-drv-geode geode is used on the OLPC XO-1 and is maintained by Daniel Drake (dsd) and he's basically done all recent commits for upstream releases and fixes unless it's been something like an ABI rebuild or similar. I'm sure he'll take over the maintainership if needed. Yes, I will take that one. Thanks for looking after it over the years. Daniel -- 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 OLPC OS 13.1.0
Hi, We're pleased to announce the release of OLPC OS 13.1.0 for XO-1, XO-1.5, XO-1.75 and XO-4. Details of new features, known issues, and how to download/install/upgrade can all be found in the release notes: http://wiki.laptop.org/go/Release_notes/13.1.0 Many thanks to all contributors, testers, upstreams, and those who have provided feedback of any kind. For those who were following the release candidate process in the last few months: candidate build 36 is released as final with no changes. Thanks! Daniel p.s. We're already knee-deep in development of the next release, 13.2.0. More info here: http://wiki.laptop.org/go/13.2.0 http://wiki.laptop.org/go/13.2.0/Release_plan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Network interface renaming, where does INTERFACE_NAME get applied?
Hi Bill
I see that initscripts in F18 ships this udev rule:
ACTION==add, SUBSYSTEM==net, PROGRAM=/lib/udev/rename_device,
RESULT==?*, ENV{INTERFACE_NAME}=$result
I'm trying to tackle some problems related to interface renaming, and
understanding how this works would be useful.
But I can't find which software component *applies* the INTERFACE_NAME
variable set by the above rule, actually performing the interface
rename. Can you explain?
FYI, I would imagine this area will also be susceptible to a current
udev bug, https://bugs.freedesktop.org/show_bug.cgi?id=56929
Thanks
Daniel
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: X touchscreen fixes for F18
On Sun, Oct 28, 2012 at 11:27 PM, Peter Hutterer peter.hutte...@who-t.net wrote: Can you file a bug for this please so we can keep track of it in case this breaks something? You almost certainly also want the fix to fdo #55738 http://lists.x.org/archives/xorg-devel/2012-October/034062.html Thanks, filed as https://bugzilla.redhat.com/show_bug.cgi?id=871064 Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
X touchscreen fixes for F18
Hi Peter, Would it be OK for me to add the following touchscreen input fixes to xorg-x11-server in F18 + rawhide? Sync TouchListener memory allocation with population in TouchSetupListeners() http://lists.x.org/archives/xorg-devel/2012-October/034149.html Xi: Don't check for TOUCH_END, it's never set http://cgit.freedesktop.org/xorg/xserver/commit/?id=3e6358ee6c33979329b78fe2097a1fdf76fb69cd At OLPC we have a big focus on touchscreens at the moment and the above patches are essential. I'd do all the testing and building and push as far as updates-testing. Thanks Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Announcing OLPC OS 12.1.0 for XO-1, XO-1.5 and XO-1.75
Hi, We're pleased to announce the release of OLPC OS 12.1.0 for XO-1, XO-1.5 and XO-1.75. Details of new features, known issues, and how to download/install/upgrade can all be found in the release notes: http://wiki.laptop.org/go/Release_notes/12.1.0 Many thanks to all contributors, testers, upstreams, and those who have provided feedback of any kind. For those who were following the release candidate process in the last few weeks: candidate build 21 is released as final with no changes. Thanks and enjoy! Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Announcing OLPC OS 12.1.0 for XO-1, XO-1.5 and XO-1.75
Hi Danishka, On Fri, Aug 31, 2012 at 10:28 AM, Danishka Navin danis...@gmail.com wrote: Hi Daniel, I would like to join for testing for the next release. How may I proceed? Great! We just posted our first F18 development build for the next release which will be called 13.1.0. I assume you have an XO with security disabled (i.e. you can reach the Ok prompt http://wiki.laptop.org/go/Ok ) Subscribe to the OLPC devel list: http://lists.laptop.org/listinfo/devel This is where we announce development versions. Here are instructions for downloading and installing the first 13.1.0 development release. http://wiki.laptop.org/go/13.1.0#Download_and_installation Feel free to ask for help either on this list or on the olpc devel list. When testing, you can send test reports by email to the OLPC devel list. If you have experience with a bug tracker you can also file bugs directly, see http://wiki.laptop.org/go/13.1.0#Bug_reports Thanks Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
DisplayManagerRework: how can a DM do plymouth internally?
Hi, I'm porting olpc-dm to F18 / https://fedoraproject.org/wiki/Features/DisplayManagerRework Thanks for the good documentation. The only detail that I'm unclear about is this one: # Add the following line only if the DM can do Plymouth internally Conflicts=plymouth-quit.service What does it mean for a DM to do plymouth internally ? Thanks Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
usrmove breaks on directory name conflict
Hi, Last week I tried a preupgrade from F16 to F17 beta. When rebooting into the preupgrade environment, the upgrade failed in usrmove: Make a copy of /mnt/sysimage/usr/bin Merge the copy with /mnt/sysimage/bin cp: cannot overwrite directory /mnt/sysimage/usr/bin.usrmove-new/mkdir with non-directory Something failed. Move back to the original state. Rebooted back into F16. It looks like the issue was that I had a directory at /usr/bin/mkdir/. No idea how, looks like it was from December. Probably my fault, but perhaps usrmove shouldn't fall over when facing this situation. After removing that weird directory, I rebooted into preupgrade and it worked fine. Now running F17 beta. Thanks, Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dracut waiting for background mdadm reconstruction to complete
On Thu, Dec 1, 2011 at 3:20 AM, Jes Sorensen jes.soren...@redhat.com wrote: Haven't noticed that one here - however when reporting RAID issues, please include details on the type of RAID you are using (regular Linux mdadm RAID, IMSM (BIOS RAID) etc.). Sorry for not specifying earlier - mdraid, raid 1 created with anaconda during F16 install. The behaviour is new - looks like this patch was only added to git a couple of weeks ago. Might be worth opening a BZ to track this. https://bugzilla.redhat.com/show_bug.cgi?id=759148 Thanks Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dracut waiting for background mdadm reconstruction to complete
On Wed, Nov 30, 2011 at 5:15 PM, Sam Varshavchik mr...@courier-mta.com wrote: Daniel Drake writes: My understanding is that this reconstruction is a background task, is there really a need for this to hold up boot? This behaviour comes from 0064-90mdraid-wait-for-md-devices-to-become-clean.patch in the dracut-013-19.fc16 package. What part dracut runs during boot? Not sure if I understand the question. Dracut runs mdadm -W for each mdraid device during every boot when the mdraid module is included in the initramfs. This is illustrated clearly in the patch in question: http://pkgs.fedoraproject.org/gitweb/?p=dracut.git;a=blob;f=0064-90mdraid-wait-for-md-devices-to-become-clean.patch;h=58c786cc5ca0b94fd138674c54417c29c38befc0;hb=refs/heads/f16 -W is documented to behave as follows: -W, --wait For each md device given, wait for any resync, recovery, or reshape activity to finish before returning. mdadm will return with success if it actually waited for every device listed, oth‐ erwise it will return failure. Thanks, Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
dracut waiting for background mdadm reconstruction to complete
Hi, Just installing Fedora 16 on a new system. We set up a RAID1 with mdadm for /. On boot, we're finding that if there is a RAID inconsistency, dracut is waiting for mdadm reconstruction to complete before booting the system. This means that after a power outage or other condition that would cause a reconstruction to become necessary, we have to wait several hours for the system to come online again. My understanding is that this reconstruction is a background task, is there really a need for this to hold up boot? This behaviour comes from 0064-90mdraid-wait-for-md-devices-to-become-clean.patch in the dracut-013-19.fc16 package. Thanks Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GNOME 3 - font point sizes now scaled?
Hi, I'm working on bringing OLPC up-to-date with all the great efforts with GNOME 3, systemd, etc. On the OLPC XO laptops we have quite a strange screen - it is small (152mm x 114mm) but very high resolution (1200x900 i.e. 201 dots per inch). Previously, on Fedora 14, we had to adjust the default GNOME font sizes since they didn't look right on the screen (I think they were too big). Now I'm looking at applying the same set of customisations to Fedora 16 since the default fonts are uncomfortably small on our display. However, I've noticed a fundamental difference in the sizing of fonts between Fedora 14 and Fedora 16. This is visible with a simple experiment: 1. Open gedit 2. Change document font size to Sans 72 3. Write the capital letter I and measure the height of the printed character with a ruler I do this on two laptops side by side, one running Fedora 14 and the other running Fedora 16. On F14 the height of the I character is 1.9cm, and on Fedora 16 it is 0.9cm. That is quite a difference. On both laptops, xdpyinfo correctly prints the screen resolution, DPI and display size, which have not changed. From a typographic standpoint, F14 seems to be correct here. As 1pt is (approx) 1/72 of an inch, size 72 should produce characters of around 1 inch in size - and 1.9cm (the F14 measurement) is about an inch. Also, Cantarell seems to play by its own rules. On F16, the I in Cantarell 72 is 0.8cm, not too different from Sans 72, but the difference between Sans 11 and Cantarell 11 is more significant - at size 11, Cantarell is tiny. Can anyone help me understand this behaviour? Thanks, Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 - font point sizes now scaled?
On Fri, Sep 30, 2011 at 12:09 PM, Felix Miata mrma...@earthlink.net wrote: Sounds to me like your F14 is using correct DPI while your F16 is forced to 96. Does your F14 have /etc/X11/xorg.conf file or a non-empty /etc/X11/xorg.conf.d/? Bad DPI could certainly be a cause. However, xdpyinfo reports the correct value (201) on both platforms. We use a config file in /etc/X11/xorg.conf.d which specifies DisplaySize - needed for the correct DPI value to be computed. Can you try opening Firefox 3.x with hidden (about:config) pref layout.css.dpi set to 0, and again set to 201, and loading http://fm.no-ip.com/Auth/dpi-screen-window.html to see what DPI it reports? Same in Konqueror? (other/newer browsers lock to 96). Sure, I'll try this. Do I run these tests on F14 or F16? (do you really mean Firefox 3.x?) cheers Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 - font point sizes now scaled?
On Fri, Sep 30, 2011 at 2:47 PM, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Someone Gnome-side decided to not trust xorg dpi and added a new heuristic to 'correct' it I know this is part of a rant.. but any chance you could quantify that point with a link to a commit, blog post, mailing list discussion, something like that? cheers Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 - font point sizes now scaled?
On Fri, Sep 30, 2011 at 6:05 PM, Jef Spaleta jspal...@gmail.com wrote: On Fri, Sep 30, 2011 at 8:47 AM, Tomasz Torcz to...@pipebreaker.pl wrote: Or http://svn.gnome.org/viewvc/gnome-settings-daemon/branches/gnome-2-24/plugins/xsettings/gsd-xsettings-manager.c?view=markup#249 (line 249)? I'm not sure that's relevant for the current codebase. But even so if you look at 73-75 the high and low reasonable limits don't seem unreasonable to me. And since the OLPC screen hardware being described is between the high/low reasonable limits in that particular bit of code you are pointing to, the fall back logic wouldn't fire so it couldn't be the cuase of the particular technical issue which started this thread. Jef, you're right, but Tomasz's link did send me in the right direction. Thanks! Here is the equivalent code of today: http://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/xsettings/gsd-xsettings-manager.c#n219 Discussion: https://bugzilla.gnome.org/show_bug.cgi?id=643704 Summary: GNOME hardcodes DPI to 96 regardless of X configuration. However, it now has a text scaling factor in gsettings that I was not aware of. So I guess I just need to find an appropriate factor that makes fonts look OK on the XO. cheers Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3 - font point sizes now scaled?
On Fri, Sep 30, 2011 at 11:30 PM, Daniel Drake d...@laptop.org wrote: However, it now has a text scaling factor in gsettings that I was not aware of. So I guess I just need to find an appropriate factor that makes fonts look OK on the XO. One problem faced here is that (as noted earlier) Cantarell behaves quite differently to Sans (DejaVu) in terms of scaling at different sizes, and the default setup mixes these 2 fonts. This problem gets amplified when applying large scale factors. So I settled for a scale factor of 2.1. This makes the document font and window title font (both Sans) look the correct size, but everything else (Cantarell) is uncomfortably large. Then I changed the default font from Cantarell to Sans and now everything looks fine. So my final override: [org.gnome.desktop.interface] cursor-size=48 text-scaling-factor=2.1 font-name='Sans 7' Thanks ! Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass Rebuild and Mass branching status update
On 11 February 2011 16:34, Dennis Gilmore den...@ausil.us wrote: yes you need to push them though bodhi. I'm having trouble here. olpc-powerd-31-1.fc15 is the version made before the rebuild olpc-powerd failed to compile in the rebuild due to using a gcc flag which no longer exists. (that was olpc-powerd-31-2) I fixed it as olpc-powerd-31-3 and built it on master for rawhide. Then I switch branch to f15 and try to build it and it says: Could not initiate build: olpc-powerd-31-3.fc15 has already been built So I tried to create an update in bodhi, but that fails: olpc-powerd-31-3.fc15 not tagged as an update candidate And I checked the existing F15 repository at http://mirror.netrino.co.uk/mirror.fedora.com/development/15/i386/os/Packages/ and I see that the current version included in F15 is olpc-powerd-31-1 (the pre-rebuild version). What am I missing? Thanks, Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
