Re: PROPOSAL: Make AppData files mandatory for applications shown in the software center

On 7 November 2014 02:15, Zbigniew Jędrzejewski-Szmek wrote: > We would. My point is that we should we should make a list of > applications which are not allowed to fall by the wayside I think that list would be very different for each person you ask; the easiest thing to do is to just create the

Re: downgrade version of gthumb in fedora 21 final?

On 7 November 2014 00:31, Michael Catanzaro wrote: > Since gthumb does not follow the GNOME release schedule, we > shouldn't push unstable versions of gthumb to rawhide. No? We push unstable GNOME to rawhide all the time; or is this more of a case where we're worrying that a stable gthumb won't b

Re: PROPOSAL: Make AppData files mandatory for applications shown in the software center

On 7 November 2014 11:04, Alexander Ploumistos wrote: > I read your blog posts on AppStream/AppData and I found some > Workstation/AppDataImprovement pages on the wiki, but I could not find the > list you provided in your original message. https://lists.fedoraproject.org/pipermail/devel/2014-Nove

Re: PROPOSAL: Make AppData files mandatory for applications shown in the software center

On 7 November 2014 11:24, Jaroslav Reznik wrote: > This is a very good idea, if we want to enforce it, packaging guidelines > are good place to start with for new applications. Approved, but ignored: https://fedorahosted.org/fpc/ticket/414 Richard. -- devel mailing list devel@lists.fedoraprojec

Re: PROPOSAL: Make AppData files mandatory for applications shown in the software center

On 7 November 2014 15:01, Alexander Ploumistos wrote: > You can scratch nut-monitor off, it already has appdata: Is it in a tarball that's been built for F22? What some upstreams do is commit the file upstream but either forget to dist the file in the tarball, or forget to install the file at ins

Re: Metacity and GNOME Flashback

On 10 November 2014 05:22, Michael DePaulo wrote: > I would like to package all of GNOME Flashback and I was wondering if > you had any intention of doing so. if not, I'm curious if there is a > use case for Metacity outside of a GNOME Flashback session and if you > (or anyone else) have any advic

Re: PROPOSAL: Make AppData files mandatory for applications shown in the software center

On 9 November 2014 23:11, Kevin Kofler wrote: > I oppose this kind of censorship, especially because you are implementing it > at the point of AppStream data generation, and thus your arbitrary policy > decisions do not affect only the GNOME Software Center, but also any other > consumer of the Ap

Re: F22 Self Contained Change: Disabled Repositories Support

On 17 March 2015 at 11:18, Jan Zelený wrote: > Personally, I don't like the semantics of these semi-disabled repos. It beats > the purpose of disabling the repos in the first place, doesn't it? disabled=0 means "don't download packages or metadata" which means if we search for "chromium" nothing

Re: F22 Self Contained Change: Disabled Repositories Support

On 17 March 2015 at 15:35, Miloslav Trmač wrote: > Wait, the metadata download and search code is not shared? What would it > take to make it so? No. The dnf code is in python and the libhif code is in C. > /me wonders how many unicorns and kittens will have to die before we get rid > of all

Re: F22 Self Contained Change: Disabled Repositories Support

On 20 March 2015 at 08:59, Matěj Cepl wrote: > Sorry, I am just a stupid idiot writing in one of those hated > interpreted languages Nobody said anything of the sort. I write stuff in python all the time. > What’s the realtionship between the interpreted > languages and said duplication? Okay,

gdk-pixbuf2 package splitting

I've just pushed two new gdk-pixbuf2 builds to rawhide *not* F22. * The first splits out the modules (e.g. the ico, jpeg, gif loaders) to a separate subpackage called gdk-pixbuf2-modules -- which we'll certainly need on workstation but really not on cloud or text-only installs * The second splits

Re: gdk-pixbuf2 package splitting

On 20 March 2015 at 15:18, Mamoru TASAKA wrote: > i.e. Looks like /usr/include/gdk-pixbuf-2.0/gdk-pixbuf-xlib/ should also be > moved to gdk-pixbuf2-xlib-devel. Good catch, I'll do that now, thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mai

Pushing the extra AppData files into Rawhide

In the effort to make the AppStream generation simpler I'm going to deprecate the fedora-appstream repo[1]. This was always designed to be a stop-gap until upstreams had done new tarball releases and to "rescue" applications that we care a lot about, and we're now at a point where over 50% of upstr

