Re: Candidate packages for removal due to FTBFS, implications
2010/1/15 Matt Domsch : > ohm-0.1.1-9.39.20091215git.fc11.src.rpm > https://bugzilla.redhat.com/show_bug.cgi?id=539200 This should be a dead package, upstream is no longer being maintained. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Draft privilege escalation policy for comments
On 30 January 2010 07:33, Kevin Kofler wrote: > The current PackageKit policy in F12 updates still allows upgrading (as > opposed to installing or removing, not sure about downgrading, does > PackageKit even support that?) No, PackageKit won't let you downgrade a package. > Is the bureaucracy in this section really necessary? AFAICT what was missing > when the F12 PackageKit change was made was the informative part of the > proposal, the maintainer just didn't know what he should be allowing and > what not. I don't think the enforcement part is really needed, maintainers > should be able to get it right on their own given the detailed list of evil > things to avoid which the proposal provides and I haven't seen any evidence > as to the contrary (again, the PackageKit example is not applicable because > the PackageKit maintainer did NOT have such a list to go by when he made his > change; there's no reason to believe he'd have made that change in spite of > it). Sure, if there was a policy document I would have never made the Fedora change in the first place. I still think the original change (to make signed packages installable by the local console user install without a password) is the "right" upstream policy, but I will of course ensure all my packages agree with whatever Fedora policy is decreed. Luckily, with the new user account editor planned for F13, a lot of these PackageKit security policy choices can be made more intuitive. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: KDE-SIG meeting report (05/2010)
On 2 February 2010 15:12, Sebastian Vahl wrote: > * setroubleshoot introduced a hard dependency on gnome-packagekit (#561001) > * The dependency should be made generic or setroubleshoot has to be removed > from KDE spin. Is it just a dep on the PackageKit session API? If so can't we just add a virtual provide "PackageKit-session" to gnome-packagekit and kpackagekit, and switch setroubleshoot to require that? Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: KDE-SIG meeting report (05/2010)
On 2 February 2010 15:44, Till Maas wrote: > While you are fixing PackageKit dependencies, can you also remove the > PackageKit-yum-plugin dependency from PackageKit? The plugin seems not > to be necessary, as it can be disabled in > /etc/yum/pluginconf.d/refresh-packagekit.conf and still the gnome applet > indicates when there are new updates. You still need the plugin if you intend to use yum on the command line. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
hughsie AFK for two weeks
Hello fedora people, I'm going on holiday for two weeks (without a laptop), so if you've got any issues with gnome-color-manager, gnome-packagekit, PackageKit, gnome-power-mamager, upower, or any of my other packages then please get a provenpackager to fix it for me, or talk to mclasen in fedora-desktop if it's really important. Thanks. Richard Hughes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum appmarket
On 19 August 2010 16:46, seth vidal wrote: > 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. > 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. I'm kinda disappointing you didn't use (or extend) http://github.com/hughsie/app-install as it's what suse and ubuntu already use, and I had planned to use in Fedora. I've looked at the xml metadata in your repo, and it seems to provide very little in the way of the data we actually need in GUI tools, e.g. translations, and icons names. The app-install metadata is a gzipped sqlite and icons file, which is super quick to query compared to parsing and building the xml tree. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum appmarket
On 29 August 2010 15:07, seth vidal wrote: > I realized after this that I don't even need it the pkgTags db that we > already generate has the information needed b/c all the apps are tagged > with 'Application'. So no separate program is needed to generate the app > metadata at all. What about application icons? Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Linux and application installing
Linux has traditionally shown the user packages to update and install, which is great for administrators, but sucks hard for end users. How many times have you been prompted with an update list that asks you to decide whether to update something you have no idea about[1]? Mo illustrated[2] a few days ago about how confusing the updater is and I agree with her; and it's mostly my fault. Lists of unlocalized generic packages are so 1990's, and compared with the Ubuntu Software Center or the Android App-store we look like amateurs. So, a solution. I've been working on app-install[3] with some people from other distros for the last few months, and last week it had it's first public release. Schema version 2 is already being worked on, and now optionally integrates with PackageKit and also provides some other features like sorting applications by rating and application screenshots. I've already generated distro metadata for the entire fedora repository (this takes about four hours on my laptop) and packages are available[4]. It's really easy to generate metadata for the other repos too, but I digress. Read the README file for all the guts about how it works. I've got two demo applications that use the app-install data. One is an http://people.freedesktop.org/~hughsient/temp/app-install-install.png installer and one is an http://people.freedesktop.org/~hughsient/temp/app-install-update.png updater. These are work in progress, and show dramatically the lack of my UI design skills. The installer will be an additional tool (much like the ubuntu-application-installer compliments synaptic) which is focused on ordinary desktop users[5]. If you know what an epoch is, it's probably not for you. The old tool will remain, so panic not. This tool will just install applications, that-is anything that ships a desktop file with an icon. Anything else just isn't shown. Sorry! We will hopefully show groups too, perhaps even the same entries as the "Applications" menu. The updater will be an improved version of the old package updater, and anything that's not an application (e.g. PackageKit-libs-devel) will be under a group (not shown in the screenshot) called "System infrastructure". If you update an application that depends on a package from the "System infrastructure" group then it gets pulled in as a dep. Otherwise you only update the system stuff (e.g. systemd, dbus, kernel) if you choose to select the "System infrastructure" metagroup. Of course, you can descend and pick updates in that group individually like before, if you know what you are doing, but I think most people will just install the metagroup as one lump. Also, bear in mind that neither app-install or the application data packages are in distros just yet. This stuff isn't well tested. The code may steal *all* your magazines from your bathroom. Now, I mentioned my ineptitude at designing GUIs. This is where you come in. I would love you add mockups of what you think an application installer or application updater should look like to http://live.gnome.org/action/edit/app-install. I'm going to ask Máirín (mizmo on IRC) to help with the design work, so please upload images I can share with her and the other design people. Thanks! Richard. [1] https://fedoraproject.org/w/uploads/1/13/Updates-pkgkit-before.png http://mairin.wordpress.com/ [2] http://mairin.wordpress.com/2010/09/01/a-story-about-updates-and-people/ [3] http://github.com/hughsie/app-install [4] http://people.freedesktop.org/~hughsient/fedora/13/i386/ [5] http://www.packagekit.org/pk-profiles.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 7 September 2010 12:57, Rahul Sundaram wrote: > Thoughts on making the software center less distro specific? Couldn't > the UI be grafted on top of the PK api? app-install is completely distro-neutral. GNOME PackageKit and KPackageKit get the same kind of data from app-install for each distro. The reason we're not just modifying the Ubuntu Software center is just because it's so tied into the Ubuntu infrastructure. So far there is a generator for Ubuntu and Fedora. It's pretty trivial to add more. The app-install README file has answers to other common questions. Thanks, Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
2010/9/7 Miloslav Trmač : > Um, do I understand this correctly that e.g. a kernel update usually > won't get installed because it belongs in "system infrastructure" and > few packages depend on "kernel"? By default, all updates will be selected, even those in the system infrastructure group. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 7 September 2010 14:11, seth vidal wrote: > okay - I'll bite - why do we want to make it less distro-specific? For the same reason as pirut and pup were replaced. Fedora is *not* a big enough ecosystem to drive fully localized and feature rich user experiences. Working with other distros mean we can work as one big team and share the burden of translation, bug-fixes and writing new common code. I certainly don't want to write software for Fedora, but rather write software for Linux, and then write the small amount of Fedora interface code. > What does it get us? It means we have to deal with a bunch of > Lowest-common-denominator issues and it means a looser coupling of the > tools we have. Sure, I understand where you're coming from. As you see from app-install schema version 1 it really was least common denominator. But version 2, which is in progress now, features application screenshot previews (that ubuntu wanted) and application ratings (which we all wanted). Having an extensible format allows us to add the features in a cross-distro way without re-inventing schemas and UI. > It is legit to write tools for fedora that are FOR fedora. Why not do > that? Of course it's legitimate to do so. I just don't think it's a very sustainable or responsible way to write software. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 7 September 2010 14:39, seth vidal wrote: > Except we don't seem to do that. Over half of all commits to PK are from > you. The next closest committer has 6% of commits. If I exclude the > backends and translations then PK is written almost exclusively by you. I'm not sure I get your logic. Lots of the bugfixes (which may only be one or two commits a month) come from other distros. If I didn't make it generic, then there would be no possibility of running PackageKit on Suse, Debian, Ubuntu, Arch Linux or the other PK supported distros. > So all the time you spent writing a compat layer of code for OTHER > distros gets fedora what? A better, more architecturally sound design. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 7 September 2010 15:23, James Antill wrote: > Are you having any discussions about applications like postfix, or is > version 2 going to be just GUI stuff? Postfix is not an application. Applications have translated desktop files and icons. > I assume you have a plan for making this repodata, but I couldn't find > it, is there a URL? This isn't repodata, it's a separate data package. You /could/ push the icons.tar.gz and desktop sqlite database as repodata, although it's not going to change for the duration of each release[1] so seems like a waste of resources. From an rpm point of view, it's easier to deal with the install and removal of data as rpm scriptlets system-wide than by pushing this into yum itself (and other distros could not use this code). We also want this data installed by default, and not fetched / updated when the user tries to install something for the first time. That would ruin the user experience. Richard. [1] The data only needs to be refreshed if popular packages get split, or many translations get added. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 7 September 2010 16:39, James Antill wrote: > However this is very much the same problem as a user trying to find > "sql server" and getting results like "voms-mysql-plugin" etc. If you > intentionally ignore this problem, it just means even more work in the > long term as we have to change the metadata and any/all tools to cope. "Users" don't install SQL servers[1]. Admins and power users install SQL servers, and they'll be competent enough to either use the package add/remove programs application or just drop to the command line and use yum. Richard. [1] My definition of users are 3 actual people: http://packagekit.org/pk-profiles.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 7 September 2010 17:20, Nicolas Mailhot wrote: > ??? This was done 100% Fedora-side (not that I mind if it were adopted > by other distros) Incorrect. It was done on the Fedora transifex instance, but I know from fact that a few of the translators are from other distros, who have no interest in Fedora whatsoever. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 7 September 2010 17:32, Matthias Clasen wrote: >> And BTW a request at the time was to extend it with font previews to get >> a "font store" (because for fonts, gfx preview is really relevant and >> not eye candy) and it never happened :( > > If you send a patch it might ! A patch would be lovely, but some sample code that renders a ttf file to a png file "The smart brown fox or whatever" using cairo is probably good enough for me to get going. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 8 September 2010 13:16, Adam Williamson wrote: > First off, I think this is a great idea and very much needed, thanks for > working on it. Cool, thanks. Some positive feedback at last! Too... much... stop... energy... > On the cross-distro front, is Canonical / Ubuntu officially involved in > this and expecting to move to it in future, or are you just working > 'unofficially' with some Ubuntu community people and if anything it'll > wind up being an unofficial alternative for Ubuntu users? I'm working semi-officially with Sebastian Heinlein from Ubuntu and Roderick Greening from Suse. Sebastian is the one driving through the new changes in the Ubuntu Software Center, and works heavily with PackageKit and apt. You could say he's the right person to be working with. Of course, all the time app-install is too feature poor for them, they'll not switch from the xapian index (and this is the case with the deliberately simple v1 schema). Version 2 schema, which we're working on defining now, and is 90% complete provides enough functionality to switch away from xapian. But of course, Fedora is an early adopter and driving development. Just like normal. Just like it should be. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 9 September 2010 09:52, Nicolas Mailhot wrote: > It needs works both packagekit-side and font packaging side, but there is > absolutely no way I'm going to expand energy on pushing the packaging changes > through FPC & other font packagers if there is no buy-in packagekit-side to > make use of them. Unlike application desktop files, font preview has a single > consumer, packagekit, so it's totally wasted work if the packagekit side is > missing. I'm interested in font installing, but I think it might be better to integrate this with app-install rather than packagekit, as app-install has a pointer to a screenshot URL we can show in the preview window. This just means we have to treat fonts either as applications (and thus need desktop files) or we can just maintain a separate datastore and merge this with the fedora-app-install data before the package is shipped. The latter is probably my preferred solution. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 13 September 2010 08:36, Hans de Goede wrote: > But Adam is not the only one I love this idea too! And I would like to > think there are other silent admirers of this idea too! Cool, thanks. > I've even considered taken the review for the app data package and approving > it, but then decided that would only raise the controversy surrounding > the app data part. Right, that bugzilla is a big mess of ego and frustration (myself included). > FWIW I agree with you that for this to be truely user friendly the app > data needs to be present on the system when the user first starts the > app installer. Not sure if dropping it in a package is the best thing > to do though. If you could comment on the bugzilla, I believe FESCo is going to handle it from now on. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 13 September 2010 21:49, James Antill wrote: > So Seth spent half a day implementing a proof of concept: > http://skvidal.wordpress.com/2010/08/19/fedora-app-market-proof-of-concept/ Translations? Icons? Offline queries? Co-operating with other distros? Formal database schema? Call me biased, but doing things in yum because "it's the way it always used to be" carries little weight when the user experience just sucks really hard. I've been working on app-install now with other distro people for nearly two years. It was a shame Seth couldn't reuse some of the schema without just re-implementing the basic idea in python and shipping a half-baked implementation in yum. Sometimes I wonder why I should deal with Fedora and all the politics when Ubuntu and Suse just ship something that works. Sorry to be blunt, but it's how I feel. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-09-14)
On 13 September 2010 20:42, Kevin Fenzi wrote: > If you would like to add something to this agenda, you can reply to > this e-mail, file a new ticket at https://fedorahosted.org/fesco, > e-mail me directly, or bring it up at the end of the meeting, during > the open floor topic. Could you discuss https://bugzilla.redhat.com/show_bug.cgi?id=488968 as well please. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Meeting summary/minutes from today's FESCo meeting (2010-09-14)
On 14 September 2010 23:01, Kevin Fenzi wrote: > 21:33:35 The other 2 items I had were: > 21:33:56 application installer issues > 21:33:57 https://bugzilla.redhat.com/show_bug.cgi?id=488968 > 21:34:04 and > 21:34:05 BuildIdBuild infrastructure > 21:34:06 https://fedorahosted.org/fedora-infrastructure/ticket/2387 > 21:34:57 that needs more time, I'd say > 21:35:08 ok, will close out if no one has anything further... Well, that was enlightening. Do you think someone from FESCo could write something about https://bugzilla.redhat.com/show_bug.cgi?id=488968 in the bug, and make a decision please. Until then, all gnome-packagekit, app-install and kpackagekit work will be halted. I don't want to be in the same situation as Lennart where I've done loads of work and then a few influential people in Fedora just to turn around and say no. On 15 September 2010 00:05, Lennart Poettering wrote: > Everybody has a different idea of what Fedora should be, but mine is > definitely not one where people with negative energy make the rules and > then win by them. My sentiments exactly. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 16 September 2010 09:57, drago01 wrote: > Lets say we ever want to implement this > https://bugzilla.gnome.org/show_bug.cgi?id=612628 (or any similar > feature in another upstream project) > without a cross distro way to get the application data (icons, names, > etc. ) it would be a maintenance nightmare. You've hit the nail on the head. Hopefully FESCo will agree. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 16 September 2010 15:01, James Antill wrote: > Err ... PackageKit is currently the cross distro. way to work with > distro. package managers, nothing outside of that layer should ever know > (or care) where the data is coming from and how it gets updated etc. PackageKit is a _package_ abstraction framework. Yum is a _package_ manager. Applications like gnome-shell and kpackagekit want to search for new applications using translated per-application strings and show icons for desktop files. gnome-shell shouldn't care what a 'package' is. That's an uninteresting technical detail. There has to be a layer above the package manager that deals with applications. There has to be a cross-distro way to deal with the package:application mapping. It just so happens that app-install does just that. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 16 September 2010 20:05, Colin Walters wrote: > Personally I'd much prefer some nice asynchronous GObject API > somewhere for this, rather than parsing SQLite directly. PackageKit > seems like as good a place as any for this. app-install in git master has a GObject library, although it does need to know what annotations are, and does need asynchronous versions. I'm not super keen feature creeping PackageKit into ApplicationKit... > (I don't have a strong opinion on whether the data format is RPM or > repodata myself; maybe just a slight preference for the latter; the > most important thing in my mind is to come to rough consensus and > working code, and actually ship something) Right. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 17 September 2010 08:01, FlorianFesti wrote: > Can someone please elaborate a bit what pieces of information are really > needed? The .desktop files as a whole? Information we use in app-install: TABLE translations: STRING application_id Name of the desktop file, with no extension) STRING application_name Name in desktop file, in locale) STRING application_summary Comment in desktop file, in locale) STRING locale System locale TABLE applications: STRING application_id Name of the desktop file, with no extension STRING package_name The package name, e.g. 'nautilus' STRING categories Categories from desktop file, _not_ PK groups or PK categories STRING repo_id For adding and removal STRING icon_name Local filename with extension, e.g. "totem-pl.png". This is required so that local theme can override upstream icon STRING application_name Name in desktop file STRING application_summary Comment in desktop file INTEGER rating Rating in percent. 0 is unrated, and 100% is the best application in the world. STRING screenshot_url Screenshot URL that shows exmple usage. BOOLEAN installed If the application is installed NB: you are required to run app-install-admin --refresh-installed after each package install or remove if you use this feature. So, most of the data is extracted from the desktop file, but the icons often need to be resized and converted into png format which takes a bit of time. The rating comes from [is present in] comps, but will be populated by the gnome3 application stats, and I'm thinking of pointing screenshot_url at pkgdb for now. So, you still need more data than just the desktop file. When i generate fedora-app-install I use the desktop data for 90% of the data, and then use comps to fudge a popularity score, and then manually add the pkgdb link. It's a more manual process than I would like, although you can pretty much leave the generator to "do it's thing" which is 90% of the work. I think it's a ton more data than you want as rpm provides. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 17 September 2010 13:36, Arthur Pemberton wrote: > Wouldn't that require the tool to download every package just to get > the embedded information. Yes, that's what my generator tool does. Of course, it only downloads the packages that contain .desktop files (which we can tell from the metadata) otherwise that would take more than ages. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 17 September 2010 15:28, Bill Nottingham wrote: > Not if it's provided in the RPM header in a way where it can be easily > stuffed into the metadata or a similar place. Bear in mind: 'n' applications per package, where 'n' can be a large number. This means you have to come up with an interesting way to encode binary data in a application prefixed rpm-provide. Icky. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux and application installing
On 17 September 2010 16:39, FlorianFesti wrote: > open the payload and unpack the content of the desktop files... I got told by infrastructure this would take too much bandwidth and too much time to do on each compose. Apparently the link between the machine doing the compose and the mirror is slow. I forget, as there were technical roadblocks put in place to every different idea I could come up with. Even incremental updates of the application metadata would mean we had to keep around a copy of the metadata from the previous run, which wasn't any good either. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)
On 23 September 2010 08:37, drago01 wrote: > Well this cycle there was "on the way to gnome3 and back" situation, > which caused a lot of churn (even upstream). For what it's worth, the GNOME "will we, won't we" on a few different issues (GApplication, GTK3, etc) has cost a lot of developer time, and from an upstream perspective was a royal pain in the behind. I think Matthias has done a wonderful job keeping F14 in some sort of semblance, even with all this upstream turmoil. I think 2.32 is going to be a pretty good, stable release, but a lot of people (myself included) are saving the new bells and whistles for GNOME 3.0. Expect the Fedora 15 feature page for GNOME to read a little more interesting, for sure. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
docbook and glibc breakage?
All three of my newly released GNOME 2.32.0 projects failed to build on koji (f14) today: http://koji.fedoraproject.org/koji/getfile?taskID=2491737&name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=2491754&name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=2491800&name=build.log I've been told it's something to do with the way glibc decides to interpret posix rules for character classes, which seems to have broken grep. Can we revert the new glibc from the buildsystem please, until the breakage is fixed upstream. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: docbook and glibc breakage?
On 27 September 2010 19:58, Jaroslav Skarvada wrote: > The character class must be inside bracketed expression, thus double > brackets, please see man grep. The new grep-2.7 checks for this common fault: Right, but you could argue it's a regression as the behavior changed. Could somebody please fix docbook-utils, otherwise all the GNOME koji builds are going to fail. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: docbook and glibc breakage?
On 27 September 2010 21:04, Jesse Keating wrote: > Unless this change was made in f14. That is not acceptable for f14 at this > stage. I'm using dist-f14. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: docbook and glibc breakage?
On 28 September 2010 18:06, Kevin Kofler wrote: > Bill Nottingham wrote: >> Exactly... this is way late to be introducing this into Fedora 14. Any >> reason it can't be held for F15? (Bug filed to this effect.) > > The old behavior of that expression is not what the code probably expected, > it just happened to silently do the wrong thing instead of throwing an > error. The code which now errors needs to be fixed anyway. Right, but now all the software that I'm developing doesn't compile. This is F14, not rawhide. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review request please (required for PackageKit)
Could someone please review this package please: https://bugzilla.redhat.com/show_bug.cgi?id=631763 I need it as a dependency in the next version of PackageKit. I can bribe with beer if required. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review request please (required for PackageKit)
On 1 October 2010 13:24, Michal Schmidt wrote: > I've taken it for review. Thanks dude. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Command not found" misfeature
On 2 October 2010 09:51, Richard W.M. Jones wrote: > ..., then (sometimes, not always) displays some sort of > error[1]. Yes, it's fixed upstream, apologies. There's a new release on Monday which will be pushed to F14. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: docbook and glibc breakage [STILL BREAKING EVERYTHING]
On 27 September 2010 20:31, Richard Hughes wrote: > Right, but you could argue it's a regression as the behavior changed. > Could somebody please fix docbook-utils, otherwise all the GNOME koji > builds are going to fail. All my F14 builds are still failing with: docbook2man zif.sgml > /dev/null grep: character class syntax is [[:space:]], not [:space:] grep: character class syntax is [[:space:]], not [:space:] jw: There is no frontend called "/docbook/utils-0.6.14/frontends/docbook". I don't care if [[:space:]] is the POSIX correct behavior or not, all I know is every single build I've sent to build for F14 is failing. I'm *very* close to just not caring about F14, and just continuing to develop for rawhide. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: docbook and glibc breakage [STILL BREAKING EVERYTHING]
On 4 October 2010 11:32, Jaroslav Skarvada wrote: > You can force grep-2.7 to silently process it (above mentioned way, same as > with older greps) by setting POSIXLY_CORRECT > environment variable. But all such REs are probably typos Dude, that's so not the point. I have a f14 srpm that built fine last week, and now fails to build. It's not my error as the sgml file is valid. It's an error somewhere deep in docbook-utils. Set POSIXLY_CORRECT to default in F14, and leave it like upstream in F15. It's totally the wrong time for this kind of change. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On 5 October 2010 05:30, Orion Poplawski wrote: > Are we really stuck with gdm/kdm/lxdm/...dm > implementing it? No, I think what we need to do is to teach GPM how to turn off the internal panel when docked and with the lid closed. The only missing piece is for the kernel to export some kind of sysfs boolean saying "in-dock". From talks with mjg59, detecting a dock is pretty hard. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On 5 October 2010 09:55, FlorianFesti wrote: > Sorry for my may be naive question: Why do we need to know if we are > docked or not. Isn't there exactly the same situation if the external > Monitor is directly connected to the laptop? If there is an external > monitor and the lid is closed don't we want to switch off the display > regardless whether there is a docking station involved or not? Well, I guess some people would want the laptop to suspend, but it's a very good question. Now all it needs is someone willing and able to write a little patch for me :-) Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: "Command not found" misfeature
On 2 October 2010 11:23, Richard Hughes wrote: > On 2 October 2010 09:51, Richard W.M. Jones wrote: >> ..., then (sometimes, not always) displays some sort of >> error[1]. > > Yes, it's fixed upstream, apologies. There's a new release on Monday > which will be pushed to F14. https://admin.fedoraproject.org/updates/PackageKit-0.6.9-4.fc14 Please test and give karma. Thanks, Richard. -- 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 5 October 2010 15:51, Brandon Lozza wrote: > It really wouldn't be a fork at all. From what I can tell it's a build > flag that can be enabled or disabled and automatically takes out the > trademark and copyright artwork. People just don't want to remove the > branding because they presume they know how end users think. I know _for a fact_ my mum just looks for the "orange little swirl". Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Trouble with building packages in F16: "The moc has changed too much"
In F16 and rawhide the PackageKit koji build is failing with "This file was generated using the moc from 4.7.2. It cannot be used with the include files from this version of Qt. (The moc has changed too much.)" when it gets to building the PackageKit-qt library. See http://koji.fedoraproject.org/koji/getfile?taskID=3243129&name=build.log for the full log. Does anybody know how to recreate the moc file so I can build PackageKit for F16 and rawhide? Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trouble with building packages in F16: "The moc has changed too much"
On 1 August 2011 15:24, Jaroslav Reznik wrote: > It's not very good idea to ship pre-generated moc files, better to > autogenerate them during the build-time. PackageKit is using automake, > so it's a little bit more difficult but possible, check for example [1]. Right, I *think* I'm doing the right thing in https://gitorious.org/packagekit/packagekit/blobs/master/lib/packagekit-qt/src/Makefile.am with the only difference being that I'm shipping the moc files in the tarball. Can I just nuke the moc files in the fedora spec file, and they'll get regenerated at build time? Or should I remove MOCFILES from EXTRA_DIST? Thanks for your help, Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trouble with building packages in F16: "The moc has changed too much"
On 2 August 2011 14:54, Laurent Rineau wrote: > Yes. MOC files are generated files like .o files. The difference is that it is > generated *source* files. MOC files are with a version of Qt is not guaranted > to be usable with another one x.y.z, even if only the .z version number is > changed. Agreed. I fixed the problem upstream by not including the moc files in the tarball, and in the Fedora spec file for the last release by manually deleting the moc files, causing them to be regenerated. Thanks to all of you! :) Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On 19 August 2011 13:35, Steve Grubb wrote: > All security guidance says turn off or get rid of avahi. We really don't want > to > require it just to print. Then "security" is flying in the face of usability. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On 23 August 2011 01:32, Lennart Poettering wrote: > This is something we should > set for a number of services which never should get network access, like > upower, dbus, or colord. As the upstream for two of those, what do I need to do? At the moment both upower and colord are system activated and thus don't have a unit file. Cutting off network access seems like a sane thing to do. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On 23 August 2011 12:01, Lennart Poettering wrote: > I'll blog about it and use colord as an example. I'll ping you when I > have done that. Legend, thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Default services enabled
On 24 August 2011 01:35, JB wrote: > ...do not expect them to accept your sick "world domination" drive ...and this is why some upstream developers have unsubscribed from fedora-devel list. Ever wonder why people like David Zeuthen unsubscribed? People like you. I'm also ---> <--- this close to unsubscribing also. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Duplicate provides for provides for perl(DynaLoader)
Not really a big problem, but I got this in my daily updates check: (zif:836): Zif-WARNING **: found multiple provides for perl(DynaLoader) ~ : (zif:836): Zif-WARNING **: 1. perl-ExtUtils-MakeMaker-6.57.5-187.fc16.noarch (updates-testing) (zif:836): Zif-WARNING **: 2. perl-4:5.14.1-187.fc16.x86_64 (updates-testing) Is this intentional? It seemed a bit odd to be provided by the former. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Duplicate provides for provides for perl(DynaLoader)
On 7 September 2011 16:31, Jesse Keating wrote: > It is intentional that both the base perl package and the split off package > provide the same things, they are expecting n-v-r ordering to sort it out. Sure, but I couldn't see why something that is involved with creating makefiles would provide a common C-loader-into-perl interface. DynaLoader - Dynamically load C libraries into Perl code ExtUtils::MakeMaker - Create a module Makefile Either way, it's probably a bug in my code that it's issuing the warning, and I'll see what I can do to reproduce it in a test case. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On 7 September 2011 01:02, Adam Williamson wrote: > Is this a Bodhi bug? Or does FESCo expect voluntary compliance / > case-by-case enforcement of this policy? I'm guilty of this too; when I file an update that's not getting enough karma (after a few weeks) then I give it a spin in a *fresh* VM and test it out like any normal user would do. If this is wrong, consider my wrists slapped, but otherwise I think it makes sense and gets things moving. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: aggregation of gnome tools
On 8 September 2011 05:03, Joachim Backes wrote: > gnome-tweak-tool Current, high level. > gconf-editor Legacy. > dconf-editor Current, low level. > gconftool-2 Legacy. > gnome-session-properties Kinda current. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On 8 September 2011 03:13, Andre Robatino wrote: > If a packager repeatedly submits +1 for updates which turn out later couldn't > possibly have worked in actual testing, then their karma privileges could be > revoked. Makes sense to me. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
libmash API bump
I'm intending to build a new version of libmash in rawhide. The only user I'm aware of is gnome-color-manager, which I'll also also rebuild. Thanks, Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On 16 September 2011 17:36, seth vidal wrote: > Here is how yum does comparison between multiple package providing the > same thing: > http://yum.baseurl.org/wiki/CompareProviders I don't think that works for all cases; surely "grid-certificates = 2" wins over "grid-certificates = 1" in all cases? It's certainly better than relying on the length of the package name or alphabetical ordering... In Zif, I'm doing something like: * Filter by best arch * Filter by depend version * Filter by native arch * Filter by smallest name * Filter by newest ...and this seems to work well as normal people don't want to drag non-native architecture packages onto their system for an update and want to follow the latest provide version (even if that means installing additional deps). The current logic where yum wants to install a hundred i686 packages on my x86_64 box when the repos get a bit screwy doesn't seem to work very well in my opinion. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On 16 September 2011 18:43, seth vidal wrote: > having different tools is not acceptable. Especially when one of them is > not even remotely covering the use cases of our actual users. Installing 205 new i686 packages when updating the system is not acceptable. > I think I'm going to suggest to fesco that all non-yum depsolvers be > removed from the distribution. It just creates more work than it does > value. Ha! That's really funny, and it's just made my evening. While you're asking fesco, can you also ask them to remove KDE and XFCE as well please. There's really nothing special about a package manager I assure you. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
2011/9/16 Miloslav Trmač : > How about the 1126 members of the "packager" group - i.e. most of us - > that would have to create and maintain packages compatible with two > different systems? That's nonsense, sorry. Zif is quite capable of using the same metadata as yum and performing the same function with the same set of packages. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On 16 September 2011 20:07, Jef Spaleta wrote: > A methodology I could use to then verify suboptimal performance of any number > of depsolving policies for myself in my own testing. This is what I've come up with already: https://github.com/hughsie/zif/tree/master/data/tests/transactions Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On 16 September 2011 20:02, Richard W.M. Jones wrote: > Is Zif a SAT solver? No, but I've been playing a few times with libsatsolver in the past year or so. > We could really use a SAT solver to replace the current yum depsolver. SAT is pretty awesome, and there are some pretty clever guys who have got it to work really well with zypp. I can't say I understand all the subtle nuances, but it's clearly better than an iterative depsolver with random rules to steer things in the right direction. Plus, once you've populated the .sat files, it's really fast. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On 16 September 2011 20:32, Jef Spaleta wrote: > local: the package installed Yup, the "installed" store. > remote: the available provider(s) that satify the transaction requirements? The packages available in remote stores. > transaction: command performed Yup. > config: system state like what arch we are pretending to be at the moment? Right, and other stuff like skip_broken or exact_arch and that kind of thing. > For these tests... what is the remote repository metadata that you are > using? Is is a cutdown set of repo data or is it a snapshot of a real fedora > tree at some moment in time? The transactions are all taken in spirit from real problems, but made as simple as possible. The repodata is all cut down to the bare minimum. Checkout zif, and run "make check" and you'll see everything that's done. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On 16 September 2011 20:46, Jef Spaleta wrote: >> Are you sure you didn't cut it down so much that you are hiding problems >> that your depsolving rules don't solve well? Did you throw out someone's >> baby with all that bathwater? Perhaps I did; the tests were made intentionally simple. > If I wanted to run the same transaction tests under current yum using your > cutdown repodata directory and point yum to it? Sure, I guess you could write some python for that. I'm not really a python dude. > I'm assuming you've done this already. are there particular test > transactions where yum comes up with a different solution than zif using > your cutdown repodata that you would like to draw my attention to? No, I've not, but I would be very surprised if those simple transaction results differed. The way the results would differ is if you setup a fake repo that's intentionally broken, and switched on skip_broken. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On 17 September 2011 02:36, Kevin Kofler wrote:
> So you came up with this really complex heuristic in a vain attempt to
> always do the right thing without requiring changes to the packages, and now
> it does a completely wrong thing which would be straightforward to avoid,
> and suddenly it's the packages that need fixing? Huh?
Sure, I don't understand this either. The whole %{isa} thing is a
crutch. I can't think of a single case where I want a new i386 package
to satisfy a dep on my x86_64 system that's not *explicitly*
specified. If the correct package isn't available, then just skip this
package until the next updates check, and hope the repos are in a more
sane state next time.
Anyway, if anyone wants to know the fesco ticket, it's here:
https://fedorahosted.org/fesco/ticket/669
Richard.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On 17 September 2011 07:21, Richard W.M. Jones wrote: > ... and no way to access yum information from anything other than > Python, which makes it harder to use more professional programming > languages and yum data together. I had to write a whole bit of code > that spawned a Python process to get some dependency data, write it to > a file, and parse that back in to the real program. Out of interest, would Zif allow you to do this? There are some example programs here: https://github.com/hughsie/zif/tree/master/examples or some developer docs here: http://people.freedesktop.org/~hughsient/zif/docs/ Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On 17 September 2011 10:38, Richard W.M. Jones wrote: > Yeah, it looks possible. > The very fact that you're exposing a C API and a library is a > promising start, even if it didn't yet do specifically what I needed. Would it be easier if I provided a GIR file so you can just use gobject-introspection? Anyway, let me know if zif falls short or looks odd as an API and I'll see what I can do. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On 17 September 2011 11:05, Richard W.M. Jones wrote: > I don't mind as long as it's callable from other languages (either > using generated bindings like GIR or using hand written bindings). I've just pushed: commit 4132eb5a40e1a6a85358e96f7adfd3cf56e8ef3f Author: Richard Hughes Date: Sat Sep 17 11:34:34 2011 +0100 Enable GObject introspection support > I would just caution that I found GIR was not expressive enough to > implement libguestfs bindings. Specifically it lacked support for > optional arguments and structs (unless encapsulated as an object). I > don't know whether or not that would affect zif. Ohh, 99.9% of Zif is using GObjects and GTypes, so I don't think that will be a problem here. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On 17 September 2011 11:59, Rahul Sundaram wrote: > I think zif needs to be command line compatible and support delta RPMs The former should work pretty well. If I've missed any obvious aliases yell and I'll add them. The latter is 80% implemented, but I don't use delta-rpms myself and it was left for somebody else to do. It would be a nice little project for someone wanting to get to know Zif internally. I can write up exactly what needs to be done if you mail me offlist. If delta-rpms support is a must-have then I can probably finish it in a day or so. No biggie. :-) > ...I think the problem PackageKit is facing is also true for other tools. I agree. I've just merged the GIR generation into master, so hopefully it would be possible to do things like use Zif from PHP and Javascript in the future. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On 17 September 2011 13:56, Kevin Kofler wrote: > Richard Hughes wrote: > And Python too, I suppose? Sure. I'd welcome any python dudes to write a small program in examples/ just to test if the GIR annotations are complete enough. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On 17 September 2011 23:06, Jef Spaleta wrote: > zif as packaged in F15 is returning with Zif in F15 is a really old version, and F16 is the first release where I'm going to support zif. The latest upstream release is 0.2.3 and I think the version in F15 is much older than that IIRC. > I was hoping the zif as packaged would be useful enough to to run > transaction tests against real repos. It's looking like that's not the > case. If zif only seems to operate with your specially crafted stripped > down repodata there isn't a lot to talk about at the moment. Naa, try the version of zif in F16, or grab the latest upstream SRPM and rebuild it for f15 from here: http://people.freedesktop.org/~hughsient/fedora/15/SRPMS/ I've been using zif exclusively day-to-day in F16 if that's a datapoint. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On 18 September 2011 19:22, Panu Matilainen wrote: > I'm talking about means of having all the rpm-related tools use the same > abstract dependency resolution algorithm though an API. Whether that is > /in/ rpm, or something that rpm itself /uses/ (and possibly further > exports via its own API) is not terribly relevant to that goal. If rpm exposed a depsolve API, I would switch to it in a heartbeat. If it's C, it's good for me. If it's based around libsolv, then even better. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On 19 September 2011 01:46, Kevin Kofler wrote: > Well, looks like we also need a rebuild of PackageKit-zif against the new > soname (libzif.so.3, the package in F15 is built against libzif.so.2), so I > think the repo is the best solution if we want people to be able to test > this. Richard, what do you think? This is why I didn't backport the new zif to F15. If you're confident doing the PK and zif rebuild for F15 at the same time then I'm happy just to stick it in F15 properly rather than having a separate repo. I didn't trust myself enough to not break PK in a stable release, although it would only affect people with PackageKit-zif already installed. I'm okay with either solution. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: how to have yum prefer one dependency over others
On 19 September 2011 17:41, Jef Spaleta wrote: > I've installed this zif from koji and I'm still not able to complete a "zif > install paprefs" transaction with realworld F15 configured public repository > set, whereas all the yum based tools: yum. repoquery etc... complete as > expected. > Guys what's going on with zif? Can you open a ticket on Red Hat bugzilla please, component "zif" and attach the output of "zif install paprefs -v" I've not tested zif on F15 in a lng time and it's probably just a trivial bug. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in
On 1 October 2011 12:02, Hans de Goede wrote: > I would like to suggest to change the default power policy to never suspend > while on AC power. That's what it was supposed to be, but due to an oversight on my part the wrong keys were being set. I've fixed this upstream in https://bugzilla.gnome.org/show_bug.cgi?id=660395 -- which will of course be included in 3.2.1 Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-16 suspends my *desktop* after 30 minutes at the gdm , making it impossible to ssh in
On 3 October 2011 08:57, Richard Hughes wrote: > That's what it was supposed to be, but due to an oversight on my part > the wrong keys were being set. I've fixed this upstream in > https://bugzilla.gnome.org/show_bug.cgi?id=660395 -- which will of > course be included in 3.2.1 I've done a test build here for anyone interested: http://koji.fedoraproject.org/koji/taskinfo?taskID=3401483 Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30
On 12 October 2011 17:44, Kevin Fenzi wrote: > All existing users of the Fedora Account System (FAS) at > https://admin.fedoraproject.org/accounts are required to change their > password and upload a NEW ssh public key before 2011-11-30. I have to upload a *new* public key? Why should I have two sets of keys? > * Nine or more characters with lower and upper case letters, digits and > punctuation marks. > * Ten or more characters with lower and upper case letters and digits. > * Twelve or more characters with lower case letters and digits > * Twenty or more characters with all lower case letters. This is just insane. My existing password is 8 digits and alphanumeric, and given that I have to enter it over and over again (and prove "I'm human", another WTF) when creating updates I'm really wondering if I want to bother. Talk about putting up barriers. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PackageKit vice shell
On 16 October 2011 19:00, JB wrote: > pk-command-not-found [OPTION...] We fixed this quite a long time ago. Perhaps upgrading to F15 or F16 might be a good idea? Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PackageKit in Fedora 15 (beta)
On 24 April 2011 19:24, Ilyes Gouta wrote: > I filed a bug: https://bugzilla.redhat.com/show_bug.cgi?id=699263 I've commented on this, and closed it NOTABUG. Sorry. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
retiring hal-info
In a move that will surprise few, I'm retiring hal-info in devel and orphaned it in f15. If hal gets blocked for f16, then I'll do the same for hal-info. The only thing that requires hal-info is hal, and libmtp-hal. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken PackageKit
I made a mistake yesterday, and pushed PackageKit-0.6.14-1 without doing all the self checks. This build broke getting the updates list which is kind of a bad thing for a package manager... I've built PackageKit-0.6.14-2 to fix the issue and pushed it to f15-updates-testing and rawhide. The broken build was only in f15 updates testing for one day, and will be in rawhide until tomorrow. Please manually update tomorrow using "yum update PackageKit" if this issue affects you. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ubuntu to switch to lightdm?
On 12 May 2011 12:41, Camilo Mesias wrote: > So, reading between the lines, is it fair to say that Ubuntu seem to > have chosen a display manager to avoid dbus and consolekit? I'm pretty sure Ubuntu chose it because it's not gdm. Differentiation FTW. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora rawhide FTBFS status 2011-06-16 i386
On 23 June 2011 01:19, Matt Domsch wrote: > Fedora Fails To Build From Source Results for i386 > using rawhide from 2011-06-16 Most of my packages are failing like this: In file included from /usr/include/pango-1.0/pango/pango-gravity.h:98:0, from /usr/include/pango-1.0/pango/pango-types.h:91, from /usr/include/pango-1.0/pango/pango-font.h:26, from /usr/include/pango-1.0/pango/pango-attributes.h:25, from /usr/include/pango-1.0/pango/pango.h:25, from /usr/include/pango-1.0/pango/pangocairo.h:25, from pk-plugin-install.c:31: /usr/include/pango-1.0/pango/pango-script.h:132:12: error: unknown type name 'G_CONST_RETURN' /usr/include/pango-1.0/pango/pango-script.h:133:12: error: unknown type name 'G_CONST_RETURN' This is because GLib has deprecated the macro G_CONST_RETURN and a *lot* of stuff that depends on GLib also define the G_DISABLE_DEPRECATED build flag. Until projects that do that ship new tarballs, there is going to be a lot of breakage. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
On 8 February 2010 22:46, Kevin Kofler wrote: > As a result, you'll be causing dozens of FTBFS bugs just before the feature > freeze. I think this is entirely the wrong time in the release cycle to do > such a change, if it is done at all. I've been fixing upstream projects for weeks to build with --no-as-needed. The list of projects that fail to build should be much smaller now, especially for GNOME and Freedesktop stuff. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: LD Changes To Implicit DSO Linking Update
2010/2/9 Parag N(पराग़) : > when one of my package fails to build? Should I ask upstream to > hardcode required DSO names in Makefile or we need to modify CFLAGS in > %build section? Most of the time upstream (myself included) just forgets to add a library at the end of the LDADD line, so all I had to do was send a trivial patch upstream to add "-lm" or something. See here for an example: http://bugzilla-attachments.gnome.org/attachment.cgi?id=152993 Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Color Management Test Day Thursday 2010-02-18
On 17 February 2010 01:48, Dariusz J. Garbowski wrote: > Features/ColorManagement describes per-screen / per-output support. I have a > dual monitor setup here > (potentially even triple-monitor if I could setup SurroundView with on-board > Radeon and discrete > Radeon card). I don't see test case for multi-monitor setups. Is this planned > or supported already? It's supported already, unless you're running the nvidia binary blob. I've never tested with SurroundView, but if you're setting up the monitors with xrandr, they should work fine. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants a more sane updates policy (feedback requested)
On 26 February 2010 22:54, Kevin Fenzi wrote: > - If stable pushes were more restricted, perhaps that would get us more > testing? If someone required a newer version and could easier > install/test from updates-testing and provide feedback, don't we all > win? Perhaps we could have PackageKit/yum say "you have the latest > stable version of foo, but foo-2.0 is in updates-testing, would you > like to test it and provide feedback? I had PK code to do that, but the check for updates took way too long, as the updates-testing repo had to be enabled, the primaries downloaded (and maybe the file lists too), updates resolved and then disabled again, in ADDITION to the normal updates check. The package manager is just too slow to get PackageKit data to make such a thing work without making the user wait an extra 30 seconds. If we could speed up the dep checking and downloading, I agree it would be better for usability, and the exposure of updates-testing generally. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants a more sane updates policy (feedback requested)
On 27 February 2010 19:31, Jeroen van Meeuwen wrote: > This sounds interesting, was this a plugin or configuration setting? > Could this be something people can opt-in to at first? in /etc/PackageKit/PackageKit.conf, the idea was to set CheckTestingRepos to true. I'm not sure the code is actually reading this config setting yet, so if you want it to work you might have to contribute some python. :-) Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FESCo wants a more sane updates policy (feedback requested)
On 28 February 2010 18:39, James Antill wrote: > I can't think of any reason why you'd need, or want, to have > updates-testing checks block any other GUI operation. To show the list of newest updates to the user... >> If we could speed up the dep checking and downloading, I agree it >> would be better for usability, and the exposure of updates-testing >> generally. > > Dep. checking is pretty fast, upT¹ is roughly 10 seconds for 300 > packages here and lsuT is like 2.5 seconds. I guess maybe that's worth > caring about if you block everything else behind it, but... Sure, and 2.5 seconds _extra_ is a long time. > As to the downloads, if you know of a way to speed up a users internet > connection ... feel free to spread your wisdom. Here's three: * Download from multiple mirrors simultaneously * Do the transaction in parallel so that you're downloading the next depsolved set of updates as you're installing the first * Have better control of the cache format so you don't need to keep three files in sync just to update the primary and then depsolve. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines 04/09 - 02/10
On 3 March 2010 21:45, Tom "spot" Callaway wrote: > Here are the list of changes to the Fedora Packaging Guidelines: I've done some updates, and now rpmlint reports: argyllcms.spec: W: no-cleaning-of-buildroot %install argyllcms.spec: W: no-buildroot-tag Does rpmlint need an update? Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap
On 4 March 2010 13:17, Kevin Kofler wrote: > But of course the GNOME spin "works" (for some definition of "works", they > also have a PackageKit issue which was declared not a blocker – For the record, it is a yum-langpacks issue. If you're running an up to date gnome-packagekit you get a nice message telling you so. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap
On 4 March 2010 19:59, Kevin Kofler wrote: > I think we > really need to be more conservative about what version of our default > updating tool we include in our releases (and in fact pushing PackageKit 0.6 > as a post-release enhancement update once the issues with it are resolved > and there is an actual kpackagekit release to go with it, while shipping F13 > GA with 0.5, would probably have been much less disruptive). PackageKit, as in the daemon has been pretty stable for ages. PackageKit-glib2 has been stable up until recently, where we broke API to fix a bug in a little-used piece of API (most applications, including GPK, unaffected). PackageKit-qt has had wild changes, which the QT and KDE guys said they needed to fix bugs in KPackageKit. KPackageKit has a much smaller community base than GNOME PackageKit (which is expected, it's a younger project) and so the developers only have the resources and desire to work on git master, rather than stable branches. If you want to talk to anybody about stability, it's probably the PackageKit-qt guys you need to talk to, and offer help. I'm pretty sure the situation will get better over time, as the -qt library settles down and the kpackagekit project gains momentum. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
sos update causing PackageKit to barf
The latest sos update is not signed: [hugh...@hughsie-t61 packages]$ rpm -qp sos-1.9-1.fc12.noarch.rpm warning: sos-1.9-1.fc12.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID 57bbccba: NOKEY This causes PackageKit to barf. How come this update was pushed without a signature and all the other are fine? Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: sos update causing PackageKit to barf
On 8 March 2010 10:59, Michael Schwendt wrote: > That means you don't have the key installed: This is a fresh F13 pre-alpha spin, updated last a few days ago. > $ rpm -Kv sos-1.9-1.fc12.noarch.rpm > sos-1.9-1.fc12.noarch.rpm: > Header V3 RSA/SHA256 signature: OK, key ID 57bbccba > Header SHA1 digest: OK (db9c3b4d1c5a5990e1c4b72cbb4c76d7c65a25e9) > V3 RSA/SHA256 signature: OK, key ID 57bbccba > MD5 digest: OK (85ddf4a6d8615965a79f06e7f09be84c) > > $ rpm -q gpg-pubkey-57bbccba > gpg-pubkey-57bbccba-4a6f97af > It is signed. Sure, but doesn't 57BBCCBA indicate that it's a F12 signed package, not a F13 signed package? I don't appear to have the 4a6f97af signature installed by default on my fresh F13 (not upgraded from F12) workstation. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Announcing `gold-rebuild' - link your packages with gold now
On 8 March 2010 11:44, Michal Nowak wrote: > Past months I spent investigating `gold' - the new GNU linker > and how it now works with stock Fedora packages. Using gold, I get: /usr/bin/ld: --no-add-needed: unknown option /usr/bin/ld: use the --help option for usage information collect2: ld returned 1 exit status This is with fully updated F13. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: selinux-policy-targeted update failure
On 8 March 2010 19:47, Adam Williamson wrote: > Is there a sekrit PK mode you can use to get such output, does anyone > know? Maybe if I just launch it from a console... No, but I could do such a thing if you file an enhancement bug. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
DeviceKit-power has been renamed to upower
As some of you may know, DeviceKit-power has been renamed to upower. If you depend on the former, you need to change your rawhide spec files to depend on the latter. DeviceKit-power will cease to be a package in devel in a few minutes. I've not made any changes to F13 branches, as it's too close to release time for this sort of change. If your project is using devkit-power-gobject, you can still keep using this, although upower will only provide this compatibility library for another few months, and applications are urged to move to libupower as soon as possible. Thanks, Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DeviceKit-power has been renamed to upower
On 15 March 2010 15:38, Bruno Wolff III wrote: > On Mon, Mar 15, 2010 at 15:17:20 +, > Richard Hughes wrote: >> As some of you may know, DeviceKit-power has been renamed to upower. >> If you depend on the former, you need to change your rawhide spec >> files to depend on the latter. DeviceKit-power will cease to be a >> package in devel in a few minutes. > > Is there some reason you aren't doing a provides for the old name so that > things still work? (And presumably an obsoletes as well.) I'm doing an obsoletes, but I would rather people feel the pain of having to update the spec files now (early in the F14 cycle) rather than when we remove the compatibility provides in over a years time, and when nobody remembers what the new name is. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: devkit-power-daemon broken?
On 14 April 2010 19:02, Adam Williamson wrote: > AFAIK none of these are generic bugs. Handling AC plug/unplug is > actually not as simple as it seems, and can vary from device to device > (or, rather, ACPI implementation to ACPI implementation). So this is to > a degree system-specific. It's totally system specific. I'm clearing bugs (and adding workarounds) as fast as I can, but if you really want a bug fixed "ASAP" you've essentially got two options: * Pay someone for a support contract to diagnose and fix the bug (if you pay Red Hat, I'll probably be me) -- this means it jumps my TODO list by an order of magnitude. * Find the bug and write a tiny patch to fix it, and send it to me I've only got 24 hours in a day, just like everybody else. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: HAL status
On 18 April 2010 20:55, Ben Boeckel wrote: > The wiki states that pm-utils is hal-free. Maybe the hard dep in the RPM needs > looked at? Ajax discovered that it pokes HAL in at least two places. We're waiting for an upstream fix in the meantime. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: spin kickstart/minimization cleanups
On 21 April 2010 16:17, Adam Williamson wrote: > I've been banging a gong about something like that for years; right now > it's much too hard to know what you're supposed to do to make > $RANDOM_GADGET that you just plugged in actually work, but we can hardly > install the software for every USB device under the sun by default. > There's a clear need for something like this. Really it's just a kind of > widget that sits between udev and PackageKit, I think. It already exists, and is the GpkHardware GObject that lives in gnome-packagekit. In Fedora we disable it by default, but Suse use it to great affect. Fedora just uses GpkFirmware which intercepts missing firmware requests from the kernel and offers to install the firmware and then soft-replug the device. The hard bit (and why it's disabled in Fedora) is working out what software needs to be installed for a given bit of hardware. It's really the kind of thing that needs to be added to udev as just a simple rule, and then enabled in gnome-packagekit. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
