Re: Building mono-2.8 for 64 bit - possible solution to the problem
Hi, > Hmm. I did a build with: > mock -r fedora-rawhide-x86_64 mono-2.8-1.1.fc15.src.rpm > on an f13/x86-64 host and it finished without complaint. Removed the m32 hacks and submitted for a rebuild. Still dies in the same place :( > Perhaps something is indeed wonky in koji, or maybe some prerequisite just > got broken and fixed since. You should try just resubmitting the package > build. It looks like glibc is missing TLS support. Do I submit a BZ against glibc? Paul -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building mono-2.8 for 64 bit - possible solution to the problem
> It looks like glibc is missing TLS support. Do I submit a BZ against > glibc? That is simply not the case and it's hard to see how you came to such a conclusion. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: trademarks [was: xulrunner 2.0 in rawhide (F15) bundles several system libs]
On Wed, Oct 13, 2010 at 6:11 PM, Kevin Kofler wrote: > Brandon Lozza wrote: >> I think an exception should be made for Chromium too. > > No. Just no. > > The exceptions for Firefox need to stop NOW, i.e. no new ones should be > granted and the ones that have already been granted repealed/discontinued. > Giving yet another package a free pass is going in the entirely wrong > direction. > > (That said, I really don't see why Firefox gets a free pass while Chromium > doesn't.) > >> Having a more secure browser would benefit the main repositories. > > We already have Konqueror which is more secure than either Firefox or > Chromium. (There have been much fewer security vulnerabilities in KHTML than > either Gecko or WebKit. All the WebKit issues have been checked for > reproducibility in KHTML and most weren't reproducible.) > > Kevin Kofler > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel Perhaps the Upstream we should be working with instead should be Debian (Iceweasel)? I'm compiling Iceweasel right now and i'm going to attempt to plug it into the system xulrunner, lol. It's the same version anyways so I don't see why the branding being changed will introduce new bugs and I'm not using debians security patches. I'll update on this and if it works i'll look into modifying the firefox spec to use this instead. However i'm kind of a noob at packaging and probably can't maintain this forever. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: docbook and glibc breakage [STILL BREAKING EVERYTHING]
Kevin Kofler writes: > POSIXLY_CORRECT has a lot of other effects which will break tons of > packages, e.g. it disables all bash extensions! Not all of them, only those that conflict with POSIX (which still leaves a lot room for extensions). Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging dwm
On Wed, Oct 13, 2010 at 09:34:22PM -0400, Matt McCutchen wrote: > On Thu, 2010-10-14 at 01:48 +0200, Kevin Kofler wrote: > > Petr Sabata wrote: > > > I've been thinking about packaging dwm [1] since we already ship dmenu and > > > dzen2. I wonder if anybody would be interested in this fine window manager > > > (except for me). > > > > I think it's completely unreasonable to package that software, because of > > this: > > > > > The problem here: dwm is configured solely in C and has to be recompiled > > > every time a user wants to change their settings (appearance, behavior, > > > shortcuts, etc). In my opinion, we could do it like this: > > > > > > - install a Fedora preconfigured version along with dwm sources > > > - copy its configuration (C header file) to some fixed location for > > > user to customize > > > - provide a script to recompile dwm locally using the local > > > configuration file > > > > Such a program is basically not packagable. > > It can't be packaged in the sense of shipping binaries. But if a > wrapper script is provided that automatically recompiles dwm for the > individual user whenever necessary, the software could be packaged in > the sense that it could be installed and updated with yum and would be > functional without user intervention. The latter is my definition of > "packageable". Compare to the akmods offered by RPM Fusion. I suppose rebuilding for every individual user would also be possible. I guess the best way to do that without any user intervention would be to rebuild every time a user's X session is started -- it's so small one would hardly notice it. I created this draft based on my yesterdays email: http://psabata.fedorapeople.org/dwm/dwm-5.8.2-1.fc13.src.rpm However, there are some limitations when compared to your approach: 1. One has to manually call dwm-reconfigure to rebuild dwm with their configuration 2. All users in the system share the same settings (this is worse) So, the new idea: package dwm: - installs binaries with default configuration only - depends on dmenu and xterm package dwm-user (or whatever): - installs dwm sources and a "dwm-start" script which: - checks for, say, ~/.dwm.config.def.h; runs default dwm if it's not present, or recompiles dwm in ~/.dwm with the user configuration and runs it if the config's there (and possibly has changed since the last time) - depends on dwm, gcc, make and Xlib-devel Petr > > -- > Matt > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Petr 'contyk' Sabata, Red Hat, Brno () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments pgpq3KOhPoZaG.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Something similar to http://susestudio.com/
Well there was http://thincrust.net, but that seems to be dead-ish: last commit in git master dates back to September '09. Thincrust aimed to build commandline tools to create appliances. Basically you could see it as susestudio.com in a commandline fashion. Thincrust's appliance-tools package is still in Fedora 14, but apart from that there is little else. Maybe Novell could open source susestudio.com. That would be nice :) Regards, Maxim Burgerhout ma...@wzzrd.com GPG Fingerprint EB11 5E56 E648 9D99 E8EF 05FB C513 6FD4 1302 B48A On Tue, Oct 12, 2010 at 20:24, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > Subject. > Have Fedora/RHEL service similar http://susestudio.com/ ? May be plans > to create it? > > Just for information. > -- > With best wishes, Pavel Alexeev aka Pahan-Hubbitus. For fast contact > with me you could use Jabber: hubbi...@jabber.ru > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Something similar to http://susestudio.com/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/10/10 09:25, Maxim Burgerhout wrote: > Well there was http://thincrust.net, but that seems to be dead-ish: > last commit in git master dates back to September '09. Thincrust aimed > to build commandline tools to create appliances. Basically you could > see it as susestudio.com in a commandline fashion. Thincrust's > appliance-tools package is still in Fedora 14, but apart from that > there is little else. > > Maybe Novell could open source susestudio.com. That would be nice :) This is something I also looked into, and found that there is something on the horizon, but I know I am not allowed to discuss it yet until the official release. The other option is looking @ projects like:- http://www.jboss.org/boxgrinder and also http://www.rpath.org/ I have used the Thincrust stuff and it does indeed still work in F13. - -- Gavin Spurgeon. gspurg...@redhat.com Red Hat GLS Instructor EMEA Red Hat UK Ltd 64 Baker Street 4th Floor, London, W1U 7DF Mob:+44 7841 231160 Desk: +44 0207 009 4429 (Direct) Tel:+44 1252 362709 Fax:+44 1252 548116 Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAky228AACgkQvp6arS3vDioDGgCfbNc54cvXXI04Qs9a9YXfc3en 4KQAnjPoD8quEL7PTwHjDLetKubjJ7Ys =hnFi -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging dwm
Matt McCutchen wrote: > It can't be packaged in the sense of shipping binaries. But if a > wrapper script is provided that automatically recompiles dwm for the > individual user whenever necessary, the software could be packaged in > the sense that it could be installed and updated with yum and would be > functional without user intervention. The latter is my definition of > "packageable". Compare to the akmods offered by RPM Fusion. Akmods are a horribly ugly hack which is a very bad example to follow. (In fact, I strongly recommend against using akmods, the binary kmods follow packaging best practices much more.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging dwm
On 10/13/2010 10:04 AM, Petr Sabata wrote: > I've been thinking about packaging dwm [1] since we already ship dmenu and > dzen2. I wonder if anybody would be interested in this fine window manager > (except for me). > > The problem here: dwm is configured solely in C and has to be recompiled > every time a user wants to change their settings (appearance, behavior, > shortcuts, etc). In my opinion, we could do it like this: > > - install a Fedora preconfigured version along with dwm sources > - copy its configuration (C header file) to some fixed location for > user to customize > - provide a script to recompile dwm locally using the local > configuration file It doesn't make any sense at all to have a system-wide preconfigured version installed. Surely the RPM should simply install the sources, along with a script that the user can run to copy the config files to the user's homedir and build dwm. The user would then have their own private copy of dwm. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packaging dwm
On 10/14/2010 01:13 AM, Jesse Keating wrote: > On 10/13/2010 02:04 AM, Petr Sabata wrote: >> The problem here: dwm is configured solely in C and has to be recompiled >> every time a user wants to change their settings (appearance, behavior, >> shortcuts, etc). > > Am i the only one that finds it hilarious that this thing is named > "Dynamic Window Manager"? So dynamic, you gotta recompile to change > anything I dunno, it sounds a lot easier than reconfiguring some window managers! ;-) Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
Kevin Kofler wrote on 14.10.2010 00:36: > Thorsten Leemhuis wrote: >> * Why haven't those that want iceweasel and icedove in Fedora not >> simply invested some time and got them integrated into the repository?(¹) > Because having both Iceweasel and Firefox in the repository, in addition to > being stupid by itself, would also mean shipping 2 different versions of > xulrunner (because there's where most of the offending patches live). If you run a 's/, in addition to being stupid by itself,//' over that: Yes, sure. > And besides, it's not that we want Iceweasel, it's that we DO NOT WANT > Firefox since it does not follow Fedora policies. As it's obvious from the discussion: There are other "we" in Fedora that think having Firefox is wise. Please note that I actually don't feel myself as being a part of either "we" here. Both sides afaics have good points. The main reason why I raised my voice: I don't see a real reason why Fedora has to pick a position for the repository (see next para) > Having both would not actually solve any problem. I tend to disagree, as including both Iceweasel and Icedove in addition to Firefox and Thunderbird gives users, admins and especially those that maintain a remix the option to easily chose the solution that suites their needs best. Cu knurd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ethtool not in default system anymore?
Jiri Popelka writes: > I'm not sure. We are trying to eventually get net-tools out of the > default install. > Most of the scripts (initscripts/networking) has been using iproute commands > now and we're trying to navigate people to switch to ip as well. Maybe it would be worth attacking vconfig -> ip link add as well? >From a quick look, all that needs fixing are these 2 lines in fcoe-utils /usr/libexec/fcoe/fcoe-setup.sh vconfig set_name_type DEV_PLUS_VID_NO_PAD vconfig add $ifname $vlan > /dev/null which I believe could be replaced with: ip link add link $ifname name $ifname.$vlan type vlan id $vlan /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Tuesday 12 October 2010 21:28:24 Evan Dandrea wrote: > You absolutely can automate it, using the same preseeding mechanism found > in debian-installer. Thanks for the info. Didn't know Debian preseeding can be used with the Ubuntu live installer as well. That boosts usability to another level when installing on more than one computer is desired and other techniques aren't feasible. Lars. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101014 changes
Compose started at Thu Oct 14 08:15:49 UTC 2010 Broken deps for x86_64 -- clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) < 0:1.3.0 clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) < 0:1.3.0 dreampie-python3-1.1-5.fc14.noarch requires python(abi) = 0:3.1 empathy-2.32.0-1.fc15.x86_64 requires libcamel-1.2.so.19()(64bit) evolution-couchdb-0.5.0-1.fc15.x86_64 requires libcamel-provider-1.2.so.19()(64bit) evolution-couchdb-0.5.0-1.fc15.x86_64 requires libcamel-1.2.so.19()(64bit) 1:gedit-devel-2.91.0-4.fc15.i686 requires gtksourceview2-devel >= 0:2.91 1:gedit-devel-2.91.0-4.fc15.x86_64 requires gtksourceview2-devel >= 0:2.91 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-pilot-eds-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.32.0-1.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evince-2.32.0-1.fc14.x86_64 requires libevview.so.3()(64bit) gnome-python2-evolution-2.32.0-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gnome-python2-totem-2.32.0-1.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.2.0-3.fc14.x86_64 requires libchamplain-gtk-0.6.so.0()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) jana-0.4.5-0.10.20100520gitacd72f2.fc15.i686 requires libcamel-1.2.so.19 jana-0.4.5-0.10.20100520gitacd72f2.fc15.x86_64 requires libcamel-1.2.so.19()(64bit) moblin-panel-people-0.1.14-1.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libsocialweb-client.so.1()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) moblin-panel-status-0.1.21-6.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) rakudo-0.0.2010.08_2.7.0-1.fc14.x86_64 requires libparrot.so.2.7.0()(64bit) stardict-3.0.1-21.fc13.x86_64 requires libgucharmap.so.7()(64bit) 1:syncevolution-libs-1.0.99.7-1.fc15.i686 requires libcamel-1.2.so.19 1:syncevolution-libs-1.0.99.7-1.fc15.x86_64 requires libcamel-1.2.so.19()(64bit) totem-2.90.5-5.fc15.i686 requires libpeasui-1.0.so.0 totem-2.90.5-5.fc15.x86_64 requires libpeasui-1.0.so.0()(64bit) Broken deps for i386 -- clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) < 0:1.3.0 dreampie-python3-1.1-5.fc14.noarch requires python(abi) = 0:3.1 empathy-2.32.0-1.fc15.i686 requires libcamel-1.2.so.19 evolution-couchdb-0.5.0-1.fc15.i686 requires libcamel-1.2.so.19 evolution-couchdb-0.5.0-1.fc15.i686 requires libcamel-provider-1.2.so.19 1:gedit-devel-2.91.0-4.fc15.i686 requires gtksourceview2-devel >= 0:2.91 1:gnome-games-extra-2.31.91.1-1.fc15.i686 requires libclutter-gtk-0.10.so.0 gnome-pilot-eds-2.32.0-1.fc14.i686 requires libcamel-1.2.so.19 gnome-python2-brasero-2.32.0-1.fc14.i686 requires libbrasero-burn.so.1 gnome-python2-brasero-2.32.0-1.fc14.i686 requires libbrasero-media.so.1 gnome-python2-evince-2.32.0-1.fc14.i686 requires libevdocument.so.3 gnome-python2-evince-2.32.0-1.fc14.i686 requires libevview.so.3 gnome-python2-evolution-2.32.0-1.fc14.i686 requires libcamel-1.2.so.19 gnome-python2-totem-2.32.0-1.fc14.i686 requires libgnome-media-profiles.so.0 gpx-viewer-0.2.0-3.fc14.i686 requires libclutter-gtk-0.10.so.0 gpx-viewer-0.2.0-3.fc14.i686 requires libchamplain-0.6.so.0 gpx-viewer-0.2.0-3.fc14.i686 requires libchamplain-gtk-0.6.so.0 hornsey-1.5.2-0.3.fc15.i686 requires libclutter-gtk-0.10.so.0 jana-0.4.5-0.10.20100520gitacd72f2.fc15.i686 requires libcamel-1.2.so.19 moblin-panel-people-0.1.14-1.fc14.i686 requires libcamel-1.2.so.19 moblin-panel-status-0.1.21-6.fc14.i686 requires libsocialweb-client.so.1 moblin-panel-status-0.1.21-6.fc14.i686 requires libclutter-gtk-0.10.so.0 moblin-panel-status-0.1.21-6.fc14.i686 requires libchamplain-0.6.so.0 qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 rakudo-0.0.2010.08_2.7.0-1.fc14.i686 requires libparrot.so.2.7.0 stardict-3.0.1-21.fc13.i686 requires libgucharmap.so.7 1:syncevolution-libs-1.0.99.7-1.fc15.i686 require
Re: Packaging dwm
On Thu, Oct 14, 2010 at 10:18:07AM +0200, Petr Sabata wrote: > > It can't be packaged in the sense of shipping binaries. But if a > > wrapper script is provided that automatically recompiles dwm for the > > individual user whenever necessary, the software could be packaged in > > the sense that it could be installed and updated with yum and would be > > functional without user intervention. The latter is my definition of > > "packageable". Compare to the akmods offered by RPM Fusion. > > I suppose rebuilding for every individual user would also be possible. I guess > the best way to do that without any user intervention would be to rebuild > every > time a user's X session is started -- it's so small one would hardly notice > it. > > I created this draft based on my yesterdays email: > http://psabata.fedorapeople.org/dwm/dwm-5.8.2-1.fc13.src.rpm > > However, there are some limitations when compared to your approach: > 1. One has to manually call dwm-reconfigure to rebuild dwm with their >configuration > 2. All users in the system share the same settings (this is worse) > > So, the new idea: > > package dwm: > - installs binaries with default configuration only > - depends on dmenu and xterm > package dwm-user (or whatever): > - installs dwm sources and a "dwm-start" script which: > - checks for, say, ~/.dwm.config.def.h; > runs default dwm if it's not present, or > recompiles dwm in ~/.dwm with the user configuration and runs it > if the config's there (and possibly has changed since the last > time) > - depends on dwm, gcc, make and Xlib-devel > Ok, here it is: http://psabata.fedorapeople.org/packages/dwm/dwm-5.8.2-1.fc13.src.rpm Comments welcome. Petr > Petr > > > > -- > > Matt > > > > -- > > devel mailing list > > devel@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/devel > > -- > Petr 'contyk' Sabata, Red Hat, Brno > > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- Petr 'contyk' Sabata, Red Hat, Brno () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments pgpxYWh3axIf1.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 640752] Broken dependency: perl-Test-Simple-tests-0.94-2.fc14.noarch requires perl-Test-Simple = 0:0.94-2.fc14
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=640752 James Laska changed: What|Removed |Added Status Whiteboard|repoclosure_hash:2585e5f1e7 |AcceptedNTH |5c833fd80c9c9a0512da267b7d2 |repoclosure_hash:2585e5f1e7 |b68a0c6d7a5954aa3536db1a2e8 |5c833fd80c9c9a0512da267b7d2 |AcceptedNTH |b68a0c6d7a5954aa3536db1a2e8 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Thu, 2010-10-14 at 01:39 +0200, Kevin Kofler wrote: > Adam Williamson wrote: > > Er, really? I don't see where I offered any insult or un-excellent-ness. > > I just meant it as a vaguely humorous way of wondering why Kevin was > > replying to an email I sent over a week ago in a discussion which I > > thought had pretty much finished already. > > Because I don't have the time to sit on mailing lists 24/7. I guess the logical conclusion, given your output level, is that you have time to write email but not read it. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Wed, Oct 13, 2010 at 6:21 PM, Kevin Kofler wrote: > Nonsense. > * Whenever somebody complains about the Firefox maintainers rejecting non- > upstream patches, they give the trademarks as the reason. > * Whenever somebody complains about the branding, they claim it doesn't > matter because we aren't carrying non-upstream patches anyway. > That's a very circular argument. Please don't fall for it. > > There are some very concrete practical reasons for shipping some non- > upstream patches, unbundling libraries is one of those. > > Kevin Kofler I agree and this is exactly how the argument is going. People in FESCo have made it clear via their meeting notes that the Firefox branding is more important than following package guidelines. I liked what Spot had to say about the whole thing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On 10/13/2010 05:51 PM, Ralf Ertzinger wrote: > Hi. > > On Wed, 13 Oct 2010 22:26:18 +0200, Gilboa Davara wrote > >> As you pointed out, different drives, can have more-or-less identical >> partition size, with different CHS in the partition table. > > I my experience the hard disk vendors have been astonishingly coordinated > in how much sectors a drive of a given size should have. Total numbers of sectors may be the same---but the way the partitions are defined in the partition table requires the use of correct CHS disk geometry. Of course modern disks don't even have a well-defined physical geometry---the number of sectors per cylinder varies between the inner and outer tracks---but they still must declare one as a weird historical artifact required by the BIOS and traditional partition table layout. The manufacturers lie about it, e.g. declaring dozens of heads, but what's worse different manufacturers lie about it differently. Warning: what follows is boring and geeky, and might be wrong because a) I haven't worked with this stuff for a while now and b) things change as the disks get biger and newer. The reason the partition table has to represent the partition boundaries not as a Linear Block Address (LBA) sector count but as a Cylinder/Head/Sector coordinates, is because the BIOS booting code uses CHS access method. If those numbers assume wrong disk geometry then the partition ends up being non-contiguous because IIRC, the calculation from CHS to LBA goes somehow like this: LBA = c * (H*S) + h * S + s where c, h, s are the CHS coordinates of a partition in the partition table, and C, H and S are the total 'reported' number of cylinders, heads and sectors on the drive. If you copy the chs numbers without converting them for the different CHS geometry, you will get different and wrong LBA addresses, i.e. different partitioning. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2010-10-05)
On Wed, Oct 13, 2010 at 5:45 PM, Kevin Kofler wrote: > Bruno Wolff III wrote: >> There was also talk about whether or not it would be allowed for there >> to be a separate Iceweasel package in Fedora. This might be done to >> test the feasibility of maintaining it. There were mixed feelings about >> this amoung FESCO. > > This is essentially not feasible because most of the disputed patches are in > xulrunner, and a hypothetical separate Iceweasel package would share > xulrunner with Firefox, unless we have even more bundled libraries. > > I also don't see what we have to gain from shipping both. > > So it's really an either-or situation. > > IMHO, the version which is not compliant with our guidelines needs to go > away, period. We need to stop treating Mozilla specially, it needs to be > held by the same rules as any other upstream. If they don't cooperate, it's > the maintainer's job to fix things or orphan it. If nobody picks it up when > orphaned, it should be retired like any other package. Firefox is NOT an > essential package, the GNOME spin could just ship Epiphany (GNOME's default > browser) instead, and other desktop spins ALREADY ship the respective > desktop's default instead of Firefox! > > Kevin Kofler > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > It doesn't help when a majority of voting FESCo members are biased Firefox users who seem to hate the idea of Iceweasel (based on what I gather from their meeting notes). There seem to be some preconceptions about what happens when you remove the branding. No conclusive data can be provided to indicate how much users Firefox brings the distro. I also don't appreciate the comment at the meeting about "non contributing" members on the mailing list complaining about this issue. It's an argument often used to ignore people with valid arguments who also don't happen to have a computer science degree. Some of us advocate Fedora and that in itself is a contribution. Fedora consists of volunteers in many areas, not all of them make packages or write code. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Thu, Oct 14, 2010 at 10:28 AM, Adam Jackson wrote: > On Thu, 2010-10-14 at 01:39 +0200, Kevin Kofler wrote: >> Adam Williamson wrote: >> > Er, really? I don't see where I offered any insult or un-excellent-ness. >> > I just meant it as a vaguely humorous way of wondering why Kevin was >> > replying to an email I sent over a week ago in a discussion which I >> > thought had pretty much finished already. >> >> Because I don't have the time to sit on mailing lists 24/7. > > I guess the logical conclusion, given your output level, is that you > have time to write email but not read it. > > - ajax > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Given his output level we'll soon have KDE 4.5 in F13, hes a busy individual. I believe it was my mention of Iceweasel in irc that brought this to his attention. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2010-10-05)
On Thu, Oct 14, 2010 at 10:51:08AM -0400, Brandon Lozza wrote: > It doesn't help when a majority of voting FESCo members are biased > Firefox users who seem to hate the idea of Iceweasel (based on what I > gather from their meeting notes). There seem to be some preconceptions > about what happens when you remove the branding. No conclusive data > can be provided to indicate how much users Firefox brings the distro. Actually, I generally use epiphany. > I also don't appreciate the comment at the meeting about "non > contributing" members on the mailing list complaining about this > issue. It's an argument often used to ignore people with valid > arguments who also don't happen to have a computer science degree. > Some of us advocate Fedora and that in itself is a contribution. > Fedora consists of volunteers in many areas, not all of them make > packages or write code. I should point out that my degrees are in biology and biology, and the one that I haven't quite got yet is in biology. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
upstart in rawhide
Hello, systemd will be default init system in Fedora 15 and scripts infrastructure will be adapted to it. There is a plan to leave upstart in Fedora as non-official alternative. For now (since upstart-0.6.5-12.fc15): - upstart-sysvinit is no longer created - upstart requires sysvinit-userspace (now provided by systemd) which provides upstart compatible utilities /sbin/halt,poweroff,reboot,shutdown,telinit - conflicting upstart utilities are located in /lib/upstart - jobs definitions in /etc/init/ are already packaged in upstart but still taken from initscripts upstream git - to use upstart as init you need to pass init=/sbin/upstart to kernel command line e.g. via grub.conf There will be probably more changes like resolving file conflicts on /sbin utilities, rc.sysinit, /etc/init.d/halt and man pages which are currently not shipped. Any objections and comments are appreciated. Regards, Petr -- Petr Lautrbach, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Thu, Oct 14, 2010 at 10:38:29 -0400, Brandon Lozza wrote: > > I agree and this is exactly how the argument is going. People in FESCo > have made it clear via their meeting notes that the Firefox branding > is more important than following package guidelines. I'd encourage people who are interested in FESCO's views to read the log. The summary above is not what I took away from the discussion. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On Tuesday 12 October 2010 15:56:02 Dennis Jacobfeuerborn wrote: > Now we are really talking semantics. The point is that users should not be > confronted with choices they don't really need to make or they don't > understand. I disagree. How should a user know about some nice feature if its whole existence is hidden from his eyes? Yeah, he should read the documentation but aren't we talking about improving usability right now? Imagine some random user does his installs the hard way for years and now discovers (someone tells him oder he learns about it by chance by searching the documentation for an unrelated problem) that Anaconda has the capabilities to make his life easier. He goes like: "Woow cool, this is the stuff I've been searching for years. I don't have to waste my precious time anymore by setting all of this up by hand. Anaconda now takes care of it. Didn't thought those Anaconda developers are that genious. But why on earth didn't they tell me before their software was capable of doing that? Do they actually like watching people suffer? Seriously, you guys suck!" Hiding features doesn't have to be beneficial to usability. It can be harmful, too. > As long as most of these defaults and menus are not displayed initially > that would probably be fine. > The problem here is that every time you present the user with data dumps > (e.g. lists of defaults) or menus you create a cognitive hurdle where the > user wonders what he's supposed to do or gets worried that he breaks > something. Minimizing that is really key to creating a streamlined > installation interface. There are other ways to prevent confusion and worries about potential brokenness. If there are sane defaults and it is clearly communicated to the user that using those is the recommended way and gives him the best results in most cases, I don't see a problem. If users can trust in those defaults being sane and that by not touching them they get a good default configuration, they aren't helpless as they know what to do. However, if they wish to change something in future attempts they already know where they have to look. > new installed system. The user doesn't care at all about "partitions", > "LVM" or "mountpoints". I think you are strongly limiting the definition of what an user can be. So who is an user of Anaconda? For me, that is all those people using Anaconda. There is some guy from your neighborhood installing Fedora to surf the internet. There is some developer installing Fedora to work on the latest and greatest software in the GNU/Linux/X/freedesktop.org stack. There are designers using Anaconda to install the free software they need to create your favorite layout. There are also sysadmins deploying Fedora/RHEL/CentOS to many computers in their company, a public school or at your ISP's datacenter. So when you restrict Anaconda's userbase to just one kind of user, the whole assumption on which you build your enhancements to usability is wrong and will lead to software which sucks in usability as soon as you want to do something that you didn't consider basic enough to show it to users. Lars. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-14 Branched report: 20101014 changes
Compose started at Thu Oct 14 14:25:12 UTC 2010 Broken deps for x86_64 -- antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 gnome-pilot-conduits-2.0.17-4.fc13.x86_64 requires libgpilotdconduit.so.2()(64bit) gnome-pilot-conduits-2.0.17-4.fc13.x86_64 requires libgpilotd.so.2()(64bit) gnome-pilot-conduits-2.0.17-4.fc13.x86_64 requires libgpilotdcm.so.2()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires spacewalk-backend-libs >= 0:0.8.28 valide-0.6.1-0.22.20103003svn511.fc14.i686 requires libvala.so.0 valide-0.6.1-0.22.20103003svn511.fc14.x86_64 requires libvala.so.0()(64bit) Broken deps for i386 -- antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 gnome-pilot-conduits-2.0.17-4.fc13.i686 requires libgpilotdcm.so.2 gnome-pilot-conduits-2.0.17-4.fc13.i686 requires libgpilotd.so.2 gnome-pilot-conduits-2.0.17-4.fc13.i686 requires libgpilotdconduit.so.2 intellij-idea-9.0.1.94.399-11.fc14.i686 requires jna-examples qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires spacewalk-backend-libs >= 0:0.8.28 valide-0.6.1-0.22.20103003svn511.fc14.i686 requires libvala.so.0 New package: darktable-0.6-9.fc14 Utility to organize and develop raw images New package: erlang-getopt-0.3-2.fc14 Erlang module to parse command line arguments using the GNU getopt syntax New package: erlang-protobuffs-0-0.2.20100930git58ff962.fc14 A set of Protocol Buffers tools and modules for Erlang applications New package: rubygem-cairo-1.10.0-2.fc14 Ruby bindings for cairo Updated Packages: ardour-2.8.11-5.fc14 * Wed Sep 29 2010 Orcan Ogetbil 2.8.11-5 - Parallel build fails. Disable * Wed Sep 29 2010 Orcan Ogetbil 2.8.11-4 - Fix CVE-2010-3349 RHBZ#638365 cairomm-1.9.2-1.fc14 * Mon Oct 04 2010 Rick L Vinyard Jr - 1.9.2-1 - New upstream release clementine-0.5.3-1.fc14 --- * Wed Sep 29 2010 Orcan Ogetbil - 0.5.3-1 - New upstream version * Sun Sep 26 2010 Orcan Ogetbil - 0.5.2-1 - New upstream version * Wed Sep 22 2010 Orcan Ogetbil - 0.5.1-1 - New upstream version - Drop all upstreamed patches eclipse-fedorapackager-0.1.3-1.fc14 --- * Mon Oct 04 2010 Severin Gehwolf 0.1.3-1 - Merge rawhide changes. * Mon Oct 04 2010 Severin Gehwolf 0.1.3-0.1 - Better error checking in FedoraCheckoutWizard.java - Fixes https://fedorahosted.org/eclipse-fedorapackager/ticket/31 - Fixes https://fedorahosted.org/eclipse-fedorapackager/ticket/36 * Fri Oct 01 2010 Severin Gehwolf 0.1.2-1 - Fix getDistDefines() in FedoraHandlerUtils. * Thu Sep 30 2010 Severin Gehwolf 0.1.1-1 - Merge changes from master. * Fri Aug 27 2010 Severin Gehwolf 0.1.0-0.3 - Updated Eclipse help for Eclipse Fedora Packager. * Thu Aug 26 2010 Severin Gehwolf 0.1.0-0.2 - Fix feature and bundle version, egit/jgit dependencies. * Thu Aug 26 2010 Severin Gehwolf 0.1.0-0.1 - Rebase to 0.1.0 (introduces dist-git support). empathy-2.32.0.1-2.fc14 --- * Tue Oct 12 2010 Brian Pepple - 2.32.0.1-2 - Rebuild for new tp-glib. kde-l10n-4.5.2-1.fc14 - * Tue Oct 05 2010 Rex Dieter - 4.5.2-1 - 4.5.2 - fix Source urls - include kdepim-4.4 translations only for < f15 * Fri Sep 03 2010 Than Ngo - 4.5.1-5 - respin kdepim 4.4.5 translations * Wed Sep 01 2010 Than Ngo - 4.5.1-4 - bz#627898, add missing kdepim 4.4.5 translations kdeaccessibility-4.5.2-1.fc14 - * Sat Oct 02 2010 Rex Dieter - 4.5.2-1 - 4.5.2 kdeadmin-4.5.2-1.fc14 - * Sat Oct 02 2010 Rex Dieter - 7:4.5.2-1 - 4.5.2 kdeartwork-4.5.2-1.fc14 --- * Fri Oct 01 2010 Rex Dieter - 4.5.2-1 - 4.5.2 kdebase-4.5.2-1.fc14 * Fri Oct 01 2010 Rex Dieter - 6:4.5.2-1 - 4.5.2 kdebase-runtime-4.5.2-1.fc14 * Fri Oct 01 2010 Rex Dieter - 4.5.2-1 - 4.5.2 kdebase-workspace-4.5.2-1.fc14 -- * Fri Oct 01 2010 Rex Dieter - 4.5.2-1 - 4.5.2 * Wed Sep 29 2010 jkeating - 4.5.1-5 - Rebuilt for gcc bug 634757 * Mon Sep 20 2010 Rex Dieter - 4.5.1-4 - kdm is not localized when changing lang using system-config-language (#631861) kdebindings-4.5.2-2.fc14 * Thu Oct 07 2010 Rex Dieter - 4.5.2-2 - patch smoke generator invalid reads found by valgrind * Fri Oct 01 2010 Rex Dieter - 4.5.2-1 - 4.5.2 * Wed Sep 29 2010 jkeating - 4.5.1-4 - Rebuilt for gcc bug 634757 * Sat Sep 11 2010 Mamoru Tasaka - 4.5.1-3 - Fix macro usage
Re: Ubuntu 10.10's installer looks rather nice
On 10/12/2010 03:56 PM, Dennis Jacobfeuerborn wrote: > On 10/12/2010 02:52 PM, Ralf Corsepius wrote: >> On 10/12/2010 02:16 PM, Dennis Jacobfeuerborn wrote: >>> On 10/12/2010 10:28 AM, Gerd Hoffmann wrote: Hi, > Striving for usability and pleasantness for the untechnical users > certainly is > a good thing. It gets problematic when you choose to make things > technically > inferior just to please those kind of users. We don't have to make things inferior to improve usability. To stick with the "advanved storage" example: IMHO the selection screen between basic and advanced storage is confusing and superfluous. First it should probably be named "local storage" and "SAN storage". Second anaconda can default to local storage if a local disk is present (option to add SAN storage needs to be there of course). If no local disk is present it can go straight to SAN setup. One screen and one mouse click less for most of the users. >>> >>> If you want to appeal to the same audience Ubuntu is going for then you >>> have to remove choice. >> >> Why? All that would be required would be to move it out of this >> audience's way (the "defaults"). > > Now we are really talking semantics. I don't think so. > The point is that users should not be > confronted with choices they don't really need to make or they don't > understand. My point is to offer users who want choice the choices they want and not to force them into something they do not want. >> As Gerd mentioned in another mail, SUSE's installer seems interesting >> wrt. this. Its "defaults" cater the demands of "uneducated desktop >> installers", while still allows many kinds of complex setups outside of >> the "defaults" in "advanced menus". > > As long as most of these defaults and menus are not displayed initially > that would probably be fine. Please get yourself a SUSE DVD and try yourself - I was very positively surprized, esp. about SUSE's "disk partitioner's work-flow". It is easy to use for beginners (Click-through), while it still allows complex setups. > The problem here is that every time you present the user with data dumps > (e.g. lists of defaults) or menus you create a cognitive hurdle where the > user wonders what he's supposed to do or gets worried that he breaks > something. Minimizing that is really key to creating a streamlined > installation interface. > > The second aspect is that you want to talk to the user in terms of his > "problem" and not in terms of the underlying technology. Correct, ... my needs differ from that of others, ... therefore the tools being provided by a distro need to cater my needs, otherwise the distro doesn't fit my needs. > For example a user > wants to either replace the current System completely or install the > distribution into free space on his HD and but into either the old or the > new installed system. Correct, that some user's demand .. but definitely not all, and could not be further away from my demands. > The user doesn't care at all about "partitions", > "LVM" or "mountpoints". This is different from the more apt user who wants > to actually have control over these details (where exactly to put > partition(s) on the disk for example). Correct ... The latter for instance is what I had needed. I wanted to compare SUSE against Fedora. So I installed SUSE in parallel to other OSes (amongst them Fedora and Windows) on to the same machine. If my only choice would have been erase Fedora and/or Windows, ... this distro would have disqualified itself. > The issue here is that keeping these advanced features available could have > a negative impact on the "easy-mode" experience.If you manage to prevent > that from happening than more power to you but if not then creating two > distinct workflows is really the only option. I can't avoid to disagree. Spawning different installers means duplicating work and wasting resource. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On 10/14/2010 06:32 PM, Lars Seipel wrote: > On Tuesday 12 October 2010 15:56:02 Dennis Jacobfeuerborn wrote: >> Now we are really talking semantics. The point is that users should not be >> confronted with choices they don't really need to make or they don't >> understand. > > I disagree. How should a user know about some nice feature if its whole > existence is hidden from his eyes? Yeah, he should read the documentation but > aren't we talking about improving usability right now? Imagine some random > user does his installs the hard way for years and now discovers (someone tells > him oder he learns about it by chance by searching the documentation for an > unrelated problem) that Anaconda has the capabilities to make his life easier. > > He goes like: "Woow cool, this is the stuff I've been searching for years. I > don't have to waste my precious time anymore by setting all of this up by > hand. Anaconda now takes care of it. Didn't thought those Anaconda developers > are that genious. But why on earth didn't they tell me before their software > was capable of doing that? Do they actually like watching people suffer? > Seriously, you guys suck!" Yet most of this can be done in a much better way *after* the installation. I'm not sure why you think cramming as many features as possible into anaconda is a good idea. Once you've got the desktop running you have way better means to advertise features to the user. > Hiding features doesn't have to be beneficial to usability. It can be harmful, > too. Clearly if we wanted to hide *everything* we would not require a user interface at all but some choices need to be made. The point is that a lot of the stuff you apparently have in mind don't actually need to happen during the installation but can happen for example as part of the first-boot configuration. >> As long as most of these defaults and menus are not displayed initially >> that would probably be fine. >> The problem here is that every time you present the user with data dumps >> (e.g. lists of defaults) or menus you create a cognitive hurdle where the >> user wonders what he's supposed to do or gets worried that he breaks >> something. Minimizing that is really key to creating a streamlined >> installation interface. > > There are other ways to prevent confusion and worries about potential > brokenness. If there are sane defaults and it is clearly communicated to the > user that using those is the recommended way and gives him the best results in > most cases, I don't see a problem. If users can trust in those defaults being > sane and that by not touching them they get a good default configuration, they > aren't helpless as they know what to do. However, if they wish to change > something in future attempts they already know where they have to look. > >> new installed system. The user doesn't care at all about "partitions", >> "LVM" or "mountpoints". > > I think you are strongly limiting the definition of what an user can be. So > who > is an user of Anaconda? For me, that is all those people using Anaconda. There > is some guy from your neighborhood installing Fedora to surf the internet. > There is some developer installing Fedora to work on the latest and greatest > software in the GNU/Linux/X/freedesktop.org stack. There are designers using > Anaconda to install the free software they need to create your favorite > layout. There are also sysadmins deploying Fedora/RHEL/CentOS to many > computers in their company, a public school or at your ISP's datacenter. So > when you restrict Anaconda's userbase to just one kind of user, the whole > assumption on which you build your enhancements to usability is wrong and will > lead to software which sucks in usability as soon as you want to do something > that you didn't consider basic enough to show it to users. The problem is that you insist on cramming all these people into one single group and create an installer that will make everyone happy. That's just not going to happen and it's one of the primary reason why efforts to improve things often fail. While abstraction is good there is such a thing as too much of it. One perfect example is the idea that you can simply slap a traditional desktop on one of these new tablets or smartphones and you are done. The real genius behind what Apple accomplished wasn't some nifty technological feat or the fact that they control both hardware and software but that they recognized that these devices simply aren't traditional desktop PCs and as a result need a system that is tailored to this new world rather than simply rebranding StandardOS(tm) and putting that on there. I think what is needed here is a similar approach were we don't try to take the current installation process and put some lipstick on it but instead recognize that the needs of Joe Sixpack who doesn't care about technology but simply want to share YouTube videos, manage his photos and browse Facebook are different from Mr.
Re: genkey Segmentation fault
On 10/11/2010 12:31 AM, Philip Prindeville wrote: >On 10/10/10 12:25 PM, Philip Prindeville wrote: >> On 10/9/10 2:54 PM, fkoo...@tuxed.net wrote: >>> On Sat, Oct 9, 2010 at 8:48 PM, Philip Prindeville >>> wrote: Any suggestions? >>> https://bugzilla.redhat.com/buglist.cgi?quicksearch=genkey >>> >>> Regards, >>> François >> So... despite being root-caused, there's been no further movement on it in 4 >> months? >> > Well, as a workaround, I did "rpm -q --scripts mod_ssl" and figured out what > the install script was doing, and ran it by hand. Quicker than waiting for > genkey to be fixed. > > I think this bug is the same reported in https://bugzilla.redhat.com/show_bug.cgi?id=598160 Elio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
On 10/14/2010 07:05 PM, Ralf Corsepius wrote: > On 10/12/2010 03:56 PM, Dennis Jacobfeuerborn wrote: >> On 10/12/2010 02:52 PM, Ralf Corsepius wrote: >>> On 10/12/2010 02:16 PM, Dennis Jacobfeuerborn wrote: On 10/12/2010 10:28 AM, Gerd Hoffmann wrote: > Hi, > >> Striving for usability and pleasantness for the untechnical users >> certainly is >> a good thing. It gets problematic when you choose to make things >> technically >> inferior just to please those kind of users. > > We don't have to make things inferior to improve usability. To stick > with the "advanved storage" example: IMHO the selection screen between > basic and advanced storage is confusing and superfluous. First it > should probably be named "local storage" and "SAN storage". Second > anaconda can default to local storage if a local disk is present (option > to add SAN storage needs to be there of course). If no local disk is > present it can go straight to SAN setup. One screen and one mouse click > less for most of the users. If you want to appeal to the same audience Ubuntu is going for then you have to remove choice. >>> >>> Why? All that would be required would be to move it out of this >>> audience's way (the "defaults"). >> >> Now we are really talking semantics. > I don't think so. > >> The point is that users should not be >> confronted with choices they don't really need to make or they don't >> understand. > My point is to offer users who want choice the choices they want and not > to force them into something they do not want. > >>> As Gerd mentioned in another mail, SUSE's installer seems interesting >>> wrt. this. Its "defaults" cater the demands of "uneducated desktop >>> installers", while still allows many kinds of complex setups outside of >>> the "defaults" in "advanced menus". >> >> As long as most of these defaults and menus are not displayed initially >> that would probably be fine. > Please get yourself a SUSE DVD and try yourself - I was very positively > surprized, esp. about SUSE's "disk partitioner's work-flow". > > It is easy to use for beginners (Click-through), while it still allows > complex setups. > >> The problem here is that every time you present the user with data dumps >> (e.g. lists of defaults) or menus you create a cognitive hurdle where the >> user wonders what he's supposed to do or gets worried that he breaks >> something. Minimizing that is really key to creating a streamlined >> installation interface. >> >> The second aspect is that you want to talk to the user in terms of his >> "problem" and not in terms of the underlying technology. > Correct, ... my needs differ from that of others, ... therefore the > tools being provided by a distro need to cater my needs, otherwise the > distro doesn't fit my needs. > >> For example a user >> wants to either replace the current System completely or install the >> distribution into free space on his HD and but into either the old or the >> new installed system. > Correct, that some user's demand .. but definitely not all, and could > not be further away from my demands. > >> The user doesn't care at all about "partitions", >> "LVM" or "mountpoints". This is different from the more apt user who wants >> to actually have control over these details (where exactly to put >> partition(s) on the disk for example). > Correct ... The latter for instance is what I had needed. I wanted to > compare SUSE against Fedora. So I installed SUSE in parallel to other > OSes (amongst them Fedora and Windows) on to the same machine. > > If my only choice would have been erase Fedora and/or Windows, ... this > distro would have disqualified itself. > For all of the above select the advanced installation. I'm not sure why you recognize that you have very special needs for you installation yet at the same time seem to insist to be able to use the same installation procedure tailored to users who don't even understand a lot of the words you were using above. Nobody is "forcing" you to do anything. >> The issue here is that keeping these advanced features available could have >> a negative impact on the "easy-mode" experience.If you manage to prevent >> that from happening than more power to you but if not then creating two >> distinct workflows is really the only option. > I can't avoid to disagree. > > Spawning different installers means duplicating work and wasting resource. Nobody is talking about spawning different installers. You'd start the same installer but it would present you with a different workflow i.e. in the advanced workflow you'd create your partitions manually and in the easy workflow you select to wipe your disk or install next to you existing windows os and anaconda would determine the necessary partitioning itself without bothering the user. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mai
TWO Days Remain to Fix Fedora 14 Blocker Bugs
Hello Fedora 14 Blocker Bug Owners (all copied on this message), The list of bugs below are currently blocking the final release of Fedora 14. Updates fixing these bugs MUST be ready on Monday, 2010-10-18 (Final Change Deadline) or Release Engineering will be unable to create the Final Release Candidate on time, resulting in the possibility of a delayed release. We need your help *NOW*. As a maintainer, here is how you can help ... 639146 :: NEW :: xorg-x11-drv-intel :: a...@redhat.com :: Blank display (backlight on) after KMS initialization :: https://bugzilla.redhat.com/show_bug.cgi?id=639146 * next steps ... 1) Need to make final decision that this is not a blocker--is there anyone that believes this is a blocker? 2) Document on Common_F14_Bugs? 642358 :: NEW :: anaconda :: akozu...@redhat.com :: Up arrow tries to run gnome-screenshot :: https://bugzilla.redhat.com/show_bug.cgi?id=642358 * next steps ... 1) Patches pending review on anaconda-devel-list (unclear whether proposed patches fix all issues) 2) Build new anaconda containing approved patches 641846 :: NEW :: compiz :: adel.gadl...@gmail.com :: Panel applets (clock, workspace switcher, window selector, ...) randomly disappear :: https://bugzilla.redhat.com/show_bug.cgi?id=641846 * next steps ... 1) Reassigned to compiz, currently thinking is it is not a blocker bug 2) Document on Common_F14_Bugs? 641474 :: ASSIGNED :: lvm2 :: a...@redhat.com :: libdm does not present method to assign UUID after map creation :: https://bugzilla.redhat.com/show_bug.cgi?id=641474 * next steps ... 1) Maintainer needs to complete patch 2) Build and submit update by tomorrow 584328 :: ASSIGNED :: python-pyblock :: dleh...@redhat.com :: AttributeError: 'NoneType' object has no attribute 'name' :: https://bugzilla.redhat.com/show_bug.cgi?id=584328 * next steps ... 1) Patches reviewed, update needed when 641474 and 641476 are resolved 2) Build and submit update ASAP 642765 :: ASSIGNED :: anaconda :: dleh...@redhat.com :: AttributeError: 'NoneType' object has no attribute 'addChild' :: https://bugzilla.redhat.com/show_bug.cgi?id=642765 * next steps ... 1) Reporter confirms that fix works 2) Include fix in next anaconda build+update 641338 :: ASSIGNED :: qemu :: jfor...@redhat.com :: f14 qemu-kvm KDE guests boot very slowly :: https://bugzilla.redhat.com/show_bug.cgi?id=641338 * next steps ... 1) Determine whether issue is a release blocker (still unclear who is working this issue) 641476 :: MODIFIED :: kernel :: a...@redhat.com :: devicemapper UUID field cannot be assigned after map creation :: https://bugzilla.redhat.com/show_bug.cgi?id=641476 * next steps ... 1) Update pending, will be available for test soon 2) Verify bug and provide positive bodhi karma 635778 :: MODIFIED :: anaconda :: b...@redhat.com :: IndexError: list index out of range :: https://bugzilla.redhat.com/show_bug.cgi?id=635778 * next steps ... 1) Patches reviewed, committed and tested, awaiting next anaconda build+update 642483 :: MODIFIED :: anaconda :: dleh...@redhat.com :: Remove the 'Pre-release Software' Warning Screen :: https://bugzilla.redhat.com/show_bug.cgi?id=642483 * next steps ... 1) Patches reviewed and committed, awaiting next anaconda build+update 642763 :: MODIFIED :: kde-settings :: rdie...@math.unl.edu :: new user = blank/black wallpaper :: https://bugzilla.redhat.com/show_bug.cgi?id=642763 * next steps ... 1) Updates pending ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: TWO Days Remain to Fix Fedora 14 Blocker Bugs
On 10/14/2010 01:47 PM, John Poelstra wrote: > 641474 :: ASSIGNED :: lvm2 :: a...@redhat.com :: libdm does not present > method to assign UUID after map creation :: > https://bugzilla.redhat.com/show_bug.cgi?id=641474 >* next steps ... > 1) Maintainer needs to complete patch > 2) Build and submit update by tomorrow A patch has been submitted to the maintainer, and we're waiting for him to do a build... > 584328 :: ASSIGNED :: python-pyblock :: dleh...@redhat.com :: > AttributeError: 'NoneType' object has no attribute 'name' :: > https://bugzilla.redhat.com/show_bug.cgi?id=584328 >* next steps ... > 1) Patches reviewed, update needed when 641474 and 641476 are resolved > 2) Build and submit update ASAP This is ready and waiting on 641474 to do a rebuild. > > 642765 :: ASSIGNED :: anaconda :: dleh...@redhat.com :: AttributeError: > 'NoneType' object has no attribute 'addChild' :: > https://bugzilla.redhat.com/show_bug.cgi?id=642765 > * next steps ... > 1) Reporter confirms that fix works > 2) Include fix in next anaconda build+update Can't really be fixed until 584328 is. > 641476 :: MODIFIED :: kernel :: a...@redhat.com :: devicemapper UUID > field cannot be assigned after map creation :: > https://bugzilla.redhat.com/show_bug.cgi?id=641476 > * next steps ... > 1) Update pending, will be available for test soon > 2) Verify bug and provide positive bodhi karma Can't test this until the other bugs mentioned are fixed. -- Peter The Shuttle is now going five times the sound of speed. -- Dan Rather, first landing of Columbia 01234567890123456789012345678901234567890123456789012345678901234567890123456789 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please Review: (555955) Add CoS merge support
https://fedorahosted.org/reviewboard/r/91/ -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: upstart in rawhide
On Thu, 2010-10-14 at 17:13 +0200, Petr Lautrbach wrote: > Hello, > > systemd will be default init system in Fedora 15 and scripts infrastructure > will be adapted to it. > There is a plan to leave upstart in Fedora as non-official alternative. Why? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: TWO Days Remain to Fix Fedora 14 Blocker Bugs
On Thu, 2010-10-14 at 10:47 -0700, John Poelstra wrote: > Hello Fedora 14 Blocker Bug Owners (all copied on this message), > > The list of bugs below are currently blocking the final release of > Fedora 14. Updates fixing these bugs MUST be ready on Monday, 2010-10-18 > (Final Change Deadline) or Release Engineering will be unable to create > the Final Release Candidate on time, resulting in the possibility of a > delayed release. > > We need your help *NOW*. As a maintainer, here is how you can help ... > > 639146 :: NEW :: xorg-x11-drv-intel :: a...@redhat.com :: Blank display > (backlight on) after KMS initialization :: > https://bugzilla.redhat.com/show_bug.cgi?id=639146 > * next steps ... > 1) Need to make final decision that this is not a blocker--is there > anyone that believes this is a blocker? We already accepted it as a blocker, only ajax has specifically proposed that it's not, and there's certainly no consensus that it isn't yet. The new information we have here is that although this is a regression from F13 / 2.6.33, it's in functionality that was essentially working by accident prior to 2.6.34, and the code involved has changed completely since. So the fix may not be as simple / non-invasive as would usually be the case for a simple regression. I would like to see results of testing one of the reporters currently has planned, to see if a fairly simple patch can address this. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building mono-2.8 for 64 bit - possible solution to the problem
Hi, > > It looks like glibc is missing TLS support. Do I submit a BZ against > > glibc? > > That is simply not the case and it's hard to see how you came to such > a conclusion. Based on what I'm seeing from the error and getting from searching... I've looked a bit deeper and there is nothing untoward being set in the Makefile.in or Makefile.am files anywhere during the compilation - it's picking things up in the configure script correctly and there is nothing in the buildlog to say -m32 is being passed. I'm going now to assume that CCASFLAGS on the x86_64 buildsys is returning -m64 (is there a way to examine the root Makefiles generated by the buildsys to ensure that this is happening?) and what does that leave us with? Help! I'm running around in circles TTFN Paul -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: upstart in rawhide
On Thu, Oct 14, 2010 at 11:36:53AM -0700, Adam Williamson wrote: > On Thu, 2010-10-14 at 17:13 +0200, Petr Lautrbach wrote: > > Hello, > > > > systemd will be default init system in Fedora 15 and scripts infrastructure > > will be adapted to it. > > There is a plan to leave upstart in Fedora as non-official alternative. > > Why? Same reason initng is still around: someone's willing to do the work to maintain it. Specifically Petr (who I'll turn maintainership over to soon). --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 643174] New: perl-Devel-REPL's re.pl is broken
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Devel-REPL's re.pl is broken https://bugzilla.redhat.com/show_bug.cgi?id=643174 Summary: perl-Devel-REPL's re.pl is broken Product: Fedora Version: 13 Platform: All OS/Version: Linux Status: NEW Severity: high Priority: low Component: perl-Devel-REPL AssignedTo: iarn...@gmail.com ReportedBy: da...@fetter.org QAContact: extras...@fedoraproject.org CC: iarn...@gmail.com, fedora-perl-devel-l...@redhat.com Classification: Fedora Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. yum install perl-Devel-REPL 2. re.pl Actual results: Can't locate object method "load_plugin" via package "Moose::Meta::Class" at /usr/share/perl5/Devel/REPL/Plugin/LexEnv.pm line 9. BEGIN failed--compilation aborted at /usr/bin/re.pl line 3. Expected results: $_ Additional info: The Perl people tell me this error comes from mismatched Moose and Devel::REPL versions. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File WebService-Google-Language-0.12.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-WebService-Google-Language: 9774dffedf830a36c52e27cd8e2ad6d9 WebService-Google-Language-0.12.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: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Thu, 2010-10-14 at 13:11 +0200, Thorsten Leemhuis wrote:
> I tend to disagree, as including both Iceweasel and Icedove in addition
> to Firefox and Thunderbird gives users, admins and especially those that
> maintain a remix the option to easily chose the solution that suites
> their needs best.
FWIW, there is precedent in {fedora,generic}-{release,logos,...}.
--
Matt
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-WebService-Google-Language] Update to 0.12
commit 84d479fc5afbb139371d8fb919d38b8c8b98ec25
Author: Emmanuel Seyman
Date: Thu Oct 14 22:47:15 2010 +0200
Update to 0.12
.gitignore |1 +
perl-WebService-Google-Language.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 6709b0f..1e1a4cb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
WebService-Google-Language-0.10.tar.gz
+/WebService-Google-Language-0.12.tar.gz
diff --git a/perl-WebService-Google-Language.spec
b/perl-WebService-Google-Language.spec
index c400458..bf43938 100644
--- a/perl-WebService-Google-Language.spec
+++ b/perl-WebService-Google-Language.spec
@@ -1,6 +1,6 @@
Name: perl-WebService-Google-Language
-Version:0.10
-Release:3%{?dist}
+Version:0.12
+Release:1%{?dist}
Summary:Perl interface to the Google AJAX Language API
License:GPL+ or Artistic
Group: Development/Libraries
@@ -49,6 +49,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Oct 14 2010 Emmanuel Seyman - 0.12-1
+- Update to 0.12
+
* Fri May 07 2010 Marcela Maslanova - 0.10-3
- Mass rebuild with perl-5.12.0
diff --git a/sources b/sources
index ab612cb..fd1f4bc 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4b7697b79880c574d9e6b9d326d4632e WebService-Google-Language-0.10.tar.gz
+9774dffedf830a36c52e27cd8e2ad6d9 WebService-Google-Language-0.12.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
Retiring nforenum
Hi there, as soon as grfcodec-1.0.1-0.1.r772 is in stable for all branches I will retire nforenum. nforenum has recently been included in the grfcodec codebase, so there's no need to keep nforenum as a seperate package. This will probably affect nobody directly (unless you develop graphics for OpenTTD) since it is only used in the build process of openttd-opengfx. Felix -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: upstart in rawhide
On Thu, 14 Oct 2010, Adam Williamson wrote: > On Thu, 2010-10-14 at 17:13 +0200, Petr Lautrbach wrote: >> Hello, >> >> systemd will be default init system in Fedora 15 and scripts infrastructure >> will be adapted to it. >> There is a plan to leave upstart in Fedora as non-official alternative. > > Why? It makes perfect sense to me, as there could easily be things that don't work with systemd and "submit a bug report then use upstart" is a more appropriate answer than "don't use rawhide/F15 until it is fixed" or "try Ubuntu". Also upstart is in the contingency plan for the systemd feature. Michael Young -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Building mono-2.8 for 64 bit - possible solution to the problem
Hi, Just an update... I've looked and the x86 as well as x86_64 builds are failing on koji. Something looks wrong in the rawhide koji buildsys... TTFN Paul -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
System Monitor (System tab) show "Release" instead of "Fedora 14 (Laughlin)"?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm using the en_ca locale if that make any difference. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iF4EAREIAAYFAky3f+4ACgkQIqo66BA244QKVAEA0cNALBxNi8NaA4eu+3HvDC/v gn93tpg1uHQQdWEw4nwBALo/z9+3b0TbTR2sHixba6fVlsF3LWOmcTeTrAhSUSUN =UI6O -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 14 Final Blocker Bug Review Meeting 2010-10-15 @ 16:00 UTC (12 PM EDT)
When: Friday, 2010-10-08 @ 16:00 UTC (12 PM EDT/9 AM PDT) Where: #fedora-bugzappers on irc.freenode.net Open blocker bugs are here: http://bit.ly/aBqOcu Details of the current unresolved blocker bugs are here: http://lists.fedoraproject.org/pipermail/devel-announce/2010-October/000707.html Please join us tomorrow for this important meeting. John ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Final Blocker Bug Review Meeting 2010-10-15 @ 16:00 UTC (12 PM EDT)
On 10/14/2010 06:25 PM, John Poelstra wrote: > When: Friday, 2010-10-08 @ 16:00 UTC (12 PM EDT/9 AM PDT) > Where: #fedora-bugzappers on irc.freenode.net You mean 2010-10-15? I have the identical message to test-announce waiting for moderation - could you resubmit it with the correct date? Thanks. signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 14 Final Blocker Bug Review Meeting 2010-10-15 @ 16:00 UTC (12 PM EDT)
When: Friday, 2010-10-15 @ 16:00 UTC (12 PM EDT/9 AM PDT) Where: #fedora-bugzappers on irc.freenode.net Open blocker bugs are here: http://bit.ly/aBqOcu Details of the current unresolved blocker bugs are here: http://lists.fedoraproject.org/pipermail/devel-announce/2010-October/000707.html Please join us tomorrow for this important meeting. John ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
Matt McCutchen wrote:
> On Thu, 2010-10-14 at 13:11 +0200, Thorsten Leemhuis wrote:
>> I tend to disagree, as including both Iceweasel and Icedove in addition
>> to Firefox and Thunderbird gives users, admins and especially those that
>> maintain a remix the option to easily chose the solution that suites
>> their needs best.
>
> FWIW, there is precedent in {fedora,generic}-{release,logos,...}.
The issue is that Firefox is not compliant with Fedora guidelines and as
such has no business being in Fedora. Adding another package Y cannot solve
the problem of package X not being compliant with Fedora guidelines, only
removing package X can.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: upstart in rawhide
Petr Lautrbach wrote: > systemd will be default init system in Fedora 15 and scripts > infrastructure will be adapted to it. There is a plan to leave upstart in > Fedora as non-official alternative. I don't think this is a good idea at all. We want users still on upstart to get automatically migrated to systemd, so having systemd obsolete upstart at RPM level is the best way to get there. I also don't see what we have to gain from having a redundant init system in the distribution. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: upstart in rawhide
On Fri, 2010-10-15 at 01:13 +0200, Kevin Kofler wrote: > Petr Lautrbach wrote: > > systemd will be default init system in Fedora 15 and scripts > > infrastructure will be adapted to it. There is a plan to leave upstart in > > Fedora as non-official alternative. > > I don't think this is a good idea at all. We want users still on upstart to > get automatically migrated to systemd, so having systemd obsolete upstart at > RPM level is the best way to get there. AFAIK, this will be the case. Petr didn't say it wouldn't be. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2010-10-05)
On Wed, 2010-10-13 at 23:45 +0200, Kevin Kofler wrote: > Firefox is NOT an > essential package, the GNOME spin could just ship Epiphany (GNOME's default > browser) instead, and other desktop spins ALREADY ship the respective > desktop's default instead of Firefox! Epiphany is still not serious about security: https://bugzilla.redhat.com/show_bug.cgi?id=643224 Until this changes, I definitely won't use it. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: [Bug 244229] targetattr not verified against schema when setting an aci
https://bugzilla.redhat.com/show_bug.cgi?id=244229 https://bugzilla.redhat.com/attachment.cgi?id=453598&action=diff https://bugzilla.redhat.com/attachment.cgi?id=453598&action=edi Description: 1. When acl contains targetattr keyword: (targetattr [!]= "attribute_1 || attribute_2 ...|| attribute_n"), where attribute_n does not contain '*', the current ACL plugin accepts any attribute_n value even if it is not defined in the schema. This patch rejects the aci if it contains attribute_n not defined in schema with this error message: NSACLPlugin - targetattr "attribute_n" does not exist in schema. Please add attributeTypes "attribute_n" to schema if necessary. 2. To implement 1, slapi APIs slapi_attr_syntax_exists and slapi_vattr_type_exists are added. 3. An attributeTypes "connection" is added to 01core389.ldif which is referred in an aci of cn=monitor. Files: ldap/schema/01core389.ldif ldap/servers/plugins/acl/aclparse.c ldap/servers/slapd/attrsyntax.c ldap/servers/slapd/slapi-plugin.h ldap/servers/slapd/vattr.c -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Git commit in all available branches
On Tue, 12 Oct 2010 13:08:17 +1000 Jeffrey Fearn wrote: ...snip... > > What sort of updates does it get? > > Large changes of every kind: bug fixes, new features, changes in > behavior of existing features. Everything you'd expect of an > application that is fairly young and has a demanding user base ... a > very demanding user base ... OK, an extremely demanding user base ... > yeah, I have ulcers. And these users expect these things in stable releases? Do you ever get bugs asking you to not change interfaces or that some update causes breakage? Do you land in rawhide first to get additional testing before sending on to stable? Do updates cause changes in things like command line parameters, etc? Do you know how many users you have? This seems like it might be a pretty specialized package and have a pretty small pool of users. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Thu, 14 Oct 2010 01:42:21 +0200 Kevin Kofler wrote: > Gregory Maxwell wrote: > > Iceweasel as it currently exists in debian currently bundles exactly > > the same media libraries. > > CURRENTLY. > > The Debian Iceweasel maintainer has attached a patch to the upstream > bug which makes it use the system libvpx, we'd just need to apply > that patch. You are mixing up the bundling of libvpx and the bundling of other media libraries here. Firefox bundles other items as well, which is I think what Gregory was talking about as iceweasel also bundles them. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes for today's FESCo meeting (2010-10-05)
On Thu, 14 Oct 2010 10:51:08 -0400 Brandon Lozza wrote: > It doesn't help when a majority of voting FESCo members are biased > Firefox users who seem to hate the idea of Iceweasel (based on what I > gather from their meeting notes). I use midori here. Every once in a great while I will run firefox to look at something or see some behavior, but I almost never have it running. Please don't speak for others when you don't really know the answer to the question. > There seem to be some preconceptions > about what happens when you remove the branding. No conclusive data > can be provided to indicate how much users Firefox brings the distro. Indeed. > I also don't appreciate the comment at the meeting about "non > contributing" members on the mailing list complaining about this > issue. It's an argument often used to ignore people with valid > arguments who also don't happen to have a computer science degree. > Some of us advocate Fedora and that in itself is a contribution. > Fedora consists of volunteers in many areas, not all of them make > packages or write code. Sure. I agree, but just discussing something or being vocal about it means you expect someone else to do the work. In an all volunteer setup like Fedora, you may have to realize that this means it won't be done unless someone steps up to do it. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu 10.10's installer looks rather nice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/10/10 03:41 AM, Richard W.M. Jones wrote: > > I installed and played with Ubuntu 10.10 over the weekend (in a VM), > and I have to say that their installer is very smooth indeed. It's > starting to make anaconda look distinctly clunky. > > Some of the things it does which are IMHO better: > > - starts disk formatting / copying / installing in parallel > with asking user questions > > - downloads updates in parallel too > > - uses IP geolocation to guess the user's timezone and keyboard > settings (it's been 100% correct for me each time) > > - suggests a username and hostname based on the user's real name > (Mac OS X's installer also does this -- it's a nice touch) > > This is in contrast to anaconda (certainly from the live CD install) > which seems to be a usability no-go area. > > Thoughts? Can we switch to their installer? > > Rich. > Looking at the installation and the documentation of Ubuntu 10.10, the outside looks nice but the functionality is very lacking as pointed out on many posts. AFAIK, Ubuntu installer does not have the ability to customize installation for use needs as highlighted and can be only done offline. I don't know if there are installer from live media that provide more control about package to install other than extracting the bundled applications. What anaconda needs is more refinement and polishing as majority of function are already in place (has the team solved issue about multiple boot bug or recognition of other installed distributions>). To answer the question: don't switch to that new installer. - -- Luya Tshimbalanga Graphic & Web Designer E: l...@fedoraproject.org W: http://www.thefinalzone.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJMt74WAAoJEGZ+gIukWeEez4UH+wcvdTZBl8TvStVILx2vHGF2 1L1mgvYlfyZqmvTA/B8oFaU5uId3tNCFhoeGAhWEXwhjX2R9mX8MFjI5Gf+aU5Me A9rI2PGePvcV9jJ7B+Fohc5/61KGAYtitNZhiDq8MlBH1TMEH+HfesX3nzMvn3iV wjDELf3dzistkprX7ERSBm+pV0auUkYIQuOlr8AapoZzhi9LaRaOW4rBORb92ATf EfKOxu/ukicaqebrMHaMB3PaDDSXhFb/99opE+pwDG5IcwCymuMfiBT+D1g5+1vr SYyThPcxmhd1BGmXpO8ChW/wwIYQJ32hTvixvBJCiIVSUp9AIkJSEZdRf1lllUc= =1O1D -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Final Blocker Bug Review Meeting 2010-10-15 @ 16:00 UTC (12 PM EDT)
Andre Robatino said the following on 10/14/2010 03:32 PM Pacific Time: > On 10/14/2010 06:25 PM, John Poelstra wrote: >> When: Friday, 2010-10-08 @ 16:00 UTC (12 PM EDT/9 AM PDT) >> Where: #fedora-bugzappers on irc.freenode.net > > You mean 2010-10-15? I have the identical message to test-announce > waiting for moderation - could you resubmit it with the correct date? > Thanks. > > My mistake. Yes, the meeting is tomorrow, 2010-10-15 @ 16:00 UTC (12 PM EDT/9 AM PDT) John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: upstart in rawhide
On Thu, 2010-10-14 at 16:24 -0700, Adam Williamson wrote: > On Fri, 2010-10-15 at 01:13 +0200, Kevin Kofler wrote: > > Petr Lautrbach wrote: > > > systemd will be default init system in Fedora 15 and scripts > > > infrastructure will be adapted to it. There is a plan to leave upstart in > > > Fedora as non-official alternative. > > > > I don't think this is a good idea at all. We want users still on upstart to > > get automatically migrated to systemd, so having systemd obsolete upstart > > at > > RPM level is the best way to get there. > > AFAIK, this will be the case. Petr didn't say it wouldn't be. I think there's value in having the option to switch to upstart for at least F15, while the default of systemd is working nicely now. Then, upstart can be discontinued in F16 or whenever. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