Re: Pushing the extra AppData files into Rawhide

On 25 March 2015 at 19:40, Richard Hughes wrote: > -- I can't promise cookies, but I'll really appreciate it and it means > the applications won't disappear from Fedora 23. Yell if you have any > questions. So, the overwhelming amount of help I received (one person) me

Proposal: Drop applications that have FTBFS for the last two releases from the AppStream metadata

The end result would be that we don't show applications that have failed the previous two releases mass rebuilds in GNOME Software i.e. we don't show f19 packages in f21, and we don't show f20 packages in f22. Should be pretty non-controversial, right? The kind of software that failed two rebuilds

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

On 30 March 2015 at 07:57, Till Maas wrote: > - provides hibernation support via "systemctl hibernate", which is > also what pm-hibernate does (why do we have two tools for the same > core task?) pm-hibernate should have been removed from Fedora a long time ago. I don't know what

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

On 30 March 2015 at 11:21, Dominik 'Rathann' Mierzejewski wrote: > Is systemctl hibernate/suspend the official replacement for > pm-hibernate/suspend now? Very much so :) Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora C

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

On 30 March 2015 at 15:42, drago01 wrote: > Can/should we just obsolete / retire it? I tried to, but I don't have enough super powers. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject

Re: Pushing the extra AppData files into Rawhide

On 31 March 2015 at 14:07, David Timms wrote: > I see my package was adjusted, but I can't get it to build: I only build the new-enough libappstream-glib into rawhide -- seeing as most of the f23 builds have succeeded I'll do the same for F22 and submit an update. F20 is much too old for that ver

Re: Pushing the extra AppData files into Rawhide

On 1 April 2015 at 11:50, Neal Gompa wrote: > Is it alright to just commit it as an extra package source existing within > the package script sources repo (like how we handle patches) until we can > get it upstreamed? Sure, that's fine as well, thanks. Richard. -- devel mailing list devel@lists

Re: AppStream license code for public domain works

On 1 April 2015 at 19:06, Alexander Ploumistos wrote: > As far as I can tell, that makes them public domain. Is it the same as > CC0-1.0 or is there another license I should choose? You don't *have* to choose SPDX license IDs -- something like "Public Domain" would be fine I suppose, although I'd

Re: AppStream license code for public domain works

On 1 April 2015 at 19:25, Alexander Ploumistos wrote: > If CC0-1.0 is (at least almost) equivalent, I am perfectly fine with > that, no need to specify a new tag. I think it's very similar indeed. I use CC0 myself when I want Public Domain that's legally clear in all countries. Richard. -- deve

Re: appdata validation and too long

On 7 April 2015 at 23:23, Bruno Wolff III wrote: > The hedgewars appdata file from upstream is getting flagged as invalid by > rpmlint. I checked with appdata-validate and get the following: > appdata-validate -v /usr/share/appdata/hedgewars.appdata.xml > /usr/share/appdata/hedgewars.appdata.xml 1

Re: dnf replacing yum and dnf-yum

On 7 April 2015 at 17:37, Adam Williamson wrote: > This is easier said than done. We don't have a perfect dependency > checker and it's not at all easy to write one. From someone that's actually written a yum-compatible dependency checker in C several years ago[1] I can attest that the --skip-bro

Re: What happened to all cmyk icc

On 27 Apr 2015 5:45 am, "Luya Tshimbalanga" wrote: > I noticed all FOGRA and CMYK icc seem missing in colord-extra-profiles > package. Is it a bug or a glaring omission? It's not enabled in rawhide, but should be present in F22 and F21 -- are you using the rawhide package perhaps? Richard -- dev

Re: What happened to all cmyk icc

On 27 April 2015 at 09:36, Richard Hughes wrote: > It's not enabled in rawhide, but should be present in F22 and F21 -- are you > using the rawhide package perhaps? My mistake; it was never re-enabled after the f22 branch (generating the print profiles takes huge wads of CPU and me

Re: nettle, gnutls: soname version bump in rawhide

On 27 April 2015 at 15:33, Kalev Lember wrote: > I think it would make sense to keep ABI compatibility with the old > soname for one Fedora release, just to give 3rd parties time to > transition over. I could help making an ABI compat package for this if > you agree it makes sense? From my point

Fedora 22 and missing applications

