Re: fedpkg import weirdness
I read a bit of code and thus replying to my own message. It seems rpkg decides whether to upload a file to the lookaside cache or not based on running "file -b --mime-encoding" on it. For a keyring file that returns "binary". See https://pagure.io/rpkg/blob/master/f/pyrpkg/utils.py#_280 -Ville-Pekka ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
fedpkg import weirdness
Hi, I imported a new package called voikko-fi yesterday. I think I hit a bug in fedpkg, but I'm not sure. The packaging guidelines say "Any detached signature file (e.g. foo.tar.gz.asc or foo.tar.gz.sig) must be uploaded to the package lookaside cache alongside the source code, while the keyring must be committed directly to the package SCM." I think fedpkg import did this the other way around. The keyring (called gpgkey-AC5D65F10C8596D7E2DAE2633D309B604AE3942E.gpg) was uploaded to the lookaside cache. The signature file (called voikko-fi-2.4.tar.gz.asc) was about to be committed to git. I fixed things manually as much as I could. I don't have the shell history available anymore and I may have made an error somewhere myself. I have not looked at the fedpkg source code yet, it'd be interesting to know how to test the import again without breaking anything. -Ville-Pekka ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Review swap: voikko-fi (for Finnish spell-checking)
Hi all, This work is finally done and the packages are in Rawhide, in good time before the beta. Thank you Miro and Zbyszek! I think I found a fedpkg import bug while importing voikko-fi from SRPM, I'll make a new thread about that. -Ville-Pekka ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Review swap: voikko-fi (for Finnish spell-checking)
Hi, This is a re-review for a rename and going from arch-specific to noarch: https://bugzilla.redhat.com/show_bug.cgi?id=1919688 The arch-noarch stuff was discussed here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JSEYB5XU24HEX7BR2QVJ732MR5P52YJ6/ Voikko 4.3, which is needed to build this, is not yet in Rawhide. I'll push it as soon as someone commits to working on this review. Pushing Voikko 4.3 to Rawhide will break Finnish spell-checking until this package is in Rawhide as well. The best packages for me to review would probably be autotools-based C/C++ stuff and Python stuff. I usually have time for Fedora work only during weekends. -Ville-Pekka ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How to properly go from arch-specific to noarch? (Finnish spell-checking)
On Wed, 20 Jan 2021 at 00:12, Zbigniew Jędrzejewski-Szmek wrote: > If the files are not arch-specific, just override the location to be > always /usr/lib/voikko. Pedantically speaking, this is not exactly following > the FHS, but it's easiest to follow upstream here. The difference between > /usr/lib and /usr/share is unimportant. Thanks. My review request is here: https://bugzilla.redhat.com/show_bug.cgi?id=1919688 I'll make a new mailing list post about a review swap if there aren't other review swap requests currently open in the latest posts on the list. -Ville-Pekka ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How to properly go from arch-specific to noarch? (Finnish spell-checking)
Thanks, Zbyszek!
I just realised one thing, which may affect the arch/noarch question.
Upstream prefers to place the data files under /usr/lib/voikko. Of
course, in a 64 bit system this would be /usr/lib64/voikko. But if I
make the package noarch, %{_libdir} will change depending on the
architecture of the system, which builds the package. So, should I
just make the package arch-specific anyway or try to come up with
another location for the data files? Logically, it could be
%{_datadir}. I'll need to test that the code actually works, if I use
that.
On Sun, 17 Jan 2021 at 13:58, Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Sun, Jan 17, 2021 at 12:12:19PM +0200, Ville-Pekka Vainio wrote:
> > %define debug_package %{nil}
> Looks iffy. Shouldn't your package have BuildArch:noarch? This should
> not be necessary once you add BuildArch:noarch.
You're right. This was a workaround I used in the older package, when
it needed to be arch-specific.
> > URL:http://voikko.puimula.org
> No https?
Good point. They do use HTTPS these days, I'll change the URL.
> > make vvfst
> %make_build vvfst ?
Seems to work, I'll use that.
-Ville-Pekka
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
How to properly go from arch-specific to noarch? (Finnish spell-checking)
Hi, I am working on updating the Finnish spell-checking stack to the current upstream versions. Currently Fedora has the malaga-suomi-voikko package, which is arch-specific. For example, my own system has malaga-suomi-voikko-1.19-12.fc33.x86_64 installed. In upstream, the successor of this package is called voikko-fi and according to the upstream developers the data files are not arch-specific anymore. My WIP spec file is at https://vpv.fedorapeople.org/packages/voikko-fi.spec How should I handle Obsoletes and possibly Provides in this case? Do I just do Obsoletes: malaga-suomi-voikko < 1.19-13 and that's it? I am close to submitting this package for review and would take review swaps as well. This package is basically the only blocker left, the others are relatively simple version updates that I should be able to manage by myself. -Ville-Pekka ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Flatpak and __pycache__
Hi,
I'm slowly working on reviving the Finnish spell-checking stack. When
working on the libvoikko package, I noticed the Python module now has
this in the file list:
%if ! 0%{?flatpak}
%{python3_sitelib}/__pycache__/*
%endif
Git blame takes me to this commit:
https://src.fedoraproject.org/rpms/libvoikko/c/e1b9941462b82f208b814fc2f6e7f369bcda11a0?branch=master
Apparently Flatpak could not handle __pycache__ stuff about six months ago.
According to the packaging guidelines I should be using something like
%pycached %{python3_sitelib}/%{name}.py
This macro is defined in /usr/lib/rpm/macros.d/macros.python3 and it
seems like it does not take the Flatpak issue into account.
Should I just leave those lines as they are? Should the %pycached
macro be improved?
Ville-Pekka Vainio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaning vdr-skinsoppalusikka and the status of my packages (looking for co-maintainers for Finnish spell checking)
Hi, Just letting people know that I was able to fix the foma build. A review request for unretiring the package is at https://bugzilla.redhat.com/show_bug.cgi?id=1885048 I could do a review swap for a python package, a simple autotools-based package or something like that. -Ville-Pekka ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaning vdr-skinsoppalusikka and the status of my packages (looking for co-maintainers for Finnish spell checking)
Hi all, As some of you may have noticed, I have been away from Fedora packaging for quite a while. I've been hoping to find the time for packaging work, but it hasn't happened. In hindsight, I should have let the project know earlier. I have now orphaned vdr-skinsoppalusikka, because I don't have a working VDR installation anymore. If someone has the ability, my user (vpv) can be dropped from the packages vdr, vdr-epgsearch, vdr-femon and vdr-osdteletext. My main interest in Fedora packaging used to be Finnish spell checking. The spell checking stack, consisting of libreoffice-voikko, libvoikko, voikko-fi and foma (as a dependency) went through quite major changes in 2017-2019. The vocabulary package voikko-fi requires foma to build. I managed to get the foma package reviewed and into Fedora in 2018. It was automatically orphaned and then retired due to FTBFS (https://src.fedoraproject.org/rpms/foma). The code has now been fixed in Github (https://github.com/mhulden/foma) and it should build, but I haven't tried it yet. If I get it to build, I might ask for it to be added back. It seems like I'll be able to work on packaging for a few days a year, so don't expect any miracles. Once foma is built, voikko-fi can be built. Even though it shares some history with the previous vocabulary package malaga-suomi-voikko, it probably needs a new review. Then libvoikko could be updated to use the new vocabulary. If anyone is interested in working on these, I would be happy to get co-maintainers. I'm willing to stay as a co-maintainer of gpodder and python-mygpoclient. I code Python at $DAYJOB so I might be able to help. Best regards, Ville-Pekka Vainio (vpv) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Resurrecting an old review request
Hi! After a break I've gotten back to Fedora packaging. Two years ago I took an attempt at packaging foma (https://github.com/mhulden/foma) but I never finished the work. I think I've now fixed all of the issues pointed out in the review. The new spec and SRPM are here: https://bugzilla.redhat.com/show_bug.cgi?id=1357110#c2 The review request was closed WONTFIX (rightly so), can I just reopen it? Anyone interested in reviewing it again? The point of getting foma into Fedora is to be able to package voikko-fi, the new version of the Finnish spell checking dictionary. After having gone through two of the most stressful years of my life thus far, I've decided to only work on Fedora during the weekends for now. Just letting you know in case my replies take some time. Ville-Pekka ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YNE5X6TPS77RZDO4JAYPT67YMC7WR7NE/
Re: About to orphan python-pymtp
On Fri, 3 Aug 2018 at 22:40, Ville-Pekka Vainio wrote: > Anyone interested in maintaining this package? Orphaned now. Ville-Pekka ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OUHAEGERAIJSCFYMPMF7DC75DQNY3EOM/
Orphaning vdr-tvonscreen
Hi! The vdr-tvonscreen plugin has not been maintained upstream in years. I don't use it anymore and don't have the motivation to fix it against new versions of VDR. I'm orphaning it now. If anyone wants to maintain it, the trick for getting the newest code is git clone --depth=1 git://projects.vdr-developer.org/vdr-plugin-tvonscreen.git tvonscreen as even the git repository is corrupted. Ville-Pekka ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OGANTGH5346MCACMMSEKTEFI2Z4YEQCA/
About to orphan python-pymtp
Hi! In light of the recent FTBFS reports, I would like to orphan python-pymtp, because I haven't used it in a while. There's one other maintainer called "snirkel", sending this email to them as well. Anyone interested in maintaining this package? Ville-Pekka Vainio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/THUC24BZFWFCDVKYJEQGLRC4MTDMGEAW/
Review swap: foma (rebasing Voikko, the Finnish spell-checking stack)
Hi all, I've been away from Fedora for a while and during my absence the Finnish spell-checking stack called Voikko has gone through major changes. I've started the work to rebase the packages in Rawhide to the newest upstream versions. The Finnish dictionary is now using the new VSFT format and needs foma to be built. That's why I'm starting with the foma package. The bug report is here: https://bugzilla.redhat.com/show_bug.cgi?id=1357110 There's also a COPR for this work: https://copr.fedorainfracloud.org/coprs/vpv/Voikko-4.0/ I'm willing to do a review swap, preferably C/C++ or Python stuff. -- Ville-Pekka Vainio -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
I've orphaned moin in all branches
Hi all! Due to having less time available for Fedora than I used to, I have decided to orphan the moin package, i.e. the MoinMoin wiki engine, in all branches. If someone wants to pick it up, there's not that much work to be done right now. It needs an update from 1.9.7 to 1.9.8, and maybe someone should go through the CVEs to see if there are unhandled security issues. In the long term it's unfortunately obvious that I won't be the best person to maintain a server package which eventually will have more security issues. -- Ville-Pekka Vainio -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Help needed with gpodder
Hi, I've had less time to work on Fedora packages this year than usually. A bug filed against gpodder lately made me realize this and I would appreciate some help. I am not even the main maintainer, Jef Spaleta is, but I used to keep an eye on gpodder because I like it and use it myself. The bug report is this: https://bugzilla.redhat.com/show_bug.cgi?id=1217061 Apparently an update to sqlite broke gpodder on Fedora 20 and now it does not even start. Could someone test the patch in the bug report and build an update with it for Fedora 20 if it solves the problem? -- Ville-Pekka Vainio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Libreoffice-voikko licensing change
Hi, The licensing guidelines say that license changes should be announced on this list. In version 4.0 libreoffice-voikko changed from GPLv3+ to dual licensing, GPLv3+ or MPLv2.0. Libreoffice-voikko 4.0 requires libvoikko 3.7 which I built today, so it should be in tomorrow Rawhide compose. I will build libreoffice-voikko 4.0 some time next week. -- Ville-Pekka Vainio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Packaging a Firefox extension
Hi,
I'm maintaining the Finnish spell checking extension for Firefox called
Mozvoikko. Upstream recently released a Javascript-based version of the
extension, which I've now packaged in Rawhide. Spec file here:
http://pkgs.fedoraproject.org/gitweb/?p=mozvoikko.git;a=blob;f=mozvoikko.spec;h=64fec9a734bc554e44c08ed0e88379a0dc220ebb;hb=HEAD.
Xulrunner maintainers, would you like me to push this new version to
F-16 and F-15 as well? It would not need to be rebuilt every time
Xulrunner is updated, but of course there is some risk in doing updates
like this in stable releases.
For now, I've only packaged the extension for Firefox, but I would like
to add Thunderbird support as well. What would be the best way to do
that? I could probably symlink the extension directory from
%{_datadir}/mozilla/extensions/%{firefox_app_id}/%{mozvoikko_ext_id} to
%{_datadir}/mozilla/extensions/%{thunderbird_app_id/%{mozvoikko_ext_id}
but are directory symlinks still probalematic for RPM? Should I just
copy all the files to Thunderbird's extension directory too, to avoid
the symlinking?
--
Ville-Pekka Vainio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Problems with the %{?_isa} macro in dependencies
Hi,
I have tried using the %{_isa} macro in a couple of my packages as
instructed in
http://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires
and I'm having problems with it.
First case:
The arch-specific libvoikko spell checking package requires the Finnish
morphology, which is in the arch-specific malaga-suomi-voikko package. I
did the following change (the versioned dependency was unnecessary):
-Requires: malaga-suomi-voikko = 1.4
+Requires: malaga-suomi-voikko%{?_isa}
Now AutoQA's depcheck says there is a problem with the i686 dependency
on x86_64:
http://autoqa.fedoraproject.org/results/198794-autotest/10.5.124.164/depcheck/results/libvoikko-3.3.1-0.2..html
SKIPBROKEN: libvoikko-3.3.1-0.2.rc1.fc16.i686 from pending has
depsolving problems
SKIPBROKEN: -- Package: libvoikko-3.3.1-0.2.rc1.fc16.i686 (pending)
-- Requires: malaga-suomi-voikko(x86-32)
Second case:
I'm renaming the openoffice.org-voikko package to libreoffice-voikko.
Review request: https://bugzilla.redhat.com/show_bug.cgi?id=739331,
spec: http://vpv.fedorapeople.org/packages/libreoffice-voikko.spec.
The Provides and Obsoletes are as follows:
Provides: openoffice.org-voikko = %{version}-%{release}
Obsoletes:openoffice.org-voikko 3.1.2-6
This works, but if I change the Obsoletes to
Obsoletes:openoffice.org-voikko%{?_isa} 3.1.2-6
then the package does not obsolete openoffice.org-voikko any more, which
results in file conflicts.
Could someone please explain what's going on here?
--
Ville-Pekka Vainio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problems with the %{?_isa} macro in dependencies
Thanks for the advice! I've made a libvoikko build without the %{_isa}
macro in the malaga-suomi-voikko dependency.
--
Ville-Pekka Vainio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Package rename review request: libreoffice-voikko
Hi, I finally had the time to package the updated and renamed version of the Finnish spell-checking extension for LibreOffice and OpenOffice.org, libreoffice-voikko. The review request is here: https://bugzilla.redhat.com/show_bug.cgi?id=739331 . I also CC'd libreoffice-owner, maybe the LibreOffice maintainers would be interested in reviewing this. I could probably do a review swap as well. -- Ville-Pekka Vainio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swap (help gPodder packaging)
Hi all, I'd like to swap reviews, my package: https://bugzilla.redhat.com/show_bug.cgi?id=643199 python-pymtp - A Pythonic wrapper around libmtp A bit of background for this one: I'm a co-maintainer of the gpodder package, though I've been doing most of the work for that package lately. A couple of minor versions back, gPodder grew a dependency on pymtp in a way that we'll either need to have pymtp in Fedora or patch gPodder in a way which includes changing UI strings. The latter would be bad wrt translations. If I could get pymtp into Fedora, I could push updated gPodder packages into the current releases. The minor upstream releases have mostly been bugfixes and would probably be useful for our users. I'd appreciate a relatively easy package to review, I haven't been doing reviews for a while... -- Ville-Pekka Vainio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
Hi,
My package malaga was on your list. Here are the %files entries:
%files
%defattr(-,root,root,-)
%{_infodir}/%{name}*
%{_bindir}/mal*
%{_datadir}/%{name}
%{_mandir}/man1/mal*
%files -n lib%{name}
%defattr(-,root,root,-)
%doc CHANGES.txt GPL.txt README.txt
%{_libdir}/lib%{name}.so.*
So libmalaga already contains the license text and malaga requires
libmalaga. This package should be fine.
--
Ville-Pekka Vainio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
pe, 2010-03-12 kello 15:20 -0800, Jesse Keating kirjoitti: Keeping that cutting-edge release practice, but adding to that stability once released would indeed be a very unique and desirable niche for Fedora to fill. I've avoided participating in these threads, since I don't really want to feed a flame war, but now I'll mention that this is something I'd like Fedora to be. I mostly use and contribute to Fedora because it's an RPM/Red Hat style distribution with a strong emphasis on community contributors, free software and upstream. As Fedora is the distribution I'm most familiar with, I've also installed it on some of my family members' systems but lately I've been considering switching those to Ubuntu once the new LTS release comes out. I've taught these people how to update their systems, but I'm always a bit worried that the adventurous updates are going to break something they need to do their daily computing. I have no problem with the new releases being leading edge, I actually quite like that. I can always put the new release onto a USB stick and test that the important stuff is working on a particular system before upgrading, especially since I upgrade other people's systems about once a year, when the old release becomes EOL. But I can't do this sort of testing for the updates being pushed to the stable releases, so I'd like to be able to trust those not to break things, at least to some extent. -- Ville-Pekka Vainio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Asking for help with translations missing from .desktop files (gnome-packagekit)
Hi, I'm asking for help in finding out what might cause bug https://bugzilla.redhat.com/show_bug.cgi?id=557082 - Menu item translations go missing intermittently in different gnome-packagekit builds. In nearly every build of gnome-packagekit some .desktop file is left with no translations at all, but this varies between .desktop files, builds and architectures. If we look at gnome-packagekit-2.29.4-0.1.20100211git.fc13, which is the newest koji build, in x86_64 gpk-log.desktop and gpk-repo.desktop have no translations and in i686 gpk-prefs.desktop has no translations. I have no idea what the problem is and against which package it should actually be reported. Could someone familiar with the .desktop file magic and GNOME i18n have a look? -- Ville-Pekka Vainio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
