Re: python-SocksiPy (was: Re: non-responsive)
On Wed, 18 Jul 2012 18:29:03 +0100 "Richard W.M. Jones" wrote: > On Mon, Jul 16, 2012 at 09:12:42PM +0400, Fl@sh wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=831743 > > > > Maybe anyone knows how to contact the maintainer? (His mail > > is not answer.) > there is still no answer -- Fl@sh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
- 元のメッセージ - | On 07/24/2012 11:35 AM, Kevin Kofler wrote: | > I don't understand this feature at all! Freetype already uses | > auto-hinting | > for fonts which do not provide hinting data, in fact that was one | > of the | > prerequisites for enabling the bytecode interpreter in Fedora, and | > I cherry- | > picked the relevant change from the huge Infinality patchset and | > got it | > upstreamed. Forcing auto-hinting for all fonts effectively means | > disabling | > the bytecode interpreter by default, which is surely not a good | > idea. | | It also turns every font into a blurry mess. This is not a subjective | opinion. Run the listed command on the Feature Page for DejaVu and | Liberation fonts (two of the biggest free fonts). With the current | free-type environment you have crisp, clean fonts. Enable | auto-hinting | and every character becomes blurred including a simple exclamation | mark | that is a single line of pixels. I admit simply enabling force-auto-hinting isn't enough. we definitely need to optimize a lot to make it more better. in fact there are the case auto-hinting gives much better than BCI-hinting. that may implies there may be more cases to be improved. as you guys are looking at your monitor daily-basis, if something goes wrong, it's easy to realize what's improved and what's worse. isn't this feature a good idea to get such feedback? If there are any commonly applicable rules, it should be done in the system wide way, I mean in fontconfig. otherwise need to do it in the specific way, in the fonts packages. | | It is unfortunate FESCo members blindly +1'd this feature without a | bit | of evidence or thought. Yes, I read the meeting log. It took just | three | minutes to pass. | | Do I need to file a ticket to get this feature revoked? | -- | devel mailing list | devel@lists.fedoraproject.org | https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
emacspeak: hearing for a new owner
Hi, For a long time - well since pre-Fedora history ;) - I have maintained the emacspeak package (see https://code.google.com/p/emacspeak/). In the past I generally found time to update it for each Fedora release (it is not really much work) but I don't actually use it myself at all or have the hardware to test (ever) so I think it would be better if someone else interested would take over the package. Or maybe noone really uses it in Fedora? (I just updated it in rawhide for the first time since end of 2008 without a single bug report! oops - did anyone notice? :) and also just added it to URM now so hopefully it can be kept more up to date. So does anyone use it? Is anyone keen to maintain it? I can still help to maintain it a bit longer but if noone is really using it maybe better to orphan? I would appreciate a CC if you reply since I sometimes miss devel list. Thanks, Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Search all spec files for a %post changing /etc/lvm/lvm.conf?
https://bugzilla.redhat.com/show_bug.cgi?id=843013 We think that a spec file in Fedora might have tried to edit /etc/lvm/lvm.conf in a %post script. Unfortunately there's quite a large list of candidate packages. Any suggestions for grepping all or a large number of Fedora spec files? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Search all spec files for a %post changing /etc/lvm/lvm.conf?
On Wed, Jul 25, 2012 at 11:53:24AM +0100, Richard W.M. Jones wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=843013 > > We think that a spec file in Fedora might have tried to edit > /etc/lvm/lvm.conf in a %post script. Unfortunately there's quite a > large list of candidate packages. dracut? http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut/dracut;a=commitdiff;h=0fae59d6eb3039628df1413a1007c5b8fe15c9c5 -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Search all spec files for a %post changing /etc/lvm/lvm.conf?
On Wed, Jul 25, 2012 at 12:59:05PM +0200, Tomasz Torcz wrote: > On Wed, Jul 25, 2012 at 11:53:24AM +0100, Richard W.M. Jones wrote: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=843013 > > > > We think that a spec file in Fedora might have tried to edit > > /etc/lvm/lvm.conf in a %post script. Unfortunately there's quite a > > large list of candidate packages. > > dracut? > http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut/dracut;a=commitdiff;h=0fae59d6eb3039628df1413a1007c5b8fe15c9c5 Yes indeed .. That is the Rawhide machine that had a bit of a dracut upset a few weeks ago. Thanks, Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v3] Retiring packages for F-18
Bill Nottingham writes: > Before we branch for Fedora 18, as is custom, we will block currently > orphaned packages and packages that have failed to build since Fedora 16. > > The following packages are currently orphaned, or fail to build. If > you have a need for one of these packages, please pick them up. > If no one claims any of these packages, they will be blocked before > we branch for Fedora 18. That is currently scheduled to happen on > or around August 7th. > > Note that if you're receiving this mail directly, it's because you are > a co-maintainer of one of these packages. Please work with your > comaintainers to take up maintenance. there is missing orphaned iptraf. please get rid of it from f18. -- Nikola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Object-InsideOut] Update to 3.95
commit 8ac3e07aab7c0c8699d4ef54aa822f8acaf374df
Author: Jitka Plesnikova
Date: Wed Jul 25 14:29:23 2012 +0200
Update to 3.95
.gitignore |1 +
perl-Object-InsideOut.spec |7 +--
sources|2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 7ffab3d..2fe073f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -9,3 +9,4 @@ Object-InsideOut-3.56.tar.gz
/Object-InsideOut-3.92.tar.gz
/Object-InsideOut-3.93.tar.gz
/Object-InsideOut-3.94.tar.gz
+/Object-InsideOut-3.95.tar.gz
diff --git a/perl-Object-InsideOut.spec b/perl-Object-InsideOut.spec
index 7fb0f86..428921d 100644
--- a/perl-Object-InsideOut.spec
+++ b/perl-Object-InsideOut.spec
@@ -1,6 +1,6 @@
Name: perl-Object-InsideOut
-Version:3.94
-Release:4%{?dist}
+Version:3.95
+Release:1%{?dist}
Summary:Comprehensive inside-out object support module
Group: Development/Libraries
License:GPL+ or Artistic
@@ -77,6 +77,9 @@ make test
%changelog
+* Wed Jul 25 2012 Jitka Plesnikova - 3.95-1
+- 3.95 bump
+
* Fri Jul 20 2012 Fedora Release Engineering
- 3.94-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
diff --git a/sources b/sources
index d31b91f..79abc7d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2e4609371d9f9950f6835ba2bcf7a964 Object-InsideOut-3.94.tar.gz
+7244317f2c509871335429e6eb22e905 Object-InsideOut-3.95.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [ACTION REQUIRED v3] Retiring packages for F-18
On Tue, Jul 24, 2012 at 9:04 PM, Bill Nottingham wrote: > Tom Lane (t...@redhat.com) said: >> Bill Nottingham writes: >> > Before we branch for Fedora 18, as is custom, we will block currently >> > orphaned packages and packages that have failed to build since Fedora 16. >> >> > The following packages are currently orphaned, or fail to build. >> > [snip] >> >> That list seems seriously incomplete. I'm aware of at least these >> others that have FTBFS in both F17 and F18 mass rebuilds, as evidenced >> by their release tags: > > It's done by basing off of the F16FTBFS bug, as that's the easiest source > of info when we haven't done a mass rebuild. > > We could include everything with older dist tags. Looking at it, that would > be 78 more packages. It would be nice to get rid of anything that's FTBFS in non supported Fedora (ie at least < fc16) and the last time I looked at that there's a good 150 odd packages that are fc15 or older packages. There's been two mass rebuilds since then and if the package maintainers haven't managed to fix them (or they've not been fixed by people like secondary arches that fix them because they're blocking their builds) the package maintainer is either AWOL or not doing their job of maintaining packages or even bothering to check failure emails so it's likely better off for Fedora that they're scrapped as well. I think in the F17 cycle I fixed over 100+ of these packages. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v3] Retiring packages for F-18
On Wed, Jul 25, 2012 at 1:44 PM, Peter Robinson wrote: > On Tue, Jul 24, 2012 at 9:04 PM, Bill Nottingham > wrote: > > Tom Lane (t...@redhat.com) said: > >> Bill Nottingham writes: > >> > Before we branch for Fedora 18, as is custom, we will block currently > >> > orphaned packages and packages that have failed to build since Fedora > 16. > >> > >> > The following packages are currently orphaned, or fail to build. > >> > [snip] > >> > >> That list seems seriously incomplete. I'm aware of at least these > >> others that have FTBFS in both F17 and F18 mass rebuilds, as evidenced > >> by their release tags: > > > > It's done by basing off of the F16FTBFS bug, as that's the easiest source > > of info when we haven't done a mass rebuild. > > > > We could include everything with older dist tags. Looking at it, that > would > > be 78 more packages. > > It would be nice to get rid of anything that's FTBFS in non supported > Fedora (ie at least < fc16) and the last time I looked at that there's > a good 150 odd packages that are fc15 or older packages. There's been > two mass rebuilds since then and if the package maintainers haven't > managed to fix them (or they've not been fixed by people like > secondary arches that fix them because they're blocking their builds) > the package maintainer is either AWOL or not doing their job of > maintaining packages or even bothering to check failure emails so it's > likely better off for Fedora that they're scrapped as well. I think in > the F17 cycle I fixed over 100+ of these packages. > It would probably help to keep track of the problem if we could manage to get back the FTBFS bugs. I don't know if there is some work done on this but it would definitely help with this issue. Johannes > > Peter > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 updates broke anaconda PNG image handling
On Tue, Jul 24, 2012 at 06:46:42PM -0700, John Reiser wrote: > > ... the gist of the problem is that /usr/share/mime/mime.cache was not > > retained > > in the squashfs.img , so mime was not able to tell what the file was. > > > http://git.fedorahosted.org/cgit/lorax.git/commit/?id=3636fd58146768b07f8814d4aeab395876d93a82 > > that has the fix. > > That works for me. Apply the fix to the /usr/share/runtime-cleanup.tmpl > of the box which runs pungi, and exclude systemd-44-8.fc17.x86_64 > and systemd-sysv-44-8.fc17.x86_64 from the updates. My resulting DVD > boots, gives a shell on VT2 immediately, and does not get the Python > traceback (does display .png correctly.) Works for me too, so I just submitted a bug for lorax: https://bugzilla.redhat.com/show_bug.cgi?id=843062 Note that my install now fails when installing the kernel, because grub2-install can not be found. I have to find out if this is an user error (I only included @Base in my test install DVD) or that this is something more serious. If the kernel needs grub2-install, it should Requires(post) that, isn't it? It obviously doesn't... -- --Jos Vos --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Akira TAGOH wrote: > I admit simply enabling force-auto-hinting isn't enough. we definitely > need to optimize a lot to make it more better. The FreeType autohinter has been developed for years, leading to what we have now. It is totally unreasonable to expect to be able to "optimize" it in the time frame of a single release. It should also be quite expected that using the hinting information provided by the fonts will necessarily lead to better hinting than not using it. > in fact there are the case auto-hinting gives much better than > BCI-hinting. Those are broken fonts (they probably ship hinting information only for selected glyphs and leave the others entirely unhinted), and we should force autohinting manually for those fonts. > that may implies there may be more cases to be improved. as you guys are > looking at your monitor daily-basis, if something goes wrong, it's easy to > realize what's improved and what's worse. isn't this feature a good idea > to get such feedback? NO! We have had autohinting by default for years, back when the BCI was patented. It has NOT lead to the kind of improvements you seem to be expecting, and in fact it was common practice to rebuild FreeType with the BCI enabled (or use the freetype-freeworld package which did that; these days, the only remaining difference between freetype and freetype-freeworld is subpixel rendering). Why should it work any better now? The BCI patent has finally expired, we have finally been able to enable the BCI in Fedora, and now you propose to move back. This is not a constructive proposal. > If there are any commonly applicable rules, it should be done in the > system wide way, I mean in fontconfig. otherwise need to do it in the > specific way, in the fonts packages. Doing it per font is the right solution if individual fonts don't work properly with the BCI. Normally, fonts which provide hinting bytecode expect it to be used! (And for those which don't provide any hinting bytecode, FreeType already automatically falls back to autohinting. I personally ensured this.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [389-devel] SSO to 389 Server from 389 Client
Hi,
don't forget either to
* add on the client workstation the CA certificate that signed the LDAP
server certifcate to /etc/openldap/ldap.conf (TLS_CACERT parameter)
* or to disable the certificate check: ("TLS_REQCERT never")
You can easily test fro the client whethe rit worked or not :
ldapsearch -x -H ldaps://your.ldap.server.example.com -b "" -s base
if the result of this command is the follwoing error then you have not
configured the CA on the workstation correctly:
ldap_bind: Can't contact LDAP server (-1)
additional info: error:14090086:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Otherwise you will have the DSE base attributes...
@+
2012/7/25 Chaudhari, Rohit K.
> Hello everyone,
>
> The setup is as follows. We have set up a server with 389 DS without DNS
> (hardcoded IP addresses in /etc/hosts) and created a CA certificate for
> distribution on servers and clients. The 389 client has been set up to
> allow users created on the server to authenticate against LDAP when logging
> in for the first time. However, this is failing.
>
> The server has 389 and a CA certificate.
> The client is given the CA certificate as certificate.asc. Then, we used
> authconfig-tui to configure the client to use LDAP authentication against
> the server using TLS/SSL.
>
> In regards to a previous thread, one had brought up that there might be
> issues using LDAP authentication with TLS if the server is set up without
> DNS and has IP addresses hard-coded in /etc/hosts. Does anyone have any
> suggestions as to why I am unable to log in against the server from my
> client machine. The user created in LDAP is given POSIX attributes so that
> if it's a user attempting to log in for the first time, it is able to do so
> (since POSIX attributes includes Group ID, UID, etc.)
>
> Thanks.
>
> --
> 389-devel mailing list
> 389-de...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Matthew Garrett wrote: > The feature was +1ed on the assumption that the feature owner, as a > maintainer of relevant code, The maintainer of the relevant code (FreeType) is Marek Kasik, has he been consulted? (Those fontconfig files to be changed are just settings, the actual code is all in FreeType.) And the patch which makes FreeType fall back to autohinting for unhinted fonts (which was what allowed the BCI to be enabled in Fedora after the patent had expired) has been upstreamed by me (it originally came from Infinality), yet I definitely haven't been talked to. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Le Mar 24 juillet 2012 23:17, Michael Cronenworth a écrit : > It also turns every font into a blurry mess. This is not a subjective > opinion. Run the listed command on the Feature Page for DejaVu and > Liberation fonts (two of the biggest free fonts). With the current > free-type environment you have crisp, clean fonts. Enable auto-hinting > and every character becomes blurred including a simple exclamation mark > that is a single line of pixels. What you call crisp other call distorted windows-like rendering (even Apple does not do it that way, their rendering is closer to freetype autohinting) The change that disabled autohinting for any font with hinting traces was done without even checking our fonts worked well with it (most fonts have some hint traces because most font authors have experimented with them or copied a few glyphs from hinted fonts. That does not mean the hints are complete or usable for the font as a whole) Current in-the-wild font hints are bad enough Werner Lemberg could raise funds to write a windows-oriented executable that does nothing but embed freetype autohinter results in font files (so windows users get the benefit of freetype autohinting) http://www.freetype.org/ttfautohint/ If you look at the Google font directory logs Google is using this tool to add hints to its own files. Using font file hints should definitely be an opt-in (enable in the fontconfig snippet associated with a particular font family, after checking the hints are actually better than autohinting) not an opt-out. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On Wed, Jul 25, 2012 at 04:13:54PM +0200, Nicolas Mailhot wrote: > > Le Mar 24 juillet 2012 23:17, Michael Cronenworth a écrit : > > > It also turns every font into a blurry mess. This is not a subjective > > opinion. Run the listed command on the Feature Page for DejaVu and > > Liberation fonts (two of the biggest free fonts). With the current > > free-type environment you have crisp, clean fonts. Enable auto-hinting > > and every character becomes blurred including a simple exclamation mark > > that is a single line of pixels. > > What you call crisp other call distorted windows-like rendering (even > Apple does not do it that way, their rendering is closer to freetype > autohinting) Which is which? There are some example here: http://tagoh.fedorapeople.org/tmp/hints/ *-autohint variants are clearly blurred, while -*hintfull are eligible. -- Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: zdzich...@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Le Mer 25 juillet 2012 15:34, Kevin Kofler a écrit : > It should also be quite expected that using the hinting information > provided > by the fonts will necessarily lead to better hinting than not using it. Unfortunately, not. This is the classical "it's expensive and therefore must be good" logic mistake. BCI is not necessarily good because it was patented. BCI is better than no hinting at all, but that does not say much. Most of the fonts we use were developed with windows as a target (OSX tends to attract closed paid-for fonts only) and windows does not do autohinting. So the hints present in most fonts are here to improve the rendering when compared to no hinting at all. That in no way means they improve the rendering when compared to a mature and well-optimised autohinter such as the one used by freetype. In fact ttfautohint development was funded in part by the Google Web Font project, that works on the same set of FLOSS fonts as us, to provide freetype autohinter-like results to windows users. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Weekly ARM status meeting - Wed 2012/07/25
Good day all, This weeks Fedora ARM status meeting will take place today (Wednesday July 25th) in #fedora-meeting-1 on Freenode. Times in various time zones (please let us know if these do not work): PDT: 1pm MDT: 2pm CDT: 3pm EDT: 4pm UTC: 8pm BST: 9pm CST: 10pm Current items on the agenda: 1) F18 Mass rebuild status 2) Raspberry Pi Remix update 3) Your topic here If you have any other items you would like to discuss that are not mentioned, please feel free to send an email to the list or bring it up at the end of the meeting. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On 07/25/2012 10:21 AM, Tomasz Torcz wrote: > On Wed, Jul 25, 2012 at 04:13:54PM +0200, Nicolas Mailhot wrote: >> >> Le Mar 24 juillet 2012 23:17, Michael Cronenworth a écrit : >> >>> It also turns every font into a blurry mess. This is not a subjective >>> opinion. Run the listed command on the Feature Page for DejaVu and >>> Liberation fonts (two of the biggest free fonts). With the current >>> free-type environment you have crisp, clean fonts. Enable auto-hinting >>> and every character becomes blurred including a simple exclamation mark >>> that is a single line of pixels. >> >> What you call crisp other call distorted windows-like rendering (even >> Apple does not do it that way, their rendering is closer to freetype >> autohinting) > > Which is which? There are some example here: > http://tagoh.fedorapeople.org/tmp/hints/ > *-autohint variants are clearly blurred, while -*hintfull are eligible. > The "eligible" bits are the windows-like rendering AIUI. Nicolas's point is that evaluating these results, despite Michael's statement to the contrary, is highly subjective. To me your results look like this: DejaVuSans: 10 pts - pretty much both terrible, but for completely opposite reasons! 11-16 pts - bizarrely thin lines on the -hintful ones, basically okay on -autohint. All readable, but some are just ugly. 17 pts - strange and uncomfortable variances in line thickness on -hintful but basically okay on -autohint 18-25 pts - still some thickness issues but mostly okay on -hintful, but better on -autohint, 26 pts - weirdly bold on -hintful, normal looking on -autohint The liberation screenshots follow much the same way, except the 17 pts one is lumped in with 11-16. But obviously some people have different opinions, and seem to prefer the blockiness of -hintful to the blur of -autohint. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
Le Mer 25 juillet 2012 16:21, Tomasz Torcz a écrit : > Which is which? There are some example here: > http://tagoh.fedorapeople.org/tmp/hints/ > *-autohint variants are clearly blurred, while -*hintfull are eligible. And -*hintfull variants clearly show massive distortion and sudden thickness jumps when moving from one size to another. So they are not well hinted either. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Fontconfig] Heads up: Droid fonts update in Rawhide
Le Mer 25 juillet 2012 14:55, Behdad Esfahbod a écrit : > On 07/16/2012 02:00 AM, Nicolas Mailhot wrote: >> So make kufi a separate family and keep the old droid sans arabic for >> sans? Or is it also horrible in some way? > > I'd say yes. Ok then I'll take it the changes in http://pkgs.fedoraproject.org/gitweb/?p=google-droid-fonts.git;a=tree are ok for production use. Need to find some brave arabic users to test your other suggestion -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On Tue, Jul 24, 2012 at 11:38:00PM +0100, Matthew Garrett wrote: > On Tue, Jul 24, 2012 at 04:17:46PM -0500, Michael Cronenworth wrote: > > > It is unfortunate FESCo members blindly +1'd this feature without a > > bit of evidence or thought. Yes, I read the meeting log. It took > > just three minutes to pass. > > The feature was +1ed on the assumption that the feature owner, as a > maintainer of relevant code, is in a better position to judge the impact > on the packages they're working on than people who don't have that level > of expertise in the area in question. If the change turns out to have a > negative effect on the distribution as a whole then that's something > that should be discussed. If there's no more reasonable solution then it > should be reverted. But at present procedure is working pretty much > exactly as expected. > While I think that there might be some hyperbole in reaction to this Feature approval, this view of the Feature Approval Process is certainly not how I envisioned it when we initially implemented the Approval Process. FESCo reviews the Features in order to understand and point out how the changes will impact the distribution as a whole. Maintainers *are* better at understanding how their changes affect the code they work on but they aren't always better at seeing how their changes impact other people and the code that they maintain. (Note that if FESCo would rather not be doing that, it probably should be something that gets added to the Fixing Features page so it's an anti-goal of a any new features policy http://fedoraproject.org/wiki/Fixing_features ). -Toshio pgp3gdo5GTZ7q.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass rebuild for Fedora 18 Complete
On Tue, 2012-07-24 at 18:11 -0500, Dennis Gilmore wrote: > http://ausil.fedorapeople.org/f18-needsbuilt.html How is this list generated? It claims vbetool needs rebuilding, but vbetool has been deadpackaged. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass rebuild for Fedora 18 Complete
On Wed, Jul 25, 2012 at 5:03 PM, Adam Jackson wrote: > On Tue, 2012-07-24 at 18:11 -0500, Dennis Gilmore wrote: > >> http://ausil.fedorapeople.org/f18-needsbuilt.html > > How is this list generated? It claims vbetool needs rebuilding, but > vbetool has been deadpackaged. It's not been blocked from F18+ by rel-eng though according to koji http://koji.fedoraproject.org/koji/packageinfo?packageID=4988 There should be an f18 in the tags down the bottom with a red minus. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass rebuild for Fedora 18 Complete
On 07/25/2012 06:03 PM, Adam Jackson wrote: On Tue, 2012-07-24 at 18:11 -0500, Dennis Gilmore wrote: http://ausil.fedorapeople.org/f18-needsbuilt.html How is this list generated? It claims vbetool needs rebuilding, but vbetool has been deadpackaged. - ajax I found different problem. My packages at and cronie weren't build, there is no changelog about mass rebuild in their git. It looks like the list of packages for rebuild is not complete or something failed during mass rebuild. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass rebuild for Fedora 18 Complete
On Tue, 24 Jul 2012, Dennis Gilmore wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El Sun, 22 Jul 2012 14:21:10 -0600 Kevin Fenzi escribió: On Tue, 17 Jul 2012 07:39:31 -0500 Dennis Gilmore wrote: > it was requested in https://fedorahosted.org/rel-eng/ticket/5222 > that we do a mass rebuild for Fedora 18 for > https://fedoraproject.org/wiki/Features/DwarfCompressor and > https://fedoraproject.org/wiki/Features/MiniDebugInfo due to a mix > up in dates it was going to start on 2012-07-30 but since that only > gives a week to do the rebuild before branching for f18 on > 2012-08-07 we will be starting the mass rebuild on 2012-07-18 > > This is a heads up that it will be done in a side tag and moved over > when completed. We will be running scripts to output failure stats. > please be sure to let releng know if you see any bugs in the > reporting. The mass rebuild has completed and been tagged back into rawhide, they should appear in tomorrow's rawhide compose. 11057 packages were successfully rebuilt. 656 packages failed to rebuild. Please fix any packages you maintain that failed to rebuild. kevin http://ausil.fedorapeople.org/f18-failures.html http://ausil.fedorapeople.org/f18-needsbuilt.html are the lists of whats failed and what needs building yet. I'll update them a few times a day. Why freeipa is on the list of needsbuilt? I rebuilt it on Monday already. -- / Alexander Bokovoy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Weekly ARM status meeting - Wed 2012/07/25
On Wed, Jul 25, 2012 at 7:27 AM, Paul Whalen wrote: > Good day all, > > This weeks Fedora ARM status meeting will take place today (Wednesday July > 25th) in #fedora-meeting-1 on Freenode. > Times in various time zones (please let us know if these do not work): > > PDT: 1pm > MDT: 2pm > CDT: 3pm > EDT: 4pm > UTC: 8pm > BST: 9pm > CST: 10pm > > Current items on the agenda: > > 1) F18 Mass rebuild status > > 2) Raspberry Pi Remix update > > 3) Your topic here > > If you have any other items you would like to discuss that are not > mentioned, please feel free to send an email to the list or bring it up at > the end of the meeting. > > Paul > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel I don't think I can make it today, but how does one attend these? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Weekly ARM status meeting - Wed 2012/07/25
On Wed, Jul 25, 2012 at 12:30 PM, Richard Vickery wrote: > I don't think I can make it today, but how does one attend these? Join the #fedora-meeting-1 IRC channel on the Freenode network at the designated time. Then chime in where relevant. That simple. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On Wed, Jul 25, 2012 at 08:34:04AM -0700, Toshio Kuratomi wrote: > On Tue, Jul 24, 2012 at 11:38:00PM +0100, Matthew Garrett wrote: > > The feature was +1ed on the assumption that the feature owner, as a > > maintainer of relevant code, is in a better position to judge the impact > > on the packages they're working on than people who don't have that level > > of expertise in the area in question. If the change turns out to have a > > negative effect on the distribution as a whole then that's something > > that should be discussed. If there's no more reasonable solution then it > > should be reverted. But at present procedure is working pretty much > > exactly as expected. > > > While I think that there might be some hyperbole in reaction to this Feature > approval, this view of the Feature Approval Process is certainly not how > I envisioned it when we initially implemented the Approval Process. FESCo > reviews the Features in order to understand and point out how the changes > will impact the distribution as a whole. Maintainers *are* better at > understanding how their changes affect the code they work on but they > aren't always better at seeing how their changes impact other people and the > code that they maintain. > If it's clear to FESCo that the feature is going to have a significant impact on packages outside of those directly affected by the change then FESCo should take that into account when approving the feature. However, if a feature is well-confined to the packages under the maintainer's responsibility then second-guessing the maintainer's judgement is dangerous. Any negative fallout should be dealt with by the maintainer, and unless that fails I don't see any reason for FESCo to be involved. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass rebuild for Fedora 18 Complete
On Wed, Jul 25, 2012 at 06:09:12PM +0200, Marcela Mašláňová wrote: > On 07/25/2012 06:03 PM, Adam Jackson wrote: > >On Tue, 2012-07-24 at 18:11 -0500, Dennis Gilmore wrote: > > > >>http://ausil.fedorapeople.org/f18-needsbuilt.html > I found different problem. My packages at and cronie weren't build, > there is no changelog about mass rebuild in their git. It looks like > the list of packages for rebuild is not complete or something failed > during mass rebuild. The script seems to be buggy. The rebuild of fwbuilder was also not catched (it happened on Mon, 23 Jul 2012 21:51:52 UTC and was still reported on 2012-07-25 00:30:38.680350 UTC). Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dracut > 009-12 never made it to f15-stable
On Wed, 25 Jul 2012 02:04:13 -0400 Bill McGonigle wrote: > Hi, all, > > It looks like the latest f15 dracut to ever make it to -stable was > 009-12. I ran across this when I found a laptop that hadn't been on > in a while and needed an upgrade to f17. The trick, of course, is > that convertfs went into dracut-009-13. After -13, -14 and -15 were > built. The Wiki links to the former bodhi page for -15 : > >https://admin.fedoraproject.org/updates/dracut-009-15.fc15 > > but apparently it never got enough karma to move to stable. I'm > presuming that when f15 went EOL all the bodhi pages went away too, > so the link went dead. > > That leaves us with no yum upgrade path from 15 to 17 (due to > infrastructure details, not functionality). I think that means > preupgrade won't work either (though I use RAID-1 for /boot, so I > don't know too much about preupgrade). preupgrade should work as fine as it always does. It doesn't need this. > Suggestions for the best way forward? I was thinking some > constructive options are: Change the link to: http://koji.fedoraproject.org/koji/buildinfo?buildID=266766 ? > 1) out-of-cycle push to stable > 2) place in -testing (easy enough to document, doesn't help trivial > preupgrade case) > 3) host elsewhere on Fedora infrastructure (ditto) It's in koji. There's no way we are pushing anything to any eol release, so those are out. I suppose someone could stick it on a people page? but koji should work fine... > 4) host -15 off Fedora infrastructure (not awesome in my book) > We could always tell folks that they have to step through f16 first > or do a DVD upgrade, but those are somewhat less elegant and much > more bandwidth intensive. Just point to the koji build? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v3] Retiring packages for F-18
On 07/24/2012 08:36 PM, Bill Nottingham wrote: <...> Removing: ncpfs hydra requires libncp.so.2.3 hydra requires ncpfs-devel = 2.2.6-17.fc18 hydra requires libncp.so.2.3(NCPFS.2.2.0.17) hydra requires libncp.so.2.3(NCPFS_2.2.0.19) hydra requires libncp.so.2.3(NCPFS_2.2.1) medusa requires libncp.so.2.3 medusa requires ncpfs-devel = 2.2.6-17.fc18 medusa requires libncp.so.2.3(NCPFS.2.2.0.17) medusa requires libncp.so.2.3(NCPFS_2.2.0.19) medusa requires libncp.so.2.3(NCPFS_2.2.1) <...> I've taken ncpfs, I'll try to maintain it (not a Netware/IPX expert), co-maintainers are welcome. The worst case is to re-orphan ncpfs and rebuild hydra/medusa without ncpfs support. Thanks, --Athmane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On Wed, Jul 25, 2012 at 05:36:41PM +0100, Matthew Garrett wrote: > On Wed, Jul 25, 2012 at 08:34:04AM -0700, Toshio Kuratomi wrote: > > On Tue, Jul 24, 2012 at 11:38:00PM +0100, Matthew Garrett wrote: > > > The feature was +1ed on the assumption that the feature owner, as a > > > maintainer of relevant code, is in a better position to judge the impact > > > on the packages they're working on than people who don't have that level > > > of expertise in the area in question. If the change turns out to have a > > > negative effect on the distribution as a whole then that's something > > > that should be discussed. If there's no more reasonable solution then it > > > should be reverted. But at present procedure is working pretty much > > > exactly as expected. > > > > > While I think that there might be some hyperbole in reaction to this Feature > > approval, this view of the Feature Approval Process is certainly not how > > I envisioned it when we initially implemented the Approval Process. FESCo > > reviews the Features in order to understand and point out how the changes > > will impact the distribution as a whole. Maintainers *are* better at > > understanding how their changes affect the code they work on but they > > aren't always better at seeing how their changes impact other people and the > > code that they maintain. > > > > If it's clear to FESCo that the feature is going to have a significant > impact on packages outside of those directly affected by the change then > FESCo should take that into account when approving the feature. However, > if a feature is well-confined to the packages under the maintainer's > responsibility then second-guessing the maintainer's judgement is > dangerous. Any negative fallout should be dealt with by the maintainer, > and unless that fails I don't see any reason for FESCo to be involved. > Absolutely. But it is FESCo's responsibility to determine how well confined a feature is. So rather than phrasing this as FESCo should stay out of it unless "it's clear that the feature is going to have a significant impact on packages outside of those directly affected by the change" I would emphasize that FESCo is supposed to play an active role in discovering and evaluating what hte impact of a feature will be. This is because, as I stated, the feature owners are better are understanding how their changes affect what they are working on. But they aren't always better at seeing the big picture. And if you disagree with that, then I will reiterate that we should add that to the Fixing Features page a an anti-goal for an updated Feature Policy. If it is an anti-goal, it would allow for options where FESCo is not involved in the Feature Process for many features. If FESCo isn't a player in fact finding about how big the impact of a feature is, Features can be processed for whether they should be documentation-only features vs ones that require either "approval on whether this is a direction the distro should take" and "needs coordination among maintainers" before they reach FESCo. FESCo would only step in on "documentation-only" features if someone complains that the feature is more than a documentation-only change. -Toshio pgpBuqqQyafVv.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On Wed, Jul 25, 2012 at 7:46 PM, Toshio Kuratomi wrote: > And if you disagree with that, then I will reiterate that we should add that > to the Fixing Features page a an anti-goal for an updated Feature Policy. > If it is an anti-goal, it would allow for options where FESCo is not > involved in the Feature Process for many features. If FESCo isn't a player > in fact finding about how big the impact of a feature is, Features can be > processed for whether they should be documentation-only features vs ones > that require either "approval on whether this is a direction the distro > should take" and "needs coordination among maintainers" before they reach > FESCo. FESCo would only step in on "documentation-only" features if someone > complains that the feature is more than a documentation-only change. A few of us have discussed some changes that should address the major problems with the features, and would have definitely improved the handling of this feature. Expect a written proposal soonish. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v3] Retiring packages for F-18
On Tue, Jul 24, 2012 at 9:36 PM, Bill Nottingham wrote: > Package healpix (fails to build) My patch fixing this has been accepted, and this package is now built correctly. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
onsdagen den 25 juli 2012 16:38:33 skrev Nicolas Mailhot: > Le Mer 25 juillet 2012 16:21, Tomasz Torcz a écrit : > > Which is which? There are some example here: > > http://tagoh.fedorapeople.org/tmp/hints/ > > > > *-autohint variants are clearly blurred, while -*hintfull are eligible. > > And -*hintfull variants clearly show massive distortion and sudden > thickness jumps when moving from one size to another. So they are not well > hinted either. Perhaps I can provide some input here? Personally I don't see anything I would call "massive distortion" in any of those samples. It could be because I'm not all that interested in fonts. I'm used to seeing many different glyph variants and I don't care a lot about the finer details as long as it's clear which letter is which. I think many users are probably like me in that regard. Users don't want to think about the font when they are reading a text; they want to think about the information contained in the text. The font should convey the information without drawing attention to itself. I hope font designers don't take this to mean that their work is unimportant. That's not what I'm saying. Good fonts are very important, but most of the time a good font is one that the users don't notice. Many years ago it would often happen that the line thickness varied so much between individual letters that some of the letters looked like they were bold. That was quite annoying, but I don't see that in these samples. Maybe the w could have been a little thinner in LiberationSans-hintfull.png, sizes 15 to 17, but that's a minor issue compared to how it was back then. I strongly dislike the blurry letters in the autohint samples. I lived with such blurry letters for some time, and I remember how they affected me. They annoyed me and drew my attention away from my reading. I think vertical and horizontal lines should always be a whole number of pixels wide. The thickness jumps between sizes are unfortunate, but they are an inevitable effect of limited screen resolution. I'll choose the thickness jumps over the blurry letters without hesitation. Should we hold a vote to determine how the majority of users like their fonts? Björn Persson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Outage of fedorahosted mailing lists and services
There will be an outage starting at 2012-07-26 16:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2012-07-26 16:00 UTC' Reason for outage: In order to grow the fedora hosted services we are moving the services email lists to a new server. This will require an outage of about an hour as we turn off old services.. sync data.. turn on new services. Affected Services: Fedora Hosted - https://fedorahosted.org/ Unaffected Services: Ask Fedora - http://ask.fedoraproject.org/ BFO - http://boot.fedoraproject.org/ Bodhi - https://admin.fedoraproject.org/updates/ Buildsystem - http://koji.fedoraproject.org/ GIT / Source Control DNS - ns1.fedoraproject.org, ns2.fedoraproject.org Docs - http://docs.fedoraproject.org/ Email system Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ Fedora Insight - https://insight.fedoraproject.org/ Fedora People - http://fedorapeople.org/ Main Website - http://fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ QA Services Secondary Architectures Smolt - http://smolts.org/ Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/3401 Contact Information: Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. -- Stephen J Smoogen. "Don't derail a useful feature for the 99% because you're not in it." Linus Torvalds "Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A preupgrade adventure - F16 to F17
On Sat, 2012-07-21 at 12:21 +0200, Reindl Harald wrote: > > Am 21.07.2012 01:41, schrieb Martin Langhoff: > > Hmm, now I think it was a F14 install: > > > > ls -lah /root/anaconda-ks.cfg > > -rw---. 1 root root 837 Jun 13 2011 /root/anaconda-ks.cfg > > > > Who calls grubby and ignores its ungraceful death? That needs bubble > > up the call stack... > > > > Upgrade completed without any more hiccups. Moving to grub2 > > the move to grub2 should have been dobe in the F16 cycle > > http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_15_-.3E_Fedora_16 > look at "Bootloader change" > > this may be a big change on older setups because > you have to make sure there is enough space for > GRUB2 meaning on all my machines installed in 2008 > make free space before the /boot partition > > that is why the movement to grub2 is not done automatically It is, if you upgrade via anaconda, but not if you upgrade via yum. We couldn't find an acceptable method to trigger a bootloader upgrade via yum. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On Wed, 25 Jul 2012, Björn Persson wrote: I'm used to seeing many different glyph variants and I don't care a lot about the finer details as long as it's clear which letter is which. I think many users are probably like me in that regard. Users don't want to think about the font when they are reading a text; they want to think about the information contained in the text. Every single Fedora upgrade in the last few years (with perhaps F17 the exception) surprised me with superior fonts over the previous release. We might not have conveyed that, but I've been pretty happy with what people have done with fonts so far. I did not look at the latest feature proposal or there impact, but I did nwat to say that there are a lot of users out there who care and notice fonts beyond "which letter is which". Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu Unity has been ported to Fedora 17
On Tue, 2012-07-24 at 14:13 -0300, Evandro Giovanini wrote: > On Tue, Jul 24, 2012 at 1:24 PM, Kevin Kofler wrote: > > Olav Vitters wrote: > >> I thought the work that went into GTK+ 3.4 (GMenu) should allow Unity to > >> use that functionality instead of any patches. Not 100% sure on this. It > >> does require that GTK+ applications make use of GMenu (and only a few > >> do). Usually when GMenu support is added you see some new entries under > >> the application icon (next to Activities). > > > > Ugh, why a new backwards-incompatible API instead of supporting this feature > > required for cross-desktop interoperability in the existing one? :-( In > > addition, the new API is designed to only export a single menu with a subset > > of the full one, which may work for Unity, but NOT for Mac-style menus such > > as the "global menu bar" widget available for KDE Plasma. Why reject a > > complete solution in favor of a crippled one? :-( > > > > > > The menu integrates just fine under GNOME, Mac OS X and XFCE. I don't > see why it wouldn't work on KDE as well. > > Please look at http://developer.gnome.org/gtk3/3.3/GtkApplication.html > to answer your questions. AIUI, the problem is that the GTK+ API is designed only to handle the GNOME design where any app has a _single_ 'universal' menu. You can't put File, Edit, View, Tools, Help... menus into the Shell panel with it; you can only get a single menu (the one with the app's name and icon, next to Activities). This is the design GNOME wants. But Kevin's saying you can't use it to implement something like OS X-style global menus, where you have a full traditional menu bar that lives in the panel rather than the app window. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora ARM weekly status meeting minutes 2012/07/25
Good day all, Thanks to those who were able to join us for the weekly status meeting today. For those that were unable, the minutes are posted below: Meeting ended Wed Jul 25 20:49:27 2012 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-07-25/fedora-meeting-1.2012-07-25-20.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2012-07-25/fedora-meeting-1.2012-07-25-20.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2012-07-25/fedora-meeting-1.2012-07-25-20.00.log.html Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v3] Retiring packages for F-18
Peter Robinson (pbrobin...@gmail.com) said: > >> That list seems seriously incomplete. I'm aware of at least these > >> others that have FTBFS in both F17 and F18 mass rebuilds, as evidenced > >> by their release tags: > > > > It's done by basing off of the F16FTBFS bug, as that's the easiest source > > of info when we haven't done a mass rebuild. > > > > We could include everything with older dist tags. Looking at it, that would > > be 78 more packages. > > It would be nice to get rid of anything that's FTBFS in non supported > Fedora (ie at least < fc16) and the last time I looked at that there's > a good 150 odd packages that are fc15 or older packages. There's been > two mass rebuilds since then and if the package maintainers haven't > managed to fix them (or they've not been fixed by people like > secondary arches that fix them because they're blocking their builds) > the package maintainer is either AWOL or not doing their job of > maintaining packages or even bothering to check failure emails so it's > likely better off for Fedora that they're scrapped as well. I think in > the F17 cycle I fixed over 100+ of these packages. I'm OK with being more thorough here, but I can't commit to bringing back the full FTBFS infrastructure myself - I just don't have the time. I'll see about getting the list of other non-building packages and get bugs filed for them. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v3] Retiring packages for F-18
Nikola Pajkovsky (npajk...@redhat.com) said: > Bill Nottingham writes: > > > Before we branch for Fedora 18, as is custom, we will block currently > > orphaned packages and packages that have failed to build since Fedora 16. > > > > The following packages are currently orphaned, or fail to build. If > > you have a need for one of these packages, please pick them up. > > If no one claims any of these packages, they will be blocked before > > we branch for Fedora 18. That is currently scheduled to happen on > > or around August 7th. > > > > Note that if you're receiving this mail directly, it's because you are > > a co-maintainer of one of these packages. Please work with your > > comaintainers to take up maintenance. > > there is missing orphaned iptraf. please get rid of it from f18. Please follow the procedure at: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Thanks, Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 updates broke anaconda PNG image handling
On Wed, Jul 25, 2012 at 03:32:55PM +0200, Jos Vos wrote: > Note that my install now fails when installing the kernel, because > grub2-install can not be found. I have to find out if this is an > user error (I only included @Base in my test install DVD) or that > this is something more serious. If the kernel needs grub2-install, > it should Requires(post) that, isn't it? It obviously doesn't... I was partly wrong here. This failure was not due to the kernel's %post, but anaconda couldn't find grub2-install for its final step. It seems that I need to add grub2 manually to the pungi config file, which also pulls in the grub2-tools, file, and file-libs packages. Then it all works fine. Is this expected behavior or should grub2 maybe be part of @Base? -- --Jos Vos --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 updates broke anaconda PNG image handling
Jos Vos (j...@xos.nl) said: > On Wed, Jul 25, 2012 at 03:32:55PM +0200, Jos Vos wrote: > > > Note that my install now fails when installing the kernel, because > > grub2-install can not be found. I have to find out if this is an > > user error (I only included @Base in my test install DVD) or that > > this is something more serious. If the kernel needs grub2-install, > > it should Requires(post) that, isn't it? It obviously doesn't... > > I was partly wrong here. This failure was not due to the kernel's > %post, but anaconda couldn't find grub2-install for its final step. > > It seems that I need to add grub2 manually to the pungi config file, > which also pulls in the grub2-tools, file, and file-libs packages. > Then it all works fine. > > Is this expected behavior or should grub2 maybe be part of @Base? You likely want '@anaconda-tools' in your compose - that's for "things that anaconda chooses to install based on your filesystem/storage/boot setup. This group creation was done late in the F17 cycle, sorry it wasn't more widely announced. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
"Jóhann B. Guðmundsson" (johan...@gmail.com) said: > >Standardization on the changes so it can be documented in the guidlines > >so people know what to do in their unit file. (such as around > >Documentation=, what fields are no longer necessary, etc.) > > That's just laughable since afaik systemd would be the only program > that is forced to go through these change and get the approvals from > FPC while others simply get away with mentioning changes in upstream > documentation. I don't see this sort of bias that you're implying here. Init script packaging changes went through FPC. Desktop file packaging goes through FPC. Ruby gems packaging changes go through FPC. Why wouldn't something like systemd services that also affects a few hundred packages? Yes, systemd does have a bit higher bar on things than, say, alienblaster, but that's because it's much more important to the overall system. > I thought you guys meant the removal of the environment files that > resides in /etc/sysconfig/ directory and that was why the feature > was being rejected and mentioning that upstream needed some kind of > upstream patching was just utter and total bullshit since putting > environment files in /etc/sysconfig/$file is Fedora/RHEL specific > and is the reason why upstream has been rejected our units when they > have been submitted upstream... This was also a concern of FESCo, yes - having a clear migration path for users and administrators, rather than dropping them all and picking up the pieces. Additionally, there was a minor concern about if there are going to be more cleanups that pop up each release, as some of the cleanups (documentation is the obvious one) didn't exist when the units were first written. These sorts of changes are the sort of thing that are great for standardizing in conjunction with FPC guidelines, so others can see how to do it and evangelize the work upstream and possibly even help. Teaching to fish instead of giving fish, more or less. Really, that's all that needs done here - get a standard for what a cleaned up unit should look like, what it should include, etc., and get that through FPC. Essentially, a list of what should be changed in: https://fedoraproject.org/wiki/Packaging:Systemd It's not like the feature was rejected out of hand; it was just redirected. > Then you guys started to act like kids in candy store and cherry > pick stuff from the feature requests well here's a news flash that > wont work with me. When I submit features I will submit them as is, > work on them as is and finish them myself as is While I commend your desire on doing the work on features you submit yourself, Fedora *IS* a community project; it's about collaboration, not a collection of individuals all going in different directions. We do have policies and procedures in Fedora for a reason. You may not like them. Heck, I don't like them some of the time either. And some of them can use fixing - we have ongoing work on fixing the feature process as we speak. However, when you say you'll only do the features your way, yourself, and aren't willing to accept alternatives, or work with the community's elected representatives on this (that's how your statements read to me), it seems to the outside world like you don't share the same set of values there. If that's the case, it *is* going to cause repeated friction, and make make it harder for you to effectively and/or happily contribute. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Replacing grubby with grub2-mkconfig in kernel install process
On Fri, Jun 22, 2012 at 2:03 AM, Chris Murphy wrote: > > On Jun 21, 2012, at 12:42 AM, Juan Orti Alcaine wrote: > > > To change your default option, just edit /etc/default/grub and set > > GRUB_DEFAULT to match the label or entry number or "saved". > > grub2-mkconfig will respect that decision (or it did, the last time I > > used it) > > No I mean for the default behavior in Fedora for GRUB 2 to be that the > last chosen entry be made the default boot option (next boot). This is done > with: > > GRUB_DEFAULT=saved > GRUB_SAVEDEFAULT=true > > I know how to change the behavior. I'm suggesting that this is a > preferable behavior for users new to Fedora, which does not require that > they become familiar with the esoteric aspects of GRUB. > > Chris Murphy > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > In /etc/default/grub if you uncomment the theme line it gave an error about fireworks.png doesnt exist Any body had this issue? Regards, Adrian.- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[ACTION REQUIRED v4] Retiring packages for F-18
Updated with new list of packages that have failed to build. Before we branch for Fedora 18, as is custom, we will block currently orphaned packages and packages that have failed to build since Fedora 16. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. If no one claims any of these packages, they will be blocked before we branch for Fedora 18. That is currently scheduled to happen on or around August 7th. Note that if you're receiving this mail directly, it's because you are a co-maintainer of one of these packages. Please work with your comaintainers to take up maintenance if you desire. Package Panini (fails to build) Package UnihanDb (fails to build) Package alevt (fails to build) Package apache-commons-launcher (fails to build) Package archmage (orphan) Package audtty (fails to build) Package autoarchive (fails to build) Package boolstuff (orphan) Package boolstuff (orphan) Package cmucl (orphan) comaintained by: green Package eboard (fails to build) Package eclipse-collabnet-merge (fails to build) Package eclipse-emf-query (fails to build) Package eclipse-emf-transaction (fails to build) Package eclipse-emf-validation (fails to build) Package eclipse-m2m-qvtoml (fails to build) Package eclipse-mdt-ocl (fails to build) Package eclipse-mdt-uml2 (fails to build) Package ext3grep (fails to build) Package ezmorph (fails to build) Package fbdesk (fails to build) Package fedora-idm-console (fails to build) comaintained by: rmeggins Package fillmore-lombard (fails to build) comaintained by: salimma Package freenx-client (fails to build) Package gant (fails to build) Package gconf-cleaner (fails to build) Package gdmap (fails to build) Package gimmix (fails to build) Package globalplatform (orphan) Package gnofract4d (fails to build) comaintained by: firewing Package gnome-do-docklets (fails to build) Package gnome-speech (fails to build) Package gooddata-cl (fails to build) Package gpshell (orphan) Package gtkmm-utils (orphan) Package gtkmm-utils (orphan) Package hamster-applet (orphan) Package hartke-aurulent-sans-fonts (orphan) Package ibus-table-code (fails to build) Package ibus-table-others (fails to build) comaintained by: nkumar Package jpoker (fails to build) Package json (orphan) Package json-lib (fails to build) Package k12linux-quick-start-guide (orphan) Package kadu (fails to build) comaintained by: gajownik radekl Package komparator (fails to build) Package krecipes (fails to build) Package ksplice (fails to build) Package libcrystalhd (fails to build) comaintained by: kwizart Package libgdbus (fails to build) Package libgtkhotkey (orphan) Package libgtksourceviewmm (fails to build) Package libharu (fails to build) Package libhid (fails to build) Package libkml (fails to build) Package libmnetutil (fails to build) Package libopensync-plugin-opie (fails to build) Package libpano12 (fails to build) Package libqttracker (fails to build) comaintained by: jreznik Package libsoup22 (orphan) Package libsoup22 (orphan) Package libvpd (fails to build) comaintained by: lnykryn Package lsvpd (fails to build) comaintained by: lnykryn Package metapixel (fails to build) Package mimetic (fails to build) Package mod_scgi (fails to build) Package munipack (fails to build) Package natus (fails to build) Package ntfs-config (fails to build) Package numptyphysics (fails to build) Package nvi (orphan) Package openoffice.org-diafilter (fails to build) Package perl-Nagios-Plugin-Beanstalk (orphan) Package pfqueue (orphan) Package php-pear-File-Find (fails to build) Package pianobooster (fails to build) Package pino (fails to build) Package pngcrush (fails to build) Package polyester (orphan) Package polyester3 (orphan) Package postgresql-odbcng (fails to build) Package printoxx (fails to build) Package putty (fails to build) comaintained by: tremble Package pxe-kexec (fails to build) Package python-batchhttp (orphan) Package python-chm (orphan) Package python-modjkapi (fails to build) Package python-pywt (fails to build) Package python-remoteobjects (orphan) Package python-typepad (orphan) Package qalculate-kde (fails to build) Package qtparted (fails to build) Package quesoglc (fails to build) Package ragel (fails to build) Package raul (fails to build) Package rpmdepsize (fails to build) comaintained by: rjones Package scite (fails to build) Package selenium-core (fails to build) Package selenium-remote-control (fails to build) Package sofsip-cli (fails to build) comaintained by: itamarjp Package specto (fails to build) Package stratagus (fails to build) Package subcommander (fails to build) Package svnkit (fails to build) Package tangogps (fails to build) Package tesseract (fails to build) Package torque (orphan) Package txt2man (fails to build) Package typepad-motion (orphan) Package upstart (orphan) Package winwrangler (orpha
Re: [ACTION REQUIRED v3] Retiring packages for F-18
Bill Nottingham (nott...@redhat.com) said: > > It would be nice to get rid of anything that's FTBFS in non supported > > Fedora (ie at least < fc16) and the last time I looked at that there's > > a good 150 odd packages that are fc15 or older packages. There's been > > two mass rebuilds since then and if the package maintainers haven't > > managed to fix them (or they've not been fixed by people like > > secondary arches that fix them because they're blocking their builds) > > the package maintainer is either AWOL or not doing their job of > > maintaining packages or even bothering to check failure emails so it's > > likely better off for Fedora that they're scrapped as well. I think in > > the F17 cycle I fixed over 100+ of these packages. > > I'll see about getting the list of other non-building packages and get > bugs filed for them. Done, new list sent. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Wed, Jul 25, 2012 at 06:24:52PM -0400, Bill Nottingham wrote: > Package rpmdepsize (fails to build) > comaintained by: rjones Wooaa there, this is the first time I'm aware this one FTBFS. (I'm sure there may have been a BZ, but I have 1000s of BZs open and the Bugzilla "UI" makes them impossible to cope with.) This one won't build in F18 because it requires ocaml-sexplib where we're still waiting for an upstream fix, and that's something that cannot be helped at the moment. I will do a F17 build soon, fixing things if necessary. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)
On 07/25/2012 09:42 PM, Bill Nottingham wrote: "Jóhann B. Guðmundsson" (johan...@gmail.com) said: Standardization on the changes so it can be documented in the guidlines so people know what to do in their unit file. (such as around Documentation=, what fields are no longer necessary, etc.) That's just laughable since afaik systemd would be the only program that is forced to go through these change and get the approvals from FPC while others simply get away with mentioning changes in upstream documentation. I don't see this sort of bias that you're implying here. Init script packaging changes went through FPC. Desktop file packaging goes through FPC. Ruby gems packaging changes go through FPC. Why wouldn't something like systemd services that also affects a few hundred packages? Yes, systemd does have a bit higher bar on things than, say, alienblaster, but that's because it's much more important to the overall system. You guys ( FESCO ) seem to have easily dismiss that fact when you accepted the preset feature or when accepting systemd. If you guys FESCO had wanted documentation how to construct units you guys would have asked for one when you guys accepted systemd as the new init system then most certainly this argument would make sense. . If the migration process was not needed to be handled on per initscript bases I would have written one long time ago. I thought you guys meant the removal of the environment files that resides in /etc/sysconfig/ directory and that was why the feature was being rejected and mentioning that upstream needed some kind of upstream patching was just utter and total bullshit since putting environment files in /etc/sysconfig/$file is Fedora/RHEL specific and is the reason why upstream has been rejected our units when they have been submitted upstream... This was also a concern of FESCo, yes - having a clear migration path for users and administrators, rather than dropping them all and picking up the pieces. Again ye had no problem accepting the preset feature Additionally, there was a minor concern about if there are going to be more cleanups that pop up each release, as some of the cleanups (documentation is the obvious one) didn't exist when the units were first written. These sorts of changes are the sort of thing that are great for standardizing in conjunction with FPC guidelines, so others can see how to do it and evangelize the work upstream and possibly even help. Teaching to fish instead of giving fish, more or less. I will be doing the cleanup process one time. After that my systemd involvement will be more or less concluded and I will be returning to QA and continue the work I was doing there and had been doing there for several release cycles before I was asked to handle the migration. Really, that's all that needs done here - get a standard for what a cleaned up unit should look like, what it should include, etc., and get that through FPC. Essentially, a list of what should be changed in: https://fedoraproject.org/wiki/Packaging:Systemd It's not like the feature was rejected out of hand; it was just redirected. ? There is nothing on that page that is mentioned on that page that would get affected by the cleanup process thus nothing is subjected to be changed there. Then you guys started to act like kids in candy store and cherry pick stuff from the feature requests well here's a news flash that wont work with me. When I submit features I will submit them as is, work on them as is and finish them myself as is While I commend your desire on doing the work on features you submit yourself, Fedora *IS* a community project; it's about collaboration, not a collection of individuals all going in different directions. We do have policies and procedures in Fedora for a reason. You may not like them. Heck, I don't like them some of the time either. And some of them can use fixing - we have ongoing work on fixing the feature process as we speak. Yes I saw that effort which still does not seem to make a room for features that span over several release cycles. However, when you say you'll only do the features your way, yourself, and aren't willing to accept alternatives, or work with the community's elected representatives on this (that's how your statements read to me), And my work proves otherwise... it seems to the outside world like you don't share the same set of values there. If that's the case, I personally would choose fewer better maintained components in the distribution then many poorly maintained or not maintained at all and personally I want feature to be actually 100% done instead of just be claimed to be done thus if the "outside world" wants and accepts half implemented things in the release then sure we do not share the same value. Heck when we in QA miss a serious bug that affects large user base I take that as a personal failure on my behalf as crazy as that is, in the end that's just ho
Re: [ACTION REQUIRED v4] Retiring packages for F-18
On Wed, 2012-07-25 at 23:53 +0100, Richard W.M. Jones wrote: > On Wed, Jul 25, 2012 at 06:24:52PM -0400, Bill Nottingham wrote: > > Package rpmdepsize (fails to build) > > comaintained by: rjones > > Wooaa there, this is the first time I'm aware this one FTBFS. See the discussion in the v3 thread, just today. It was discovered that there are a number of packages that have been FTBFS since F15 or earlier but which weren't previously included in the list. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED v4] Retiring packages for F-18
> Package Panini (fails to build) > Package fedora-idm-console (fails to build) > comaintained by: rmeggins > Package gdmap (fails to build) For these packages, I have filed patches to fix them in the bugzilla bugs. > Package python-batchhttp (orphan) I have taken over this one. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mass rebuild for Fedora 18 Complete
Hi, On Wed, Jul 25, 2012 at 4:41 AM, Dennis Gilmore wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > El Sun, 22 Jul 2012 14:21:10 -0600 > Kevin Fenzi escribió: >> On Tue, 17 Jul 2012 07:39:31 -0500 >> Dennis Gilmore wrote: >> >> > it was requested in https://fedorahosted.org/rel-eng/ticket/5222 >> > that we do a mass rebuild for Fedora 18 for >> > https://fedoraproject.org/wiki/Features/DwarfCompressor and >> > https://fedoraproject.org/wiki/Features/MiniDebugInfo due to a mix >> > up in dates it was going to start on 2012-07-30 but since that only >> > gives a week to do the rebuild before branching for f18 on >> > 2012-08-07 we will be starting the mass rebuild on 2012-07-18 >> > >> > This is a heads up that it will be done in a side tag and moved over >> > when completed. We will be running scripts to output failure stats. >> > please be sure to let releng know if you see any bugs in the >> > reporting. >> >> The mass rebuild has completed and been tagged back into rawhide, they >> should appear in tomorrow's rawhide compose. >> >> 11057 packages were successfully rebuilt. >> 656 packages failed to rebuild. >> >> Please fix any packages you maintain that failed to rebuild. >> >> kevin > http://ausil.fedorapeople.org/f18-failures.html > http://ausil.fedorapeople.org/f18-needsbuilt.html > I don't see iok ever failed to build and caribou has been already rebuilt but still above list has listed it. please update this list. Regards, Parag. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