Quite a few people are going to be installing Fedora 22 in the coming days, searching for things in the software center and not finding their esoteric GUI tool. This is because some applications still don’t ship AppData files, which have become compulsory in the workstation spin for this release. L

Re: Fedora 22 and missing applications

On 26 May 2015 at 19:56, Hans de Goede wrote: > What does "dead" in that table mean? I see a lot of games marked this way, > and yes many games see little upstream activity, because once a game is > finished it typically really is finished. Dead means "no upstream release in 5 years". > If I add

Re: Fedora 22 and missing applications

On 26 May 2015 at 22:10, Reindl Harald wrote: > you need learn to accept that software reaches the point where iot is just > *read yand finished* just because it does what it is supposed to do and > needs ntohing fixed or changed all the time I assume you can point to several high-quality desktop

Re: Fedora 22 and missing applications

On 27 May 2015 at 09:32, Jaroslav Reznik wrote: > Is it GUI only or is there any chance to get at least TUI apps? Some > as mc are pretty popular even in the group of GUI only users. I think mc fails quite a few of the criteria: https://github.com/hughsie/appstream-glib/blob/master/README.md -- a

Re: Fedora 22 and missing applications

On 27 May 2015 at 11:57, Michael Schwendt wrote: > It kinda sucks that you list a "No keywords in .desktop file" warning > for almost all packages even if they meet the packaging guidelines and > the specific requirements of the F22 development cycle, i.e. running > "appstream-util validate-relax"

Re: Including tlp in Fedora Workstation by default

On 28 May 2015 at 10:45, Nadim Kobeissi wrote: > I would like to suggest that tlp [0] be included with Fedora Workstation by > default, starting with Fedora 23. Why can't we just use the correct defaults? Having a "configure all the things" version of powertop isn't going to help anybody but the

Re: Including tlp in Fedora Workstation by default

On 28 May 2015 at 11:21, Nadim Kobeissi wrote: > 1: My understanding is that tlp ships with a default configuration that, > without any modification, will enable reasonable settings for power saving. I think what the kernel is providing is reasonable, from a regression / feature point of view. I

Re: Fedora 22 and missing applications

On 27 May 2015 at 16:19, Matthew Miller wrote: > Richard, sorry for the dumb question, but is there a path to pull in > keywords from ? Or, going the > other way, can we get the Fedora apps team to highlight/prioritize > packages which match applications on

Re: Fedora 22 and missing applications

On 29 May 2015 at 15:57, Matthew Miller wrote: > Yeah, that makes a lot of sense. I was thinking of something periodic > rather than just once, though. Does anybody know the URL to get the tags for all packages? Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedorapr

Re: AppData Guidelines

On 2 June 2015 at 17:17, Gerald B. Cox wrote: > Upstream response is if they are duplicated in the desktop file, then they > aren't needed in the appdata file. This is old advice and no longer true. One mistake I made when first pushing AppStream was to fall back to the .desktop file Name= and Co

Re: fedup for F23 and beyond

On 3 June 2015 at 11:55, Petr Hracek wrote: > Does it mean that using systemd Offline Updates there will not be a "Zero" > downtime feature. > Except rebooting because of kernel upgrade? Well, we'll certainly be using offline updates to do the actual transaction. > Will there be any possibility

Avoiding the automatic /usr/bin/python3 dep

Hi all, In fwupd we ship 4 *tiny* python scripts that are useful for ODMs and other people working with low level firmware blobs. In https://src.fedoraproject.org/rpms/fwupd/pull-request/2 it was suggested we split them off as a subpackage to avoid the /usr/bin/python3 dep which is unwanted on Cor

Re: Avoiding the automatic /usr/bin/python3 dep

