systemd and filesystems with noauto
by Matthew Miller
I have a fstab entry like this:
/dev/sde1 /mnt/sdcard autonoexec,noauto,users,ro,sync,shortname=lower 0 0
which I use in a script to take pictures off my camera's SD card and
transfer them to my photo management system. I've been doing it this way for
a long time, and now with modern Linux I recognize that there's better ways
of doing it. But I was surprised when I updated this system to latest
rawhide and rebooted, because it came up with that filesystem mounted.
Is this expected behavior?
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
10 years, 7 months
Deactivating LVDS display when laptop lid is closed
by Orion Poplawski
Apparently[1] it is up to the desktop environment now to deactivate the LVDS
display if the laptop lid is closed at boot (or whenever?). I now have
several F13 laptops in docks with external monitors that boot with the lid
closed, but kdm_greet puts the login panel on the closed LVDS display (see
bug[2]). I've also filed a Fedora bug for similar stuff here [3]. I don't
know how gdm behaves.
Any other comments/help? I tried doing:
# Disable LVDS if another output is up
if xrandr --current | grep -qE '^(DVI|VGA).* connected'
then
lvds=$(xrandr --current | awk '$1 ~ /LVDS/ { print $1 }')
xrandr --output $lvds --off
fi
in /etc/kde/kdm/Xsetup, but kdm_greet appears to get stuck in an infinite loop
and I only see the small round black spinner cursor, never the login panel.
I thought about posting to the Fedora KDE list, but I'd like to get some wider
input.
1 - https://bugs.freedesktop.org/show_bug.cgi?id=28936
2 - https://bugs.kde.org/show_bug.cgi?id=243807
3 - https://bugzilla.redhat.com/show_bug.cgi?id=539180
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
10 years, 7 months
fedpkg prep
by Steve Dickson
Just curious....
Why does 'fedpkg prep' care that the repo is in an inconsistent state?
I just did a rebase to the latest f14 code on a private branch.
So yes he repo in an inconsistent but that is ok. I'm going to
make some changes to put it back in a consistent state but
I can not do that without a source tree.
So is there a way to do what the old 'make prep' did? That is
stupidity untar the tarball an apply all the current patch
without checking any state??
tia,
steved.
10 years, 7 months
Starting Java SIG
by Stanislav Ochotnicky
Hi everyone,
There has been an effort few years back to start Java SIG but it didn't
work out in the end (no idea why). I decided it's time to try again :-)
I would like to start Java SIG for a lot of reasons. Some of them:
* Packaging guidelines are in need of an update (badly)
* Consistency in java packages is somewhat lacking
* More eyes see more approach, I'd like for all java related commits to
go through an alias so we can all watch out for changes that can
break our stuff
* Have a place where we can collect tips & tricks, solutions to common
problems etc. Currently this information is scattered through
people's wiki pages
* Java needs collaboration more than most other areas, because problems
cannot be safely discovered automatically when someone changes
dependency. This can cause serious headaches (to me at least). Java
SIG to the rescue! :-)
* Other languages have their own SIGs and we don't! :-)
Who am I?
Owner/Co-maintainer of a bunch of Java packages (mostly maven plugins,
apache-commons, junit, velocity, checkstyle, plexus
libraries). Involved in recent update of maven to v2.2.1.
Reply if you're interested with helping out and being able to
see/influence where Java packaging in Fedora is going. I know there will
be at least a few people joining in.
I'll be starting Java SIG wiki page soon, plus I guess we can peruse
java-devel mailing list for SIG discussions.
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Associate Software Engineer - Base Operating Systems Brno
PGP: 71A1677C
Red Hat Inc. http://cz.redhat.com
10 years, 7 months
yum appmarket
by Seth Vidal
I mentioned this on:
http://skvidal.wordpress.com/2010/08/19/fedora-app-market-proof-of-concept/
last night but I thought I'd bring it up here:
Yesterday someone was talking about installing apps in fedora and how it
was hard to figure out what to install/try b/c there were too much STUFF
in fedora. They suggested an ‘app store’ like functionality. I explained
that all the resources to do something like that exist in the
infrastructure yum and friends offer now. I decided to prove that
concept a bit.
The concept of an ‘app’ is pretty amorphous but I decided to just use
what Colin Walters said was his definition of an ‘app’ – which is any
pkg containing a .desktop file. So I just whipped up a simple tool to
dump out an xml-file of a format yum is already familiar with based on
that criteria:
http://skvidal.fedorapeople.org/misc/appfinder.py
Running that generates an xml file with only the ‘apps’ defined.
Great. Then I wrote a yum plugin to access and use this data.
and I stuck it in this repo
1. copy this file into /etc/yum.repos.d/
2. run: yum install yum-plugin-appmarket
Now yum will have a few new commands available to it:
app-install Install an App
app-list List Apps
app-remove Remove an App
app-search Search for an App
Some examples:
yum app-search yum
won’t turn up ‘yum’ but it will turn up ‘yumex’.
Fancy, huh?
Now, the concept of an app can be refined in many ways but this is just
to prove that the infrastructure has been available.
-sv
10 years, 7 months
Fedora Notifications System.
by Mahmoud Abdul Jawad
Hi all,,
before two weeks, a discussion started in ambassadors mailing-list about a
work around to deliver the important notifications to the fedora desktop
(whatever the desktop is).
after some discussion, we started with some guide lines & putted them on the
wiki:
https://fedoraproject.org/wiki/Fedora_notifications_system
Continuing, I created an early prototype i want people to check & gives
feedbacks about it.
you can reach it through gitweb:
http://fedorapeople.org/gitweb?p=megenius/public_git/fns.git;a=summary
or, you can grab your own clone from the git repo:
git://fedorapeople.org/megenius/fns.git
keep in mind that last_check file should be writeable by the world, & you
should change its value to an earlier date, so you can see some
notifications.
--
Regards,,
Mahmoud Abdul Jawad
@meGenius
10 years, 7 months
clutter -> 1.3
by Colin Walters
Heads up to Clutter consumers - I'm updating it in f15 to the 1.3
(master) branch. I've tested GNOME Shell and quadrapassel, feel free
to CC me for other fallout.
10 years, 7 months
Nautilus misbehaving
by Paul F. Johnson
Hi,
After the recent rawhide to nautilus 2.90.1-1.fc15.i686, it's stopped
working claiming that I don't have Settings schema
'org.gnome.desktop.lockdown' installed.
What is this and how do I fix the problem?
TTFN
Paul
10 years, 7 months
Re: [kernel/f14/master] add in patch from lmacken to support more mac models with efifb
by Luke Macken
Thanks for taking care of this, Kyle.
Should I send this patch upstream? if so, 1 patch per hardware?
do/should I get sign-off's?
Thanks,
luke
On 08/31/2010 05:23 PM, Kyle McMartin wrote:
> commit 3c5d4de07ca16d799f1ca63454b56a03456191fe
> Author: Kyle McMartin<kyle(a)dreadnought.i.jkkm.org>
> Date: Tue Aug 31 17:23:33 2010 -0400
>
> add in patch from lmacken to support more mac models with efifb
>
> efifb-add-more-models.patch | 59 +++++++++++++++++++++++++++++++++++++++++++
> kernel.spec | 10 ++++++-
> 2 files changed, 68 insertions(+), 1 deletions(-)
> ---
> diff --git a/efifb-add-more-models.patch b/efifb-add-more-models.patch
> new file mode 100644
> index 0000000..3351970
> --- /dev/null
> +++ b/efifb-add-more-models.patch
> @@ -0,0 +1,59 @@
> +--- vanilla-2.6.35.3.orig/drivers/video/efifb.c
> ++++ vanilla-2.6.35.3/drivers/video/efifb.c
> +@@ -39,7 +39,11 @@ enum {
> + M_I20, /* 20-Inch iMac */
> + M_I20_SR, /* 20-Inch iMac (Santa Rosa) */
> + M_I24, /* 24-Inch iMac */
> ++ M_I24_8_1, /* 24-Inch iMac, 8,1th gen */
> ++ M_I24_10_1, /* 24-Inch iMac, 10,1th gen */
> + M_MINI, /* Mac Mini */
> ++ M_MINI_3_1, /* Mac Mini, 3,1th gen */
> ++ M_MINI_4_1, /* Mac Mini, 4,1th gen */
> + M_MB, /* MacBook */
> + M_MB_2, /* MacBook, 2nd rev. */
> + M_MB_3, /* MacBook, 3rd rev. */
> +@@ -47,6 +51,7 @@ enum {
> + M_MBA, /* MacBook Air */
> + M_MBP, /* MacBook Pro */
> + M_MBP_2, /* MacBook Pro 2nd gen */
> ++ M_MBP_2_2, /* MacBook Pro 2,2nd gen */
> + M_MBP_SR, /* MacBook Pro (Santa Rosa) */
> + M_MBP_4, /* MacBook Pro, 4th gen */
> + M_MBP_5_1, /* MacBook Pro, 5,1th gen */
> +@@ -64,11 +69,16 @@ static struct efifb_dmi_info {
> + [M_I20] = { "i20", 0x80010000, 1728 * 4, 1680, 1050 }, /* guess */
> + [M_I20_SR] = { "imac7", 0x40010000, 1728 * 4, 1680, 1050 },
> + [M_I24] = { "i24", 0x80010000, 2048 * 4, 1920, 1200 }, /* guess */
> ++ [M_I24_8_1] = { "imac8", 0xc0060000, 2048 * 4, 1920, 1200 },
> ++ [M_I24_10_1] = { "imac10", 0xc0010000, 2048 * 4, 1920, 1080 },
> + [M_MINI]= { "mini", 0x80000000, 2048 * 4, 1024, 768 },
> ++ [M_MINI_3_1]= { "mini31", 0x40010000, 1024 * 4, 1024, 768 },
> ++ [M_MINI_4_1]= { "mini41", 0xc0010000, 2048 * 4, 1920, 1200 },
> + [M_MB] = { "macbook", 0x80000000, 2048 * 4, 1280, 800 },
> + [M_MBA] = { "mba", 0x80000000, 2048 * 4, 1280, 800 },
> + [M_MBP] = { "mbp", 0x80010000, 1472 * 4, 1440, 900 },
> + [M_MBP_2] = { "mbp2", 0, 0, 0, 0 }, /* placeholder */
> ++ [M_MBP_2_2] = { "mbp22", 0x80010000, 1472 * 4, 1440, 900 },
> + [M_MBP_SR] = { "mbp3", 0x80030000, 2048 * 4, 1440, 900 },
> + [M_MBP_4] = { "mbp4", 0xc0060000, 2048 * 4, 1920, 1200 },
> + [M_MBP_5_1] = { "mbp51", 0xc0010000, 2048 * 4, 1440, 900 },
> +@@ -92,7 +102,11 @@ static struct dmi_system_id __initdata d
> + EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "iMac6,1", M_I24),
> + EFIFB_DMI_SYSTEM_ID("Apple Inc.", "iMac6,1", M_I24),
> + EFIFB_DMI_SYSTEM_ID("Apple Inc.", "iMac7,1", M_I20_SR),
> ++ EFIFB_DMI_SYSTEM_ID("Apple Inc.", "iMac8,1", M_I24_8_1),
> ++ EFIFB_DMI_SYSTEM_ID("Apple Inc.", "iMac10,1", M_I24_10_1),
> + EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "Macmini1,1", M_MINI),
> ++ EFIFB_DMI_SYSTEM_ID("Apple Inc.", "Macmini3,1", M_MINI_3_1),
> ++ EFIFB_DMI_SYSTEM_ID("Apple Inc.", "Macmini4,1", M_MINI_4_1),
> + EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "MacBook1,1", M_MB),
> + /* At least one of these two will be right; maybe both? */
> + EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "MacBook2,1", M_MB),
> +@@ -104,6 +118,7 @@ static struct dmi_system_id __initdata d
> + EFIFB_DMI_SYSTEM_ID("Apple Inc.", "MacBookAir1,1", M_MBA),
> + EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "MacBookPro1,1", M_MBP),
> + EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "MacBookPro2,1", M_MBP_2),
> ++ EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "MacBookPro2,2", M_MBP_2_2),
> + EFIFB_DMI_SYSTEM_ID("Apple Inc.", "MacBookPro2,1", M_MBP_2),
> + EFIFB_DMI_SYSTEM_ID("Apple Computer, Inc.", "MacBookPro3,1", M_MBP_SR),
> + EFIFB_DMI_SYSTEM_ID("Apple Inc.", "MacBookPro3,1", M_MBP_SR),
> diff --git a/kernel.spec b/kernel.spec
> index d5c3638..77630ec 100644
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -48,7 +48,7 @@ Summary: The Linux kernel
> # reset this by hand to 1 (or to 0 and then use rpmdev-bumpspec).
> # scripts/rebase.sh should be made to do that for you, actually.
> #
> -%global baserelease 13
> +%global baserelease 14
> %global fedora_build %{baserelease}
>
> # base_sublevel is the kernel version we're starting with and patching
> @@ -663,6 +663,8 @@ Patch1824: drm-intel-next.patch
> Patch1825: drm-intel-make-lvds-work.patch
> Patch1900: linux-2.6-intel-iommu-igfx.patch
>
> +Patch2000: efifb-add-more-models.patch
> +
> # linux1394 git patches
> Patch2200: linux-2.6-firewire-git-update.patch
> Patch2201: linux-2.6-firewire-git-pending.patch
> @@ -1262,6 +1264,8 @@ ApplyOptionalPatch drm-intel-next.patch
> ApplyPatch drm-intel-make-lvds-work.patch
> ApplyPatch linux-2.6-intel-iommu-igfx.patch
>
> +ApplyPatch efifb-add-more-models.patch
> +
> # linux1394 git patches
> #ApplyPatch linux-2.6-firewire-git-update.patch
> #ApplyOptionalPatch linux-2.6-firewire-git-pending.patch
> @@ -1892,6 +1896,10 @@ fi
> # and build.
>
> %changelog
> +* Tue Aug 31 2010 Kyle McMartin<kyle(a)redhat.com> 2.6.35.4-14
> +- efifb-add-more-models.patch: Add patch from Luke Macken to
> + support more Mac models (rhbz#528232)
> +
> * Tue Aug 31 2010 Dave Jones<davej(a)redhat.com> 2.6.35.4-13
> - Fix incorrect DMA size freeing error in via-velocity.
>
10 years, 7 months