On Thu, 25 Jun 2020 at 14:57, Miro Hrončok wrote: > What you need is to disable is the "shebang dependency generator" from RPM. > The > easiest way is to use: > https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/ > %global __requires_exclude ^%{python3

Re: Packaging firmwares

On Fri, 26 Jun 2020, 22:21 Florian Weimer, wrote: > Is FirmwareUpdate.efi really firmware in Fedora's sense? Won't it run > on the host CPU? > This is flashed hardware!? Can't mellanox just use the LVFS to distribute firmware rather than having to install a package of blobs you're going to use

Re: TPM2 for disk encryption, clevis

On Wed, 8 Jul 2020 at 09:59, Marius Vollmer wrote: > As I understand it, there is a lot of evolving OS specific subtlety > involved, so I am asking specifically how this would look on current > Fedora and what to expect in the near future. Just a heads-up; the PCR0 changes when you upgrade the sy

Re: The future of legacy BIOS support in Fedora.

On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr wrote: > needlessly disables a lot of kernel functionality It disables functionality which can destroy platform security. > You cannot load kernel modules you've built If you can build and insert your own kernel module you can do almost anything to

Re: The future of legacy BIOS support in Fedora.

On Wed, 8 Jul 2020 at 22:19, John M. Harris Jr wrote: > This is not something that's beneficial here, it's only > harming our users. That seems exceedingly myopic to me. I'm guessing you've not been following the last few years of security research, where attacking the firmware is now the best wa

Managing the GNOME updates in Fedora

At the moment the GNOME updates in Fedora are a bit of chaotic affair. They mostly work, but only because of people like mclasen who spend hours and hours building packages and putting everything together manually. For 3.3.92 I experimented doing a mega-update and trying to get all the 3.3.92 build

Re: Managing the GNOME updates in Fedora

On 26 March 2012 11:58, Peter Robinson wrote: > It would be nice if the rawhide stream was built at the same time as > well as not doing so has the effect of people trying to work with > rawhide as well get random failures and in the process of building > F-17 and rawhide on ARM a non insignifican

Re: Managing the GNOME updates in Fedora

On 26 March 2012 20:31, Kevin Kofler wrote: > Let's also mention our mass-update script: > https://fedorahosted.org/kde-settings/browser/scripts > which may or may not be of interest. Very much of interest, thanks. I spent a couple of hours and wrote mclazy, i.e. "I'm lazy and I'm trying to help

Building the GNOME 3.4.1 Release

If you're maintaining a GNOMEish package and you want it included in the 3.4.1 release, please build the package like normal and then add the build ID to: https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc Most of the packages released on ftp.gnome.org with t

Re: Building the GNOME 3.4.1 Release

On 14 April 2012 22:31, Debarshi Ray wrote: > What about using a page on https://fedoraproject.org/wiki/ ? Unless I'm mistaken, you can't have more than one person editing a wiki page at the same time. Seeing as there's normally 3 or 4 of us building packages simultaneously, it needs to be instan

Re: Building the GNOME 3.4.1 Release

On 16 April 2012 10:13, Milan Crha wrote: > it will be kind of you to not touch packages you do not own, especially > those which are actively maintained. The way you did it breaks "build > the package like normal" from your instructions. In the same way I've emailed for your two other privately

Re: Building the GNOME 3.4.1 Release

On 16 April 2012 11:32, Milan Crha wrote: > Maybe he's just _currently_ busy, sleeping (consider different > timezones) and so on? Anyway, I never asked to have those packages part > of the auto-build list, and never was asked for acceptance. This is > easily distinguishable, isn't it? I was aske

Re: Fedora 18 Release name voting and Poll for whether to continue naming releases

On 20 April 2012 07:41, Toshio Kuratomi wrote: > As for the poll -- The Board has heard a lot of people asking to remove code > names but is unsure if thats just because thats the group that happen to > subscribe to the mailing list in question. When have you ever heard "I'm running Fedora Beefy

GNOME 3.4.2 mega-update

I'm going to manage the GNOME 3.4.2 mega-update again for this release, as it's much easier to QA in one update than 30. If you're doing a GNOME 3.4.2 build please add it to the speadsheet https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc and I'll add it to th

Non-GNOME version numbers -- maintainer help required!!

Hi! The mclazy.py script is doing a great job of building all the tarballs that come from ftp.gnome.org that adhere to the official gnome numbering scheme. This means we can build an entire gnome point update automatically in about an afternoon whereas before it used to take days of manual work. W

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

On 17 June 2012 10:53, Richard W.M. Jones wrote: > So this is a problem that needs to be solved, but does it require a > reboot?  Not really ... it's possible to list all processes using > zlib, convert that back into a list of packages, then instruct those > packages to restart themselves.  Job d

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

On 16 June 2012 14:04, Reindl Harald wrote: > the next "have solution, searching problem" of Lennart? > hopefully this leads not sooner or later in uncareful > designs where it get more and more a must No, if you mist blame somebody please send insults to me instead. I asked Lennarts advice on ho

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

On 17 June 2012 11:00, Frank Murphy wrote: > Not much use to Xfce users. Xfce doesn't have a native PackageKit client. If you run the gnome-settings-daemon updates plugin then it "just works". I don't think XFCE has the manpower to re-implement all the stuff needed for the existing QA release tim

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

On 17 June 2012 20:01, Jochen Schmitt wrote: > In this case we may save outage time, because we don't have waste time > for the BIOS POST, loading the bootloader and the kernel. It takes me 4 seconds to POST, boot the kernel, get into system-update.service, and then reboot. Using a new rpm versio

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

On 17 June 2012 18:49, Richard W.M. Jones wrote: > You're asserting that dbus-daemon etc cannot be restarted, but without > saying why. Okay, I'll say why. The core protocol was never designed to support the dbus-daemon being restarted. >  The current design may make restarting some daemons > di

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

On 18 June 2012 10:50, Alek Paunov wrote: > As I understand the proposal, the necessary workaround only affects the > desktop instances and specifically Gnome ones - I am under the impression > that my servers will continue to be updated by the normal way. Exactly. This will not touch either RHN

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

On 18 June 2012 10:10, Richard W.M. Jones wrote: > I believe there is or was an effort to replace dbus by something > AMQP-based.  However I can't find that right now. The async-message bus isn't the only problem. You *have* to restart a process before it will be running a new library version. Th

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

On 18 June 2012 12:03, Benny Amorsen wrote: > Why testing the daemons? Any daemon which cannot be restarted by > systemctl restart foo.daemon is broken already. Try booting a few VMs and then doing "systemctl restart libvirtd.daemon" -- libvirtd restarts okay (hopefully) but all the clients are d

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

On 18 June 2012 00:38, Reindl Harald wrote: > the point is that it was perfectly possible in 2005 to make a fedora > dist-upgrade at friday night while http, netatalk or samba was > fully up and running until saturday sometimes at evening where > you rebootet the machine and now EIGHT years later

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

On 18 June 2012 15:32, Seth Vidal wrote: > As dbus is required for various things like networkmanager - does this mean > that if a server happens to be using nm for network setup that in order to > apply a security patch to dbus, for example, that the server will require a > reboot? Well, if we t

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

On 18 June 2012 17:36, Reindl Harald wrote: > and now you come the road and thell us firefox can not be > updated while it is running? strange that i apply FF updates > since years in my daily workload and after all are finished the > browser get's restarted or even at the next day if the update >

Re: update installation timing (was Re: Schedule for Monday's FESCo Meeting (2012-06-18))

On 20 June 2012 08:08, Stijn Hoop wrote: > I agree that mind reading computers may not be the final answer... Well, switching to system-update.service from a running desktop should probably kill off everything and start the offline update, so that would be possible with the new scheme too. Richa

Re: update installation timing (was Re: Schedule for Monday's FESCo Meeting (2012-06-18))

On 20 June 2012 12:51, Stijn Hoop wrote: > Good to know, thanks -- although I wonder, in what capacity is this > supported then? Well, I've got no idea if it works at all, let alone if it works well ;) > Would you / others be willing to deal with both update > timings in this Feature? It's not

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

On 22 June 2012 12:40, Michal Hlavinka wrote: > Well, there is difference between inhibited reboot and "are you really sure > you want to reboot and break your system" questions. Is that a joke? [Click here to break your system] is never a good idea. > Anyway, what would happen when user press p

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

On 22 June 2012 13:56, Simo Sorce wrote: > How do we make sure that if package manager goes crazy the user still > have a way to reboot his system that is not 'press power button for 5 > seconds' ? Just make sure the package manager doesn't go crazy. It's just doing a simple rpm transaction after

Re: Schedule for Monday's FESCo Meeting (2012-06-18)

On 22 June 2012 15:27, Lennart Poettering wrote: > a) make a snapshot of the fs, and make it where all changes from now on > are written to, but do not make it the default snapshot to be mounted > for the next boot. > b) make the updates > c) if the update succeeded make the previously created sna

packagekit-glib and packagekit-qt API bump

Hi all, I'm going to build the unstable PackageKit 0.8.1 into rawhide tomorrow. The packagekit-glib and packagekit-qt break ABI, but I'll take care of anything that needs patching / rebuilding. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/l

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

On 14 February 2014 21:43, Przemek Klosowski wrote: > If we are providing a next-generation UI for installing, to replace yum That's not what we're doing. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct:

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

On 17 February 2014 08:45, Christian Schaller wrote: > That said we should list the Developer Assistant in the Software center (or > even have it installed by default) > and that should be the tool IMHO to install these and other developer tools. It's already in the software center (and ships an

Re: gnome-disk-utility orphaned ?

On 17 February 2014 15:45, Hans de Goede wrote: > rhughes just bumped it to 3.11.0, so this is fixed now, I'll go > and close the bug. Actually, mclazy picked it up automatically, I can't claim credit :) Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

On 19 February 2014 18:16, Adam Williamson wrote: > For those > who really want a GUI package installer, the old gpk is still available > in a not-installed-by-default package (though I assume Richard will > eventually drop it), and yumex is always an option. There are quite a few distros that ha

Re: Heads up; F22 will require applications to ship appdata to be listed in software center

On 20 February 2014 17:44, Adam Williamson wrote: > You get all the disadvantages of complexity with none of the benefits of > simplicity. "Jack of all trades, master of none". Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fe

Re: libgcrypt soname bump in rawhide

On 28 February 2014 15:38, Tomas Mraz wrote: > This should not break builds of any reasonably current software. libgcrypt.so.11()(64bit) is needed by (installed) google-chrome-stable-33.0.1750.117-1.x86_64 I guess not much we can do there, other than maintain a compat package -- right? :( Richa

Re: libgcrypt soname bump in rawhide

On 28 Feb 2014 19:51 > OTOH important libraries that still break soname instead of using symbol > versioning in 2014 really make me frown loudly.. Is there a best practice guide here? I'm guilty of breaking soname in my stuff every few years... Richard -- devel mailing list devel@lists.fedorapro

Proposal: Don't show applications in the software center with XPM icons

XPM is an old standard for icons used by a very small number of desktop packages in Fedora. The XPM icons are normally small, mostly 8 bit, and usually without an alpha channel and look very bad in the software center. I'm going to propose for F21 that we drop support for XPM in the metadata extra

Re: Proposal: Don't show applications in the software center with XPM icons

On 6 March 2014 18:51, Tim Lauridsen wrote: > Not showing app, because they have bad looking icons, seems like a bad idea > to me. I'm not sure anyone will be surprised in my goal of making the applications we show users have high quality content. XPM icons are a good first step, then it'll be th

Re: Proposal: Don't show applications in the software center with XPM icons

On 7 March 2014 11:42, Petr Pisar wrote: > GIF is an old standard for icons used by a very small number of > desktop packages in Fedora. Also valid. The *two* applications in Fedora using gif icons are asymptote and imagej. Richard -- devel mailing list devel@lists.fedoraproject.org https://adm

Re: Proposal: Don't show applications in the software center with XPM icons

On 7 March 2014 11:57, Tim Lauridsen wrote: > what will be the next ? qt apps ? gtk2 apps No, because that would be ridiculous. Hiding applications using GTK1 would of course be okay. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/d

Re: Proposal: Don't show applications in the software center with XPM icons

On 7 March 2014 14:08, Michael Catanzaro wrote: > Microsoft, Apple, and Google set requirements that apps must follow if > they want to appear in the software center in order to ensure a good > user experience. This is something I absolutely want to do. We already rate the applications in GNOME 3

Re: Read this if your package includes a status notifier / system tray icon

On 8 March 2014 17:55, Kevin Kofler wrote: > To properly integrate with the other desktops, GNOME has no other choice but > to implement that spec I'm not sure that's a terribly convincing argument. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mai

Re: Proposal: Don't show applications in the software center with XPM icons

On 7 March 2014 16:21, Richard Hughes wrote: > On 7 March 2014 14:08, Michael Catanzaro wrote: >> Microsoft, Apple, and Google set requirements that apps must follow if >> they want to appear in the software center in order to ensure a good >> user experience. > This i

AppStream Logs and False Positives

Quite a few people have asked me how the AppStream distro metadata is actually generated for their package. Since F20 we're also doing things like supply missing AppData files for some key apps, and replacing some upstream screenshots on others. In order to make this more transparent, I'm going to

Re: AppStream Logs and False Positives

On 24 March 2014 17:15, Jerry James wrote: > Am I taking a fundamentally wrong approach, or does something in the appdata > stack need to be taught about file:// URLs? Are you installing them with the package? I guess file:// could make sense, so if that's what you're doing can you file a bug in

Re: AppStream Logs and False Positives

On 24 March 2014 19:01, Jerry James wrote: > Thank you, I appreciate the offer. However, I think I'm going to use my > fedorapeople.org space for this purpose. Hopefully it won't be needed for > long, anyway (/me crosses fingers). Yes, I think fedorapeople.org is fine for this; like I said it's

Re: systemd bugs in F20/F21 -> bug against the distribution?

On 3 April 2014 20:00, Adam Jackson wrote: > We didn't, and no justification would matter. It's not acceptable > behaviour, and you need to knock it off. I'm not the only developer considering unsubscribing from fedora-devel because of emails like the original email. Either the moderators start

Re: appdata handling

On 13 April 2014 13:21, Markus Mayer wrote: > What I'm interested in is: > - Directory, Name, ownership and permissions for appdata.xml files Just the default permissions and groups are required, no special handling. > - %post/%postun scriptlets (if needed) Nope, none. > - If appdata-validate

Re: appdata handling

On 14 April 2014 21:10, Bill Nottingham wrote: > "How do I locally check changes to my appdata inside gnome-software, as > opposed to just appdata-validate?" Now it's a case of cloning and building https://github.com/hughsie/createrepo_as and then doing ./createrepo_as --basename=test path/to/pac

Re: appdata handling

On 14 April 2014 21:46, Richard Hughes wrote: > You are an early adopter; somewhat simpler now :) Okay, since this morning: createrepo_as --basename=test path/to/package.rpm sudo appstream-util install test.xml.gz test-icons.tar.gz I'll get a new appstream-glib release out at the en

Re: F21 Self Contained Change: libzhuyin

On 15 April 2014 12:25, Jaroslav Reznik wrote: > ** Package ibus-libzhuyin in Fedora Can this also get an AppData file also, so it appears in GNOME Software. Thanks, Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code o

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

On 30 April 2014 15:52, Kalev Lember wrote: > Getting rid of the copy-pasted rpm scriptlets would be a huge win. Totally agree. We should make this happen. SUSE has been doing it for years. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listi

Re: Computational chemistry softwares orphaned in F20

On 16 May 2014 00:53, Henrique Junior wrote: > Too bad I don't have the time to be a packager anymore... If anyone does pick this up, ghemical needs an AppData file: https://github.com/hughsie/createrepo_as_logs/blob/master/ghemical/ghemical-2.99.2-24.fc20.log Richard -- devel mailing list deve

New gettext in Rawhide causing builda failures?

I'm trying to build a new upstream release of gscan2pdf -- but a lot of other upstream software also looks affected, this is the build failure: /usr/bin/perl -MExtUtils::Command -e 'mkpath' -- /builddir/build/BUILDROOT/gscan2pdf-1.2.5-1.fc21.noarch/usr/share/locale/ab/LC_MESSAGES msgfmt -c po/gsca

Re: New gettext in Rawhide causing builda failures?

On 2 June 2014 10:02, Daiki Ueno wrote: > However, the non-warning errors have been there for a long time. Isn't > it time to fix them? If this is really too strict, we can revert this > in the next minor release and advise users until the next major release. I think quite a lot of software wil

Re: New gettext in Rawhide causing builda failures?

On 2 June 2014 11:23, Daiki Ueno wrote: > I see. So, just applied a patch to turn the missing-header errors into > warnings (should be available as 0.19-2). Works great, thanks! Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Slipping F21 (was: Schedule for Wednesday's FESCo Meeting (2014-06-11))

On 11 June 2014 15:56, Kalev Lember wrote: > With my Workstation WG hat on, I'd very much like to avoid pushing back > the schedule. We already skipped one whole release; if we slip F21 it's > going to negatively impact how users perceive the Workstation, and make > it harder for Workstation devel

Metainfo files for addons/plugins/extensions that extend desktop applications

Recently I added the addon component type to AppStream[1] which is an XML standard that is used by Fedora and lots of other distros to create metadata for various software center applications such as GNOME Software and KDE's Apper. By creating a metainfo.xml for each plugin, these are then shown n

<    1   2   3   4   5   6   7   >