Re: (Most) Results from the Candidate Questionnaire are available now
On 05.06.2009 21:42, Till Maas wrote: > On Thu June 4 2009, Thorsten Leemhuis wrote: >> On 03.06.2009 21:28, Thorsten Leemhuis wrote: > >>> http://www.leemhuis.info/files/fedora/answers-table.ods >> Both updated with the answers from Dglimore. > He has been added twice to the ods table. Because he runs for both the Board and FESCo as indicated by the first row ;-) CU knurd -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning nopaste // ruby help wanted for broken package
On Fri, Jun 5, 2009 at 7:48 PM, Casey Dahlin wrote: > Iain Arnell wrote: >> If anyone beats me too it - iwannit! >> > > You can have it. Your solution sounds better. Taken - for the sole purpose of retiring it gracefully. I've added a nopaste sub-package to perl-App-Nopaste in devel, F-11, and F-10 that should provide a seamless upgrade for existing users. It supports multiple pastebins and provides redundancy; if one site goes down, it just tries another one. -- Iain. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mono (& Moonlight) Licensing? Revisited
On Sun, May 31, 2009 at 12:15 PM, Kevin Kofler wrote: > King InuYasha wrote: > > I really don't see why you should freak out over Moonlight, if Mono is > > protected, then Moonlight 2 should be protected, since it is a form of > > Mono itself. > > Moonlight needs to go to RPM Fusion anyway because it needs to link to > FFmpeg, unless you want to use the proprietary codec pack from M$ (yuck!). > So it's no use arguing about whether Moonlight itself is patent-encumbered > or not. > >Kevin Kofler > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Then don't use FFmpeg. And since Moonlight itself will not contain the MS codec pack, it can still fit in main Fedora repositories. If you don't want to do that, then find someone knowledgeable in GStreamer to write a GStreamer media backend for Moonlight. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nathanael D. Noblet wrote: > Casey Dahlin wrote: >> Nathanael D. Noblet wrote: I don't know how hard it would be to fix rpm to allow for that though. >>> Just off the top of my head, this doesn't feel like something rpm should >>> be in charge of. To me it seems more likely that we need something in a >>> base/core rpm that installs an inotify script for system dirs that does >>> what it should when something is dropped into it...? >>> >> >> Ugh, no. We don't need another running service to do this. Just have >> rpm do it as part of its post install and you don't need to involve >> inotify; it knows a file showed up because it put it there a few >> milliseconds ago. > Inotify isn't a service/daemon, and its running already afaik?? > > > Its a kernel API. You need a service running to operate it. - --CJD -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkopsp4ACgkQIHOkVH4pLz5XUQCaAw5Ol2Evm0miTclrIQNJIFgZ 1kUAnRX4X/RYVF0kt9M828cpMwXFs7ps =lmLv -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
File Triggers (was Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros)
Hi,
On Fri, Jun 5, 2009 at 2:05 PM, Adam Williamson wrote:
> On Fri, 2009-06-05 at 13:50 -0400, Ray Strode wrote:
>
>> > It seems to me it'd make sense to convert all these kinds of snippets
>> > into macros. Am I right, or is there a reason against doing this?
>> It would be awesome to get rid of the boilerplate. Honestly though,
>> I'd rather the solution was "just works" than "replace giant glob of
>> muck with %{glob_of_muck}"
>
> Yes indeed, this would be best in many cases. Some can't really be done
> like that, though - like the snippets for Tcl and Python to define the
> version, directories for certain types of file and so on. They're
> just...informational. Defining them as macros seems the optimal
> solution.
Right, totally agree.
>> For instance, if a file gets dropped under /usr/share/icons/something
>> rpm should run gtk-update-icon-cache /usr/share/icons/something
>> automatically.
>>
>> the gtk2 package should be able to drop a file in /usr/lib/rpm/redhat
>> that makes that happen. likewise, desktop-file-utils should be able
>> to drop a file there to make update-desktop-database get run and so
>> on.
>>
>> I don't know how hard it would be to fix rpm to allow for that though.
>
> This is definitely possible; Mandriva (I know I talk about MDV a lot,
> I'm sorry, it's what I know! :>) does this, via an implementation called
> 'file triggers'. This is not yet upstream, though.
>
> The MDV patch that implements this is:
>
> http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/rpm/current/SOURCES/rpm-4.6.0-rc1-filetriggers.patch?view=markup
>
> MDV's wiki discussion of it is here:
>
> http://wiki.mandriva.com/en/Rpm_filetriggers
>
> It appears to be something upstream has thought about several times.
> Here's an RPM 5 community discussion of it, with Jeff Johnson's
> thoughts:
>
> http://rpm5.org/community/rpm-devel/2959.html
>
> Here's a discussion from the rpm.org Wiki:
>
> http://www.rpm.org/wiki/Problems/Scriptlets
Oh neat!
> I'm not sure what the current status is for rpm.org - whether they're
> actively working on a solution for this side of things or what.
Panu, does this patch make sense?
> Oh, and please try to consider the original proposal in replies to this
> thread, as I sense a derail coming :). file triggers is certainly an
> interesting topic, but there are some snippets which just don't fit the
> case, see above.
Right, I'veretitled the subject. I guess there are two different
halves to the spec boilerplate problem.
--Ray
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESco meeting summary for 20090605
On Fri, Jun 05, 2009 at 01:56:59PM -0600, Kevin Fenzi wrote: > On Fri, 5 Jun 2009 15:30:36 -0400 > "Paul W. Frields" wrote: > > > > So, perhaps someone could contribute that. :) > > > Currently it just writes logs/summary to a local filesystem. > > > > I'd like to try this (and fail badly, and then have it rewritten by > > someone who knows better). The main problem I see is that the thing's > > written in Tcl which I don't know. Maybe I could try porting it to a > > zodbot plugin, and then use python-mediawiki to do the auth + posting. > > Oh, the link on the summary is pointing to the wrong page. > The tcl thing was the old generation of plugin. > > The http://wiki.debian.org/MeatBot one which we are using is in > python. ;) Yay! -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On Fri, 2009-06-05 at 12:28 -0700, Toshio Kuratomi wrote: > /me notes that we did pass it in the end, though. > > I don't believe this would be a problem for things like python_sitelib > which are defining standard directory locations. using macros for > directories is something that we do everywhere. > > For things that are replacing actions, there is a certain amount of > obscuring being done. This is a barrier for entry for people who know > how to build software from upstream but don't know how to package. It > also can make debugging harder if something does go wrong in the macro. > > However, these are balanced by giving us the ability to change the > instructions in a central location and having that propagate out to the > next build of all packages. And they can make it simpler to perform an > action correctly if it is complex. I think therefore I'll plan to to the most non-controversial ones first - things like the version and directory macros for Tcl and Python - and then maybe look at the more debated ones after that. I'll bring the first wave of ones to the packaging committee once I have proposed patches ready. Sound good? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On Fri June 5 2009, Toshio Kuratomi wrote: > For things that are replacing actions, there is a certain amount of > obscuring being done. This is a barrier for entry for people who know > how to build software from upstream but don't know how to package. It > also can make debugging harder if something does go wrong in the macro. In case of macros in %post and related sections, afaik one can easily inspect the code after macro expansion using rpm --scripts -q... Regards Till signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESco meeting summary for 20090605
On Fri, 5 Jun 2009 15:30:36 -0400 "Paul W. Frields" wrote: > > So, perhaps someone could contribute that. :) > > Currently it just writes logs/summary to a local filesystem. > > I'd like to try this (and fail badly, and then have it rewritten by > someone who knows better). The main problem I see is that the thing's > written in Tcl which I don't know. Maybe I could try porting it to a > zodbot plugin, and then use python-mediawiki to do the auth + posting. Oh, the link on the summary is pointing to the wrong page. The tcl thing was the old generation of plugin. The http://wiki.debian.org/MeatBot one which we are using is in python. ;) kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: (Most) Results from the Candidate Questionnaire are available now
On Thu June 4 2009, Thorsten Leemhuis wrote: > On 03.06.2009 21:28, Thorsten Leemhuis wrote: > > http://www.leemhuis.info/files/fedora/answers-table.ods > > Both updated with the answers from Dglimore. He has been added twice to the ods table. Regards, Till signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESco meeting summary for 20090605
On Fri, Jun 05, 2009 at 01:05:06PM -0600, Kevin Fenzi wrote: > On Fri, 5 Jun 2009 14:56:34 -0400 > "Paul W. Frields" wrote: > > > On Fri, Jun 05, 2009 at 11:51:42AM -0600, Kevin Fenzi wrote: > > > If this format is acceptable, I would like to see all irc meetings > > > use it, and have them all transfer to a common location with search > > > ability. If not, we will come up with something better. > > > > We should probably try to have these transferred to the wiki, under > > the Meeting: namespace, with an appropriate category assigned. > > Perhaps the bot could be given an account that would allow that > > access? > > That would be great, but it currently has no ability to talk to a wiki. > > The upstream page at http://wiki.debian.org/MeatBot has: > > Wishlist: > Publish to a wiki page? (I'll do it if someone gives me wiki-posting > code) > > So, perhaps someone could contribute that. :) > Currently it just writes logs/summary to a local filesystem. I'd like to try this (and fail badly, and then have it rewritten by someone who knows better). The main problem I see is that the thing's written in Tcl which I don't know. Maybe I could try porting it to a zodbot plugin, and then use python-mediawiki to do the auth + posting. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On 06/05/2009 11:40 AM, Matthias Clasen wrote: > On Fri, 2009-06-05 at 10:31 -0700, Adam Williamson wrote: > >> >> It seems to me it'd make sense to convert all these kinds of snippets >> into macros. Am I right, or is there a reason against doing this? >> > > When this was discussed for the example of GConf schemas in the > packaging committee a few weeks ago, there was quite a bit of pushback > about 'obscure macros' hiding whats really going on... > /me notes that we did pass it in the end, though. I don't believe this would be a problem for things like python_sitelib which are defining standard directory locations. using macros for directories is something that we do everywhere. For things that are replacing actions, there is a certain amount of obscuring being done. This is a barrier for entry for people who know how to build software from upstream but don't know how to package. It also can make debugging harder if something does go wrong in the macro. However, these are balanced by giving us the ability to change the instructions in a central location and having that propagate out to the next build of all packages. And they can make it simpler to perform an action correctly if it is complex. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: (Most) Results from the Candidate Questionnaire are available now
On Fri, Jun 05, 2009 at 09:04:08PM +0200, Thorsten Leemhuis wrote: > Sorry, was a bit busy over the past few days and didn't get around to > answer all mails. > > On 04.06.2009 00:30, Andreas Thienemann wrote: > > On Wed, 3 Jun 2009, Paul W. Frields wrote: > [...] > >> I'm disappointed this ended up being a more difficult process than you > >> intended, but I have no doubt we can improve it for the next cycle. > > Leaving a bit more time between the cut-off date for the questionaire and > > the town hall meeting should hopefully fix that. > > My basic idea is to have the question finished and in the wiki after the > first half of the nomination period is over. I'd also suggest the > answers should get sent in no later than "end of nomination period" + > something like 2 or 3 days. > > That way the total time of the whole the election business stays roughly > the same. People that are late with the nomination then only have > something like two or three days to answer the question, but that's > their decision -- they could have had 9 or10 days if they had chosen to > nominated earlier. Thorsten, if you get a chance, would you mind hanging a link off the wiki's [[Elections]] page with a brief summary of the procedure you used, and/or any suggestions for improvements? When it comes time for the next election we can refer to it. If you're willing and able then to fill that role, you can refer to it; and if not, we'll be able to carry on as needed. -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On Fri, Jun 5, 2009 at 1:18 PM, Joe Nall wrote: > > On Jun 5, 2009, at 1:57 PM, Adam Williamson wrote: > >> On Fri, 2009-06-05 at 14:40 -0400, Matthias Clasen wrote: >>> >>> On Fri, 2009-06-05 at 10:31 -0700, Adam Williamson wrote: >>> It seems to me it'd make sense to convert all these kinds of snippets into macros. Am I right, or is there a reason against doing this? >>> >>> When this was discussed for the example of GConf schemas in the >>> packaging committee a few weeks ago, there was quite a bit of pushback >>> about 'obscure macros' hiding whats really going on... >> >> Honestly, that just sounds silly. It's not obscuring things, it's a >> sensible level of abstraction and reuse. >> >> I suspect you'd have trouble selling that position to developers - >> "instead of calling functions from obscure external libraries, just copy >> and paste the code from them into every single app you build!" I don't >> think that'd go down a storm. ;) > > Libraries have well defined error handling. Macros can get pretty mysterious > when they start failing. Poor analogy. > ??? There are tons of bugs I have dealt with where a library has gone off into some mysterious way that didn't follow defined error handling. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On Jun 5, 2009, at 1:57 PM, Adam Williamson wrote: On Fri, 2009-06-05 at 14:40 -0400, Matthias Clasen wrote: On Fri, 2009-06-05 at 10:31 -0700, Adam Williamson wrote: It seems to me it'd make sense to convert all these kinds of snippets into macros. Am I right, or is there a reason against doing this? When this was discussed for the example of GConf schemas in the packaging committee a few weeks ago, there was quite a bit of pushback about 'obscure macros' hiding whats really going on... Honestly, that just sounds silly. It's not obscuring things, it's a sensible level of abstraction and reuse. I suspect you'd have trouble selling that position to developers - "instead of calling functions from obscure external libraries, just copy and paste the code from them into every single app you build!" I don't think that'd go down a storm. ;) Libraries have well defined error handling. Macros can get pretty mysterious when they start failing. Poor analogy. joe As long as there's a clear and sensible policy for how macros should be implemented (what the files should be called and what packages they should go in), they wouldn't be 'obscure' at all. All you'd need to do to check what a given macro did would be 'grep (macroname) /etc/rpm/macros.*' or something similar. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On 06/05/2009 11:59 AM, Adam Williamson wrote: > On Fri, 2009-06-05 at 11:43 -0700, Toshio Kuratomi wrote: >> The way to get these changed is to first go through the Packaging >> Committee to get the changes approved, then have the macros merged into >> the packages that will provide them. Then patch the packages that >> should be updated. > > Would it be best to have the concrete implementation (or at least some > examples) built before taking it to the packaging committee, or no? > Yes it would. We'd want to end up with a list of the macros to use in specific circumstances rather than the expanded form that's currently there. In doing that, we'd want to test that the new Guidelines work, so having the concrete implementation is necessary. If this sounds daunting, doing a few at a time is certainly possible. >> Note: I remember one argument against macros being that they make spec >> files harder to port between distros but I'm not willing to champion >> that argument. If someone else does, I'll certainly listen to the >> reasoning, though. :-) > > The obvious answer to that is to try and standardize macro usage between > distributions, not to not use macros. For e.g., I revamped the Mandriva > Tcl packaging policy late last year: I took the macro names and even > code snippets from Fedora's Tcl policy. I just implemented them as > system-wide macros in the tcl-devel package instead of writing in the > policy that they should be re-defined at the top of every spec file :) That would be great! -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: (Most) Results from the Candidate Questionnaire are available now
On 03.06.2009 23:02, Tom "spot" Callaway wrote: > On 06/03/2009 04:55 PM, Josh Boyer wrote: >> On Wed, Jun 03, 2009 at 04:24:16PM -0400, Bill Nottingham wrote: >>> Thorsten Leemhuis (fed...@leemhuis.info) said: The answers are quite interesting and as far as I can see can be quite helpful to decide whom to (not) vote for. So if you plan to vote in the elections I'd suggest you go and read the answers! >>> Thanks for doing this! >> >> Agreed, thanks. >> >> I'd like to add that if anyone want's follow ups to answers, feel free to >> email the candidates too! > > A great big me too here. Also, if anyone isn't able to attend the > townhall meetings, I'd be happy to answer any questions sent to me via > email. I don't want to discourage that at all, but would like to make a general remark -- partly as a reminder for the next elections. One thing I really liked about the whole candidate questionnaire: The answers came in as private mails and went public in (nearly) one go. That way those nominees that were late with sending in answers had no chance to look at the answers from the other candidates ;-) CU knurd -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On Fri, 5 Jun 2009, Adam Williamson wrote: On Fri, 2009-06-05 at 11:43 -0700, Toshio Kuratomi wrote: To some extent, yes. macros can go overboard, though. I think that the macros you're planning are going to make sense, though :-) Thanks. The way to get these changed is to first go through the Packaging Committee to get the changes approved, then have the macros merged into the packages that will provide them. Then patch the packages that should be updated. Would it be best to have the concrete implementation (or at least some examples) built before taking it to the packaging committee, or no? Note: I remember one argument against macros being that they make spec files harder to port between distros but I'm not willing to champion that argument. If someone else does, I'll certainly listen to the reasoning, though. :-) The obvious answer to that is to try and standardize macro usage between distributions, not to not use macros. For e.g., I revamped the Mandriva Tcl packaging policy late last year: I took the macro names and even code snippets from Fedora's Tcl policy. I just implemented them as system-wide macros in the tcl-devel package instead of writing in the policy that they should be re-defined at the top of every spec file :) Yah. let's get the rpm macros standardized at the lsb. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, 2009-06-05 at 16:32 +0300, Nicu Buculei wrote: > On 06/05/2009 04:14 PM, Matthias Clasen wrote: > > On Fri, 2009-06-05 at 14:04 +0300, Nicu Buculei wrote: > > > >> Now F11 is a new low: when pressing the scan or preview buttons from > >> either xsane-gimp or gnomescan the result is X crashing and me seeing > >> the GDM screen. > > > > X crashing does not sound like something related to scanning in > > particular; but it is certainly a bug worth filing, especially if it is > > easily reproducible. > > I was not sure on which component should it be reported to, X, > sane-backends/fronteds, gnomescan, xsane. > > It crashes every time when I am trying to scan with a GUI, the only way > to do somehing without a crash is using scanimage from commandline, > which is aborting with "scanimage: received signal 15". > Before reporting, you might want to try the command line scanner tool scanimage: scanimage --format=tiff --reslution=300 > scan.tiff and see what happens. That should help you understand if the issue is with sane-backends or elsewhere. The -L and -T options will be usefull too. You may also want to try the new 1.0.20 release as that fixes quite a few bugs. There is a feature request for it, but compiling it yourself is not that hard if you first do a rpm rebuild on the old rpm package so it pulls in required dependencies Use the following script to run configure: #!/bin/bash set -x arch=`uname -m` case $arch in x86_64) lib=/usr/lib64 ;; *) lib=/usr/lib esac echo "lib =" $lib make distclean BACKENDS="pixma niash" ./configure \ --prefix=/usr \ --libdir=$lib \ --sysconfdir=/etc \ --with-gphoto2=/usr \ --with-docdir=/usr/doc/sane-1.1.0 best regards, Louis > -- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESco meeting summary for 20090605
On Fri, 5 Jun 2009 14:56:34 -0400 "Paul W. Frields" wrote: > On Fri, Jun 05, 2009 at 11:51:42AM -0600, Kevin Fenzi wrote: > > If this format is acceptable, I would like to see all irc meetings > > use it, and have them all transfer to a common location with search > > ability. If not, we will come up with something better. > > We should probably try to have these transferred to the wiki, under > the Meeting: namespace, with an appropriate category assigned. > Perhaps the bot could be given an account that would allow that > access? That would be great, but it currently has no ability to talk to a wiki. The upstream page at http://wiki.debian.org/MeatBot has: Wishlist: Publish to a wiki page? (I'll do it if someone gives me wiki-posting code) So, perhaps someone could contribute that. :) Currently it just writes logs/summary to a local filesystem. kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: (Most) Results from the Candidate Questionnaire are available now
Sorry, was a bit busy over the past few days and didn't get around to answer all mails. On 04.06.2009 00:30, Andreas Thienemann wrote: > On Wed, 3 Jun 2009, Paul W. Frields wrote: [...] >> I'm disappointed this ended up being a more difficult process than you >> intended, but I have no doubt we can improve it for the next cycle. > Leaving a bit more time between the cut-off date for the questionaire and > the town hall meeting should hopefully fix that. My basic idea is to have the question finished and in the wiki after the first half of the nomination period is over. I'd also suggest the answers should get sent in no later than "end of nomination period" + something like 2 or 3 days. That way the total time of the whole the election business stays roughly the same. People that are late with the nomination then only have something like two or three days to answer the question, but that's their decision -- they could have had 9 or10 days if they had chosen to nominated earlier. CU knurd -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On Fri, 2009-06-05 at 11:43 -0700, Toshio Kuratomi wrote: > To some extent, yes. macros can go overboard, though. I think that the > macros you're planning are going to make sense, though :-) Thanks. > The way to get these changed is to first go through the Packaging > Committee to get the changes approved, then have the macros merged into > the packages that will provide them. Then patch the packages that > should be updated. Would it be best to have the concrete implementation (or at least some examples) built before taking it to the packaging committee, or no? > Note: I remember one argument against macros being that they make spec > files harder to port between distros but I'm not willing to champion > that argument. If someone else does, I'll certainly listen to the > reasoning, though. :-) The obvious answer to that is to try and standardize macro usage between distributions, not to not use macros. For e.g., I revamped the Mandriva Tcl packaging policy late last year: I took the macro names and even code snippets from Fedora's Tcl policy. I just implemented them as system-wide macros in the tcl-devel package instead of writing in the policy that they should be re-defined at the top of every spec file :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On Fri, 2009-06-05 at 14:40 -0400, Matthias Clasen wrote: > On Fri, 2009-06-05 at 10:31 -0700, Adam Williamson wrote: > > > > > It seems to me it'd make sense to convert all these kinds of snippets > > into macros. Am I right, or is there a reason against doing this? > > > > When this was discussed for the example of GConf schemas in the > packaging committee a few weeks ago, there was quite a bit of pushback > about 'obscure macros' hiding whats really going on... Honestly, that just sounds silly. It's not obscuring things, it's a sensible level of abstraction and reuse. I suspect you'd have trouble selling that position to developers - "instead of calling functions from obscure external libraries, just copy and paste the code from them into every single app you build!" I don't think that'd go down a storm. ;) As long as there's a clear and sensible policy for how macros should be implemented (what the files should be called and what packages they should go in), they wouldn't be 'obscure' at all. All you'd need to do to check what a given macro did would be 'grep (macroname) /etc/rpm/macros.*' or something similar. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESco meeting summary for 20090605
On Fri, Jun 05, 2009 at 11:51:42AM -0600, Kevin Fenzi wrote: > If this format is acceptable, I would like to see all irc meetings use > it, and have them all transfer to a common location with search > ability. If not, we will come up with something better. We should probably try to have these transferred to the wiki, under the Meeting: namespace, with an appropriate category assigned. Perhaps the bot could be given an account that would allow that access? -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On 06/05/2009 10:31 AM, Adam Williamson wrote: > It seems to me it'd make sense to convert all these kinds of snippets > into macros. Am I right, or is there a reason against doing this? > > If I'm right, I'm happy to work on this and contribute it as patches to > the relevant packages, or as a new package in itself, or something. > Where should such macros go? Should we have a separate package for them > which is brought in when you install the development environment package > set? Or should they be added to the appropriate -devel packages - e.g., > Tcl snippets should be turned into a /etc/rpm/macros.tcl that's in the > tcl-devel package? Or a combination of the two? > To some extent, yes. macros can go overboard, though. I think that the macros you're planning are going to make sense, though :-) The way to get these changed is to first go through the Packaging Committee to get the changes approved, then have the macros merged into the packages that will provide them. Then patch the packages that should be updated. Note: I remember one argument against macros being that they make spec files harder to port between distros but I'm not willing to champion that argument. If someone else does, I'll certainly listen to the reasoning, though. :-) -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On Fri, 2009-06-05 at 10:31 -0700, Adam Williamson wrote: > > It seems to me it'd make sense to convert all these kinds of snippets > into macros. Am I right, or is there a reason against doing this? > When this was discussed for the example of GConf schemas in the packaging committee a few weeks ago, there was quite a bit of pushback about 'obscure macros' hiding whats really going on... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESco meeting summary for 20090605
On Fri, 05 Jun 2009 11:30:02 -0700 Toshio Kuratomi wrote: > On 06/05/2009 10:51 AM, Kevin Fenzi wrote: > > We are trying out a meeting irc bot plugin to handle meetings in a > > more consisent and timely manner. > > > > You can find a copy of the meeting output at: > > > > http://www.scrye.com/~kevin/fedora/fedora-meeting/2009/fedora-meeting.2009-06-05-17.00.html > > > > We would appreciate feedback on this format for meeting logs. > > > > If this format is acceptable, I would like to see all irc meetings > > use it, and have them all transfer to a common location with search > > ability. If not, we will come up with something better. > > > > kevin > > > Notting's #agreed note wasn't picked up by meetbot: > 17:30:11 #agreed rsync should be fixed in the same manner Yes, this command is only available to the chair of the meeting. ;( We will likely just add all the voting fesco folks to the chair list for it to work. Alternately, we can make sure the chair always does those if there is an agreement. > > -Toshio > kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESco meeting summary for 20090605
Toshio Kuratomi (a.bad...@gmail.com) said: > Notting's #agreed note wasn't picked up by meetbot: > 17:30:11 #agreed rsync should be fixed in the same manner The bot only listens to the defined meeting chair for certain items; we'll get this fixed up for later meetings. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
Adam Williamson wrote:
> %{!?tcl_version: %global tcl_version %(echo 'puts $tcl_version' | tclsh)}
> %{!?tcl_sitelib: %global tcl_sitelib %{_datadir}/tcl%{tcl_version}}"
>
> %{!?python_sitelib: %global python_sitelib %(%{__python} -c "from
> distutils.sysconfig import get_python_lib; print get_python_lib()")}"
This kind of stuff should really be provided in RPM macros in a package
which is BRed anyway (tcl resp. python themselves are good candidates). I
really don't see why the macro has to be defined by the specfile itself,
that makes no sense. For KDE 4, that kind of macros is defined by
kde-filesystem. MinGW does the same in mingw32-filesystem now. It's also
kinda silly to have to query the tcl or python binary at runtime for this.
The RPM macro should be set to a constant value by a package which KNOWS
the constant value (again, like it is in KDE and MinGW, we're not calling
kde4-config each time to figure out where to put files!).
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESco meeting summary for 20090605
On 06/05/2009 10:51 AM, Kevin Fenzi wrote: > We are trying out a meeting irc bot plugin to handle meetings in a more > consisent and timely manner. > > You can find a copy of the meeting output at: > > http://www.scrye.com/~kevin/fedora/fedora-meeting/2009/fedora-meeting.2009-06-05-17.00.html > > We would appreciate feedback on this format for meeting logs. > > If this format is acceptable, I would like to see all irc meetings use > it, and have them all transfer to a common location with search > ability. If not, we will come up with something better. > > kevin > Notting's #agreed note wasn't picked up by meetbot: 17:30:11 #agreed rsync should be fixed in the same manner -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GDM Language list...
Ankitkumar Rameshchandra Patel wrote: > There is yet another dependency of "internet connection" here... An Internet connection (and a reasonably fast one at that) is basically required to use Fedora effectively. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESco meeting summary for 20090605
Here also is the full txt file of the meeting: 17:00:15 #startmeeting 17:00:28 #meetingtopic FESCo Meeting - https://fedorahosted.org/fesco/report/9 17:00:38 nirik: you drive this meeting, I'm not sure how to operate this new-fangled thing :D 17:00:57 happy to. I was going to make that the first topic. ;) 17:01:10 * nirik thought jds2001 wasn't going to be around today. Moving done? 17:01:36 that was yesterday. 17:01:41 wait, what thing? 17:01:46 I still have boxes all around :( 17:01:51 jwb: fedbot 17:01:57 so we're not doing gobby? 17:02:00 * dgilmore is here 17:02:17 we could try each I guess. 17:02:21 well, lets go ahead and discuss which we want to do... 17:02:25 #topic ticket 158: Create new meeting summary procedure 17:02:28 fedbot 17:02:33 because i don't have gobby setup :) 17:02:49 so, this is a plugin to supybot, created by the fine debian folks. 17:03:10 it runs the meeting and produces a log and summary and such. 17:03:29 examples of the summaries? 17:03:30 nirik: i like the idea its something everyone can use and we can post all meetings logs to a common location 17:03:43 * nirik is digging up a example. 17:03:58 http://www.scrye.com/~kevin/fedora/fedora-meeting/2009/fedora-meeting.2009-06-04-16.33.html 17:04:06 this was the IRC Support sig meeting yesterday. 17:04:13 dgilmore: yeah, I would like that too. 17:04:27 we could still use both 17:04:29 currently it's running on my machine here, but we could easily add it to zodbot and get it on a fedora location. 17:04:43 so, it's all keyword based? 17:04:44 nirik, could have febot log to gobby 17:04:54 notting: yeah. 17:04:57 #commands 17:05:10 we need a #gobby 17:05:11 :) 17:05:18 nirik: is it packaged? 17:05:23 hm. it might be simpler, i'm not sure if it will end up more legible on the list/wiki 17:05:29 this does more than log, it does summary and such. 17:05:41 jds2001: not yet. I can do so. 17:05:49 notting, at this point i think we should just focus on getting something there consistently 17:05:54 notting, cleanup can happen later 17:06:04 jwb: right, but that can be done by just assigning someone :) 17:06:13 I would like all meetings to use the same format and go the same place and be searchable. ;) 17:06:13 notting: i could setup something like http://fp.o/meetings/ 17:06:22 to point to the right spot on noc1. 17:06:32 nirik: yep 17:06:42 notting, true. but robots are soo much cooler 17:06:48 we have a bunch in the wiki as well. 17:06:49 so that we dont have to put it on the wiki. 17:06:52 Meeting: space 17:07:10 jds2001: well, we'd still want them all (both before and after we change) in the same place 17:07:12 but the wiki search is... suboptimal 17:07:51 nirik: i google site:fedoraproject.org :( 17:08:13 so, I guess I think this is usable, but if we just want to assign a minutes taker, or try gobby, or whatever I am open to it if people feel its better. 17:08:43 * abadger1999 notes that we should make sure the logs get backed up. 17:08:46 perhaps ask for feedback from people who read logs after this meeting? 17:08:59 nirik: works for me 17:09:12 abadger1999: noc1 gets backed up, right? 17:09:14 * nirik nods. I backup the machine they are on here. ;) But yes, if they go to noc1 they should get backed up 17:09:20 if we add this plugin to zodbot? 17:09:43 jds2001: I don't know, thus: make sure ;-) 17:09:52 nirik: maybe take the log from this and post it on the wiki, get comments, and we can move everything together later? 17:10:29 well, not sure it would post right to the wiki. It expects to be it's own html/txt file. 17:10:37 but yes, I can ask for feedback from it. 17:10:51 it does allow logs to be posted right when the meeting is done, which is nice. 17:11:06 also links to the items in the logs, etc. 17:11:50 * nirik waits for any other votes/opinions. 17:12:05 i'm good with either 17:12:32 the bot looks good 17:12:38 i like the bot. 17:12:49 * j-rod happy w/the bot, knows nothing of gobby at all though 17:13:19 #action nirik will post the summary/logs from the meeting plugin for comment/feedback on fedora-devel. 17:13:24 ok, shall we move on? 17:14:07 #topic ticket 159: FPC report - 2009-06-02 17:14:11 .fesco 159 17:14:14 nirik: #159 (FPC report - 2009-06-02) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/159 17:14:30 +1 17:14:45 +1 17:14:58 +1 17:14:59 +1 17:14:59 seems reasonable to reduce the number of duplicate things in spec files... +1 here. 17:15:24 n+1 17:16:11 #agreed Approval for ticket 159 (phase out BuildRoot tag) from FPC. 17:16:32 #topic ticket 134: Approval needed - zsync needs to ship internal zlib for rsync compatibility 17:16:36 .fesco 134 17:16:42 nirik: #134 (Approval needed - zsync needs to ship internal zlib for rsync compatibility) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/134 17:17:01 -1, if at all technically possible 17:17:17 -1 17:17:23 -1 17:17:27 yeah, I don't want to allow an
Re: FESco meeting summary for 20090605
On Fri, Jun 05, 2009 at 11:51:42AM -0600, Kevin Fenzi wrote: > We are trying out a meeting irc bot plugin to handle meetings in a more > consisent and timely manner. > > You can find a copy of the meeting output at: > > http://www.scrye.com/~kevin/fedora/fedora-meeting/2009/fedora-meeting.2009-06-05-17.00.html > > We would appreciate feedback on this format for meeting logs. > > If this format is acceptable, I would like to see all irc meetings use > it, and have them all transfer to a common location with search > ability. If not, we will come up with something better. Holy moley Kevin, this is great! -- Paul W. Frieldshttp://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On Fri, 5 Jun 2009, Nathanael D. Noblet wrote:
[...]
It seems to me it'd make sense to convert all these kinds of snippets
into macros. Am I right, or is there a reason against doing this?
It would be awesome to get rid of the boilerplate. Honestly though,
I'd rather the solution was "just works" than "replace giant glob of
muck with %{glob_of_muck}"
For instance, if a file gets dropped under /usr/share/icons/something
rpm should run gtk-update-icon-cache /usr/share/icons/something
automatically.
the gtk2 package should be able to drop a file in /usr/lib/rpm/redhat
that makes that happen. likewise, desktop-file-utils should be able
to drop a file there to make update-desktop-database get run and so
on.
I don't know how hard it would be to fix rpm to allow for that though.
Just off the top of my head, this doesn't feel like something rpm should be
in charge of. To me it seems more likely that we need something in a
base/core rpm that installs an inotify script for system dirs that does what
it should when something is dropped into it...?
1. file-globs-based actions means it works for everything
2. inotify doesn't work on FS
3. inotify can't be run for ALL FILES
things are happening to make it possible to do the above in rpm.
-sv
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On Fri, 2009-06-05 at 13:50 -0400, Ray Strode wrote:
> > It seems to me it'd make sense to convert all these kinds of snippets
> > into macros. Am I right, or is there a reason against doing this?
> It would be awesome to get rid of the boilerplate. Honestly though,
> I'd rather the solution was "just works" than "replace giant glob of
> muck with %{glob_of_muck}"
Yes indeed, this would be best in many cases. Some can't really be done
like that, though - like the snippets for Tcl and Python to define the
version, directories for certain types of file and so on. They're
just...informational. Defining them as macros seems the optimal
solution.
> For instance, if a file gets dropped under /usr/share/icons/something
> rpm should run gtk-update-icon-cache /usr/share/icons/something
> automatically.
>
> the gtk2 package should be able to drop a file in /usr/lib/rpm/redhat
> that makes that happen. likewise, desktop-file-utils should be able
> to drop a file there to make update-desktop-database get run and so
> on.
>
> I don't know how hard it would be to fix rpm to allow for that though.
This is definitely possible; Mandriva (I know I talk about MDV a lot,
I'm sorry, it's what I know! :>) does this, via an implementation called
'file triggers'. This is not yet upstream, though.
The MDV patch that implements this is:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/rpm/current/SOURCES/rpm-4.6.0-rc1-filetriggers.patch?view=markup
MDV's wiki discussion of it is here:
http://wiki.mandriva.com/en/Rpm_filetriggers
It appears to be something upstream has thought about several times.
Here's an RPM 5 community discussion of it, with Jeff Johnson's
thoughts:
http://rpm5.org/community/rpm-devel/2959.html
Here's a discussion from the rpm.org Wiki:
http://www.rpm.org/wiki/Problems/Scriptlets
I'm not sure what the current status is for rpm.org - whether they're
actively working on a solution for this side of things or what.
Oh, and please try to consider the original proposal in replies to this
thread, as I sense a derail coming :). file triggers is certainly an
interesting topic, but there are some snippets which just don't fit the
case, see above.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
Casey Dahlin wrote: Nathanael D. Noblet wrote: I don't know how hard it would be to fix rpm to allow for that though. Just off the top of my head, this doesn't feel like something rpm should be in charge of. To me it seems more likely that we need something in a base/core rpm that installs an inotify script for system dirs that does what it should when something is dropped into it...? Ugh, no. We don't need another running service to do this. Just have rpm do it as part of its post install and you don't need to involve inotify; it knows a file showed up because it put it there a few milliseconds ago. Inotify isn't a service/daemon, and its running already afaik?? -- Nathanael d. Noblet T: 403.875.4613 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
Nathanael D. Noblet wrote: >> >> I don't know how hard it would be to fix rpm to allow for that though. > > Just off the top of my head, this doesn't feel like something rpm should > be in charge of. To me it seems more likely that we need something in a > base/core rpm that installs an inotify script for system dirs that does > what it should when something is dropped into it...? > Ugh, no. We don't need another running service to do this. Just have rpm do it as part of its post install and you don't need to involve inotify; it knows a file showed up because it put it there a few milliseconds ago. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
Ray Strode wrote:
Hi,
On Fri, Jun 5, 2009 at 1:31 PM, Adam Williamson wrote:
I've been dipping my toes into packaging things for Fedora lately, and
one thing that feels a bit awkward is that the packaging guidelines are
full of boilerplate like:
[...]
Heck, there's an entire page full of these:
https://fedoraproject.org/wiki/Packaging/ScriptletSnippets
[...]
It seems to me it'd make sense to convert all these kinds of snippets
into macros. Am I right, or is there a reason against doing this?
It would be awesome to get rid of the boilerplate. Honestly though,
I'd rather the solution was "just works" than "replace giant glob of
muck with %{glob_of_muck}"
For instance, if a file gets dropped under /usr/share/icons/something
rpm should run gtk-update-icon-cache /usr/share/icons/something
automatically.
the gtk2 package should be able to drop a file in /usr/lib/rpm/redhat
that makes that happen. likewise, desktop-file-utils should be able
to drop a file there to make update-desktop-database get run and so
on.
I don't know how hard it would be to fix rpm to allow for that though.
Just off the top of my head, this doesn't feel like something rpm should
be in charge of. To me it seems more likely that we need something in a
base/core rpm that installs an inotify script for system dirs that does
what it should when something is dropped into it...?
--
Nathanael d. Noblet
T: 403.875.4613
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
FESco meeting summary for 20090605
We are trying out a meeting irc bot plugin to handle meetings in a more consisent and timely manner. You can find a copy of the meeting output at: http://www.scrye.com/~kevin/fedora/fedora-meeting/2009/fedora-meeting.2009-06-05-17.00.html We would appreciate feedback on this format for meeting logs. If this format is acceptable, I would like to see all irc meetings use it, and have them all transfer to a common location with search ability. If not, we will come up with something better. kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning nopaste // ruby help wanted for broken package
Iain Arnell wrote: > On Fri, Jun 5, 2009 at 7:34 PM, Casey Dahlin wrote: >> Simon Wesp wrote: >>> Dear List, >>> >>> >>> short version: >>> >>> I'm going to orphan nopaste since rafb.net/paste, which was used by >>> this package, is discontinued (bug #504108). >>> I tried to contact upstream four times and asked if they were planning >>> to switch to another provider, but no avail >>> If someone with ruby skills is able to rewrite nopaste for another >>> pastebin, he/she is welcome to take over the package. > > woot.!I Was meaning to contact you about this.I already own > perl-App-Nopaste whiich can also proveide /usr/bin/nopatse (with lots > more possibilities than rafb). More than happy to obsolete/provide > (and extend to support fpaste too). > > If anyone beats me too it - iwannit! > You can have it. Your solution sounds better. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
Hi,
On Fri, Jun 5, 2009 at 1:31 PM, Adam Williamson wrote:
> I've been dipping my toes into packaging things for Fedora lately, and
> one thing that feels a bit awkward is that the packaging guidelines are
> full of boilerplate like:
[...]
>
> Heck, there's an entire page full of these:
>
> https://fedoraproject.org/wiki/Packaging/ScriptletSnippets
>
[...]
> It seems to me it'd make sense to convert all these kinds of snippets
> into macros. Am I right, or is there a reason against doing this?
It would be awesome to get rid of the boilerplate. Honestly though,
I'd rather the solution was "just works" than "replace giant glob of
muck with %{glob_of_muck}"
For instance, if a file gets dropped under /usr/share/icons/something
rpm should run gtk-update-icon-cache /usr/share/icons/something
automatically.
the gtk2 package should be able to drop a file in /usr/lib/rpm/redhat
that makes that happen. likewise, desktop-file-utils should be able
to drop a file there to make update-desktop-database get run and so
on.
I don't know how hard it would be to fix rpm to allow for that though.
--Ray
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning nopaste // ruby help wanted for broken package
On Fri, Jun 5, 2009 at 7:34 PM, Casey Dahlin wrote: > Simon Wesp wrote: >> Dear List, >> >> >> short version: >> >> I'm going to orphan nopaste since rafb.net/paste, which was used by >> this package, is discontinued (bug #504108). >> I tried to contact upstream four times and asked if they were planning >> to switch to another provider, but no avail >> If someone with ruby skills is able to rewrite nopaste for another >> pastebin, he/she is welcome to take over the package. woot.!I Was meaning to contact you about this.I already own perl-App-Nopaste whiich can also proveide /usr/bin/nopatse (with lots more possibilities than rafb). More than happy to obsolete/provide (and extend to support fpaste too). If anyone beats me too it - iwannit! -- Iain. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning nopaste // ruby help wanted for broken package
Simon Wesp wrote: > Dear List, > > > short version: > > I'm going to orphan nopaste since rafb.net/paste, which was used by > this package, is discontinued (bug #504108). > I tried to contact upstream four times and asked if they were planning > to switch to another provider, but no avail > If someone with ruby skills is able to rewrite nopaste for another > pastebin, he/she is welcome to take over the package. > > I do ruby. I'd be willing to look when I get home today. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: orphaning nopaste // ruby help wanted for broken package
On Fri, 2009-06-05 at 19:02 +0200, Simon Wesp wrote: > Dear List, > > > short version: > > I'm going to orphan nopaste since rafb.net/paste, which was used by > this package, is discontinued (bug #504108). > I tried to contact upstream four times and asked if they were planning > to switch to another provider, but no avail > If someone with ruby skills is able to rewrite nopaste for another > pastebin, he/she is welcome to take over the package. I'm no ruby-ite so I can't fix it for you, but a quick hint: my favourite pastebin, http://www.pastie.org/ , seems to be very Ruby-ish - it's written in RoR, defaults to Ruby syntax, etc - so it would seem like a natural fit here... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
Just wanted to run this by the group to make sure it's desired before I
start working on it...
I've been dipping my toes into packaging things for Fedora lately, and
one thing that feels a bit awkward is that the packaging guidelines are
full of boilerplate like:
"Use this when a desktop entry has a 'MimeType key.
%post
update-desktop-database &> /dev/null || :
%postun
update-desktop-database &> /dev/null || :"
"noarch packages
The following macros must be used at the top of the spec file to
determine the correct installation paths:
%{!?tcl_version: %global tcl_version %(echo 'puts $tcl_version' | tclsh)}
%{!?tcl_sitelib: %global tcl_sitelib %{_datadir}/tcl%{tcl_version}}"
"If you are installing anything into the global site_packages directory,
use the following trick. First, define python_sitelib at the top of your
specfile:
%{!?python_sitelib: %global python_sitelib %(%{__python} -c "from
distutils.sysconfig import get_python_lib; print get_python_lib()")}"
Heck, there's an entire page full of these:
https://fedoraproject.org/wiki/Packaging/ScriptletSnippets
it seems to me that this is a bit of a silly approach - it encourages
cut and paste errors (or people cutting and pasting non-canonical blocks
from other people's spec files), it just looks bad in spec files, and if
any of those snippets happens to need to be changed a bit - say, the
syntax for updating the desktop database changes, or something - we'd
have to adjust them in seven zillion different spec files.
It seems to me it'd make sense to convert all these kinds of snippets
into macros. Am I right, or is there a reason against doing this?
If I'm right, I'm happy to work on this and contribute it as patches to
the relevant packages, or as a new package in itself, or something.
Where should such macros go? Should we have a separate package for them
which is brought in when you install the development environment package
set? Or should they be added to the appropriate -devel packages - e.g.,
Tcl snippets should be turned into a /etc/rpm/macros.tcl that's in the
tcl-devel package? Or a combination of the two?
Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, 2009-06-05 at 17:56 +0100, Daniel P. Berrange wrote: > On Fri, Jun 05, 2009 at 12:50:40PM -0400, Matthias Clasen wrote: > > On Fri, 2009-06-05 at 09:35 -0700, Adam Williamson wrote: > > > > > So I think the gnome-scan interface is nice but if my results are > > > reproduced by others, we can't really replace xsane with it until it's a > > > bit less buggy. It would be nice if any coders with scanning interest > > > could contribute to the code I guess (I'm unfortunately not a coder). > > > > IMO the obnoxious license dialog that xsane still subjects you to is > > sufficient reason already to replace it. We don't tolerate dialogs like > > that in other default-installed components... > > Why don't we patch it out then > Ok, lets try that: https://bugzilla.redhat.com/show_bug.cgi?id=504344 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
orphaning nopaste // ruby help wanted for broken package
Dear List, short version: I'm going to orphan nopaste since rafb.net/paste, which was used by this package, is discontinued (bug #504108). I tried to contact upstream four times and asked if they were planning to switch to another provider, but no avail If someone with ruby skills is able to rewrite nopaste for another pastebin, he/she is welcome to take over the package. long version: I'm the maintainer (not a good one) of "nopaste". I was wondering myself that the pasteservice of rafb.net/paste closed on my birthday. I contacted the upstream of nopaste on the same day (25th May), 3 days later, a week later, and yesterday. I wrote him the situation and my problem (i believe the same problem is in gentoo, too, because they have nopsate, too[didn't find a solution @ gentoo]) and I hint at the urgency. Nothing happened. :-( Yesterday I got the bug #504108. I can't ruby, so I can't fix it. I took over the review from Phillip Baum, who discarded the idea to become a Fedora packager. My most important question is: Can anybody wrote the script to fpaste.org or an other pastebin, to continue the life of this package in fedora? I will hand over the package to the guy(s) who can fix this, of course. I'm really awfully sorry, for orphaning this package with an open bug. :-( -- Mit freundlichen Grüßen aus dem schönen Hainzell Simon Wesp The G in GNU stands for GNU http://fedoraproject.org/wiki/SimonWesp signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, Jun 05, 2009 at 12:50:40PM -0400, Matthias Clasen wrote: > On Fri, 2009-06-05 at 09:35 -0700, Adam Williamson wrote: > > > So I think the gnome-scan interface is nice but if my results are > > reproduced by others, we can't really replace xsane with it until it's a > > bit less buggy. It would be nice if any coders with scanning interest > > could contribute to the code I guess (I'm unfortunately not a coder). > > IMO the obnoxious license dialog that xsane still subjects you to is > sufficient reason already to replace it. We don't tolerate dialogs like > that in other default-installed components... Why don't we patch it out then Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
Matthias Clasen (mcla...@redhat.com) said: > > So I think the gnome-scan interface is nice but if my results are > > reproduced by others, we can't really replace xsane with it until it's a > > bit less buggy. It would be nice if any coders with scanning interest > > could contribute to the code I guess (I'm unfortunately not a coder). > > IMO the obnoxious license dialog that xsane still subjects you to is > sufficient reason already to replace it. We don't tolerate dialogs like > that in other default-installed components... Not to go all Ubuntu on everyone, but we have a patch command. We should use it. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, 2009-06-05 at 09:35 -0700, Adam Williamson wrote: > So I think the gnome-scan interface is nice but if my results are > reproduced by others, we can't really replace xsane with it until it's a > bit less buggy. It would be nice if any coders with scanning interest > could contribute to the code I guess (I'm unfortunately not a coder). IMO the obnoxious license dialog that xsane still subjects you to is sufficient reason already to replace it. We don't tolerate dialogs like that in other default-installed components... Matthias -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some pulseaudio questions...
On Fri, 2009-06-05 at 11:11 -0400, Jon Masters wrote: > On Fri, 2009-06-05 at 12:57 +0200, Lennart Poettering wrote: > > On Fri, 05.06.09 00:21, Jon Masters (jonat...@jonmasters.org) wrote: > > Text book RT applications use mlock()/mlockall() to lock themselves > > into memory and make sure they never are swapped out. This is > > something we cannot really do for PA given that map a *lot* of stuff > > into our address space: libraries, SHM segments for communications > > with other clients, cached samples, and so on. If we'd lock all that > > into memory there wouldn't be any memory left for much else > > Yeah, I'm aware of this. But there perhaps should be some option anyway > - after all, you already have all the support code for it, and already > handle setting real time priorities too. In my brief time with a hacked > up local build that does an mlockall right at the beginning of the > mainloop, I am hearing few audio pops and skips on this box. It's > obviously not a longer term solution, just a datapoint. I'll join the PA devel list over the weekend, it's not strictly that Fedora specific now. But one thing I'm wondering is whether you might benefit from splitting PA into a small core-util bit that were lockable and having all the rest outside in separate tasks - that's probably not too feasible at this stage though. I want to help fix whatever problems I'm getting on each of my machines running PA, rather than sound like I'm trashing talking PA as a technology. The sad reality is that Linux audio worked for me more smoothly 14 years ago when I started with Linux (and manually had to set jumpers, run isapnpdump, etc.) than it does now. It was smoother when I had early ESD[0] than it is now, and smoother when I first built experimental ALSA drivers than it is now. Things like PA are a great concept in theory, but they're not of much benefit if (as in my case) the only obvious way I can get an decent experience is to hack my system and run stuff under pasuspender. Jon. [0] And I mean alongside 0.1 enlightment, back when I had the Free Software Song as a ringtone and enjoyed hearing the startup pips as ESD opened the sound device. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, 2009-06-05 at 11:23 +0100, Bastien Nocera wrote: > Heya, > > Yesterday, I was browsing Ubuntu's "Blueprints" for their next release, > and saw this: > https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnomescan > > gnome-scan is already packaged by Deji, but I gather that more > integration work could be done to make setting up and using scanners > easier in GNOME and Fedora in general. > > Any takers? > > I think a good start would be making a list of problems seen in setting > up scanners (additional packages required, tweaks), and make sure that > gnome-scan and the necessary plugins are installed in a default > installation. > > Cheers > > /Bastien, who doesn't own a scanner I have a scanner, but it's a rather well-behaved one (an HP ScanJet 2100C). As long as SANE is installed you don't really need to do anything to set it up - you can just run GIMP or xsane directly and get to scanning. Looking at gnome-scan, I see the author is asking for help: http://blogs.gnome.org/gnome-scan/ testing it out, it seems a bit odd - it certainly has a nicer interface than xsane's horribleness, but it seems a bit weird in places. It defaulted to a rather odd scanned image size for me, and the preview tab would only show that area of the page. I then switched to the 'Letter' size on the main tab, previewed again, and the preview seemed to come out right - but I couldn't then click and drag to resize the area to be scanned. I had to go back to the main tab, switch back to 'Manual', then go back to the preview tab before I could click and drag to resize - and if I then tried to refresh the preview, it didn't preview correctly again, it only previewed a tiny corner of the area and I couldn't click and drag the selection to make it any bigger. So I think the gnome-scan interface is nice but if my results are reproduced by others, we can't really replace xsane with it until it's a bit less buggy. It would be nice if any coders with scanning interest could contribute to the code I guess (I'm unfortunately not a coder). On the packaging side of things, I would also be happy to help but it looks like we're not short of volunteers. What would be useful, I guess, is input from anyone who has a scanner that's a pain to set up, explaining what they have to do, so we could look into how we could ease that task. I may do a quick build of gnome-scan 0.7.1 to see if it addresses my problems, though that's an unstable release we may not want to package officially. The thought also occurs that this is an area that would be helped by one of my little hobby horses, the pony that I'd like to have which I call HardwareKit, which is just my name for a little widget/layer/whatever between udev/HAL/DeviceKit and PackageKit: it would allow the system to prompt you to install a given set of packages when it notes a certain piece or type of hardware being plugged in. So, in this case, if HAL/DeviceKit notices a scanner being plugged in, it could call out to PackageKit to install our scanning package group. That's something I've been wishing we had for a while now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Fri, 2009-06-05 at 09:01 -0700, Adam Williamson wrote: > On Thu, 2009-06-04 at 23:19 +0200, Edwin ten Brink wrote: > > > Aside from all discussions in this thread, the current Bugzilla > > documentation seems quite clear on this topic. Whatever the outcome of > > the discussion is, I think the documentation which is visible to the > > end-user (customer), should at least match the common practice/procedure. > > > > Note also that the discussion is primarily focussed on the Resolution of > > the bug report, while there are also two Keywords available with respect > > to upstream. I've quoted the full texts below for reference. > > > From https://bugzilla.redhat.com/describekeywords.cgi > > This page doesn't really cover Fedora policy or practice, it covers RHEL > policy and practice, which is not the same thing. Sorry, I mistook this: the page that's not strictly entirely applicable to Fedora is the one you link to lower down: https://bugzilla.redhat.com/page.cgi?id=fields.html#status not the keyword description page. We don't presently have a separate keyword description page for Fedora. I haven't looked yet at whether any of the keywords or descriptions are inapplicable to Fedora, if they are, we should probably 'branch' that page too. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Action requested: check dist tags and conditionals
Toshio Kuratomi (a.bad...@gmail.com) said:
> Does this look like the right generic structure for doing this:
>
> %if 0%{?fedora} >= X || 0%{?rhel} >= Y
> # Do things from X until Current Fedora, Y until Current RHEL
> # Y should be the latest released version if we don't know that
> # it's not going to change in the next version
> %else
> %if %{fedora} && 0%{fedora} < X && ! %{rhel}
> # Do things for Fedora < X
> %else
> %if ! %{fedora} && %{rhel} && 0%{rhel} < Y
> # Do things for RHEL < Y
> %else
> # Do things for any other distros
> %endif
> %endif
> %endif
>
> If so, then we'd want to prettify and codify it a bit so we can put it
> in the Packaging Guidelines
Looks reasonable.
Bill
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Fri, 2009-06-05 at 10:44 +0200, Jaroslav Reznik wrote: > > In other situations, you can set the UPSTREAM keyword, so the bug > > remains open but you know it's being handled upstream and you need to > > bring the fix downstream once it's available upstream. > > I like idea of some TRACKING_UPSTREAM keyword - it's easy to search and > CLOSED > bugs are not as easy to search for duplicates when you are reporting bug. As Edwin noted, there is in fact an Upstream keyword in RH Bugzilla (and a 'MoveUpstream' keyword). 'Upstream' appears only ever to have been used for two bugs, however. 'MoveUpstream' seems to have been used extensively in the past, but rarely lately: it does seem to fit the case I described, however. So, yeah, if you like this idea, use the 'MoveUpstream' keyword. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GDM Language list...
Mathieu Bridon (bochecha) wrote: How about that: 1. user chooses a language in GDM for the first time 2. PK tries to install the -support group 3. if this group exist and some packages could be installed (i.e. not already installed), the user is presented a nice PK popup, just like the font or codec install suggestion, but for the support of his language If no packages need to be installed, then the user won't be bothered by an obtrusive popup. We can do it only the first time as, well, if it doesn't work the second time, then the user specifically chose not to install them or to remove one of the required packages There is yet another dependency of "internet connection" here... -- Regards, Ankit Patel http://www.indianoss.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Rawhide moving on to Fedora 12 content
On Fri, 2009-06-05 at 10:36 -0300, Martín Marqués wrote: > > Couldn't this have waited until F11 was out? Previous releases we've waited longer, but given that F12 is a short release cycle, and that we delayed F11 release twice it was important that we get rawhide moving on for the sake of F12. > > Else the people that are testing F11-preview will be out of luck with > using yum to install or update. > > Or did I understand incorrectly the comment above? They'll have access to the updates and updates-testing repo, just not the 'fedora' repo. It is a bit of an inconvenience for users for a few days. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GDM Language list...
Bill Nottingham wrote: Well, there are languages we would support fine that don't have a specific language-support group (most anything that uses a Latin-1 like charset, and no specific input method.) Moreover, the groups that are installed aren't actually recorded anywhere on the installed system. (And having gdm attempt to discover/compute what groups are installed is completely impractical.) Bill Well, there should be hard-coded list maintained for such languages, which doesn't require any specific support packages and those languages should be listed by default in gdm. But other languages, which requires specific packages' support, should be listed only if their support is (or support packages are) installed. As Ray has mentioned "GDM only show a language in the language list if ...locale, etc meet>..." that means GDM already does some checks, so I guess there should be some way to check the installed groups. -- Regards, Ankit Patel http://www.indianoss.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Thu, 2009-06-04 at 23:19 +0200, Edwin ten Brink wrote: > Aside from all discussions in this thread, the current Bugzilla > documentation seems quite clear on this topic. Whatever the outcome of > the discussion is, I think the documentation which is visible to the > end-user (customer), should at least match the common practice/procedure. > > Note also that the discussion is primarily focussed on the Resolution of > the bug report, while there are also two Keywords available with respect > to upstream. I've quoted the full texts below for reference. > From https://bugzilla.redhat.com/describekeywords.cgi This page doesn't really cover Fedora policy or practice, it covers RHEL policy and practice, which is not the same thing. The next revision of Bugzilla will in fact include a link on this page, directing you to: https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow for the Fedora policy and practice. That page says in passing: "The resolution UPSTREAM can be used by maintainers to denote a bug that they expect to be fixed by upstream development and naturally rolled back into Fedora as part of the update process. Ideally, a comment should be added with a link to the upstream bug report." but that's just what I wrote when updating the page, it's not based on any official discussion / agreement, so I made it intentionally vague and (hopefully) non-controversial. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, 2009-06-05 at 08:56 -0400, Tom "spot" Callaway wrote: > Perhaps we could target some specific scanners on the first attempt? > We > might be able to get some hardware donated to the effort. > > ~spot, who has several scanners of varying age and quality in a box > I have a relatively new Canon Scanner, that has no current hope of working on Linux. Boy I'd love to see that changed. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Thu, 2009-06-04 at 22:53 +0200, Kevin Kofler wrote: > Adam Williamson wrote: > > If, say, the bug is in a package that gets frequent releases, and was > > filed on the development release, you can just use CLOSED UPSTREAM, > > because you can rely on the fact that there'll be a new upstream release > > of the package soon after the upstream report is fixed, you (the > > maintainer) will then naturally package the new release, and the fix for > > the bug will have been rolled into the distribution package without you > > having to do anything besides your normal packaging work. > > In fact that's what happens with KDE, bugfix releases come out once a month > in most cases (the time from the last bugfix point release to the next > feature release is a bit longer though, about 2 months upstream (blame the > folks who decided *.5 releases are not needed), plus about 2 weeks of > testing in updates-testing to prevent regressions). Indeed, KDE would be exactly the kind of project I had in mind for that scenario: it's very actively maintained and bugfix releases show up and are packaged into Fedora frequently. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GDM Language list...
>> We only show a language in the language list if >> - language-support is installed (e.g. yum groupinstall chinese-support) > > Well, there are languages we would support fine that don't have a > specific language-support group (most anything that uses a Latin-1 like > charset, and no specific input method.) Moreover, the groups that are > installed aren't actually recorded anywhere on the installed system. > (And having gdm attempt to discover/compute what groups are installed > is completely impractical.) How about that: 1. user chooses a language in GDM for the first time 2. PK tries to install the -support group 3. if this group exist and some packages could be installed (i.e. not already installed), the user is presented a nice PK popup, just like the font or codec install suggestion, but for the support of his language If no packages need to be installed, then the user won't be bothered by an obtrusive popup. We can do it only the first time as, well, if it doesn't work the second time, then the user specifically chose not to install them or to remove one of the required packages. -- Mathieu Bridon (bochecha) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
Bastien Nocera wrote: > gnome-scan is already packaged by Deji, but I gather that more > integration work could be done to make setting up and using scanners > easier in GNOME and Fedora in general. I'll semi-hijack this thread to point out that the KDE 4 (extragear) scanning solution, Skanlite, should really go into Fedora. There was a review request, but it got closed because the submitter vanished. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GDM Language list...
Ankitkumar Rameshchandra Patel (an...@redhat.com) said: > I think above checks only ensures the technical (rather i18n) support > exists. But, what about the native language desktop users who expects > fedora to be equal for all languages (just like english)? > > How about, > > We only show a language in the language list if > - language-support is installed (e.g. yum groupinstall chinese-support) Well, there are languages we would support fine that don't have a specific language-support group (most anything that uses a Latin-1 like charset, and no specific input method.) Moreover, the groups that are installed aren't actually recorded anywhere on the installed system. (And having gdm attempt to discover/compute what groups are installed is completely impractical.) Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GDM Language list...
Nicolas Mailhot wrote: Le Ven 5 juin 2009 17:03, Ray Strode a écrit : We only show a language in the language list if 1) It's got at least one translation in /usr/share/locale 2) it's recognized by libc as a valid utf8 locale 3) it's listed in iso-codes 4) it's got enough font converage to at least show it's own name in the language list. Please, the main use of the language list is to select a keyboard layout. All the keyboard defs are installed by default. Punting a user to qwerty just because those other bits are missing is not going to make anyone happy. Especially if the user password can not be typed using qwerty. Please, it's not only locale, libc, iso-codes, fonts or input-methods, but also translated applications like openoffice, firefox, etc. -- Regards, Ankit Patel http://www.indianoss.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GDM Language list...
Christoph Wickert wrote: By doing "yum install hindi-support"?! We cannot put all languages on the LiveCD because there is not enough space. Not only on LiveCD, but on Fedora main also, it's difficult to install all language-supports by default since it's very heavy task, as you said because of the space issue. So, that's the reason, I am requesting the GDM list to be shortened based on the language-supports installed. -- Regards, Ankit Patel http://www.indianoss.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GDM Language list...
Le Ven 5 juin 2009 17:03, Ray Strode a écrit : > > Hi, > >> 2. to GDM maintainers: Is it possible to change the list of >> languages >> dynamically (based on the language-supports installed) on the GDM >> login >> screen? > We only show a language in the language list if > > 1) It's got at least one translation in /usr/share/locale > 2) it's recognized by libc as a valid utf8 locale > 3) it's listed in iso-codes > 4) it's got enough font converage to at least show it's own name in > the language list. Please, the main use of the language list is to select a keyboard layout. All the keyboard defs are installed by default. Punting a user to qwerty just because those other bits are missing is not going to make anyone happy. Especially if the user password can not be typed using qwerty. -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GDM Language list...
Am Freitag, den 05.06.2009, 20:30 +0530 schrieb Ankitkumar Rameshchandra Patel: > Nicolas Mailhot wrote: > > Le Ven 5 juin 2009 15:06, Ankitkumar Rameshchandra Patel a écrit : > > > > > applications like gedit, nautilus showing square boxes instead of > > > Hindi text. > > > > > > > Actually, in F11 they'll show a nice popup suggesting to look for and > > autoinstall hindi fonts. So this part is already fixed (maybe not in > > all apps but in pango-based apps at least) > > > > > That's good to know. Thanks Nicolas. > > But, it's not only the matter of fonts, rather language support which > includes - fonts, input method (and maps), spell checker, openoffice > langpack, kde langpack and language packs for various other > applications. > > So, how are we going to solve those things? By doing "yum install hindi-support"?! We cannot put all languages on the LiveCD because there is not enough space. Currently the group hindi-support looks like this: > > hindi-support > <_name>Hindi Support > <_description/> > false > true > hi > > lohit-hindi-fonts > m17n-contrib-hindi > m17n-db-hindi > aspell-hi >requires="gcompris">gcompris-sound-hi >requires="hunspell">hunspell-hi > hyphen-hi >requires="xorg-x11-server-Xorg">ibus-m17n >requires="kdelibs3">kde-i18n-Hindi >requires="kdelibs">kde-l10n-Hindi > moodle-hi >requires="openoffice.org-core">openoffice.org-langpack-hi_IN > iok > samyak-devanagari-fonts > sarai-fonts > > Is there something you are missing? Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GDM Language list...
Ray Strode wrote: Hi, 2. to GDM maintainers: Is it possible to change the list of languages dynamically (based on the language-supports installed) on the GDM login screen? We only show a language in the language list if 1) It's got at least one translation in /usr/share/locale 2) it's recognized by libc as a valid utf8 locale 3) it's listed in iso-codes 4) it's got enough font converage to at least show it's own name in the language list. --Ray I think above checks only ensures the technical (rather i18n) support exists. But, what about the native language desktop users who expects fedora to be equal for all languages (just like english)? How about, We only show a language in the language list if - language-support is installed (e.g. yum groupinstall chinese-support) -- Regards, Ankit Patel http://www.indianoss.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some pulseaudio questions...
On Fri, 2009-06-05 at 12:57 +0200, Lennart Poettering wrote: > On Fri, 05.06.09 00:21, Jon Masters (jonat...@jonmasters.org) wrote: > > > Folks, > > > > Anyone want to clarify my understanding of PA's use of > > mlock/posix_madvise? From looking over the code - in particular > > pa_will_need, and its callsites - it looks like PA doesn't really use > > this support that it has for locking pages. Which seems weird. > > mlock() is not actually used anymore by PA on modern kernels. I noticed :) But then, neither is the posix_madvise being used that much either, as I noted. On a related note, I have revived the upstream discussion of MCL_INHERIT and will repost patches implementing this over the weekend - then I can have a simple wrapper utility to test forcing an app like PA to do an mlockall. > Text book RT applications use mlock()/mlockall() to lock themselves > into memory and make sure they never are swapped out. This is > something we cannot really do for PA given that map a *lot* of stuff > into our address space: libraries, SHM segments for communications > with other clients, cached samples, and so on. If we'd lock all that > into memory there wouldn't be any memory left for much else Yeah, I'm aware of this. But there perhaps should be some option anyway - after all, you already have all the support code for it, and already handle setting real time priorities too. In my brief time with a hacked up local build that does an mlockall right at the beginning of the mainloop, I am hearing few audio pops and skips on this box. It's obviously not a longer term solution, just a datapoint. > There is a system call for requesting swapping in of memory: > posix_madvise(POSIX_MADV_WILLNEED). Yeah, I saw that and I think it's a nice idea. I'm not sure it's being called very often though - bear in mind I only spent a few minutes looking at the source, so I might have missed something. > > I'll admit I'm about ready to hack in some horrible mlockall hacks to > > see if that'll stop the poppy/skippyness on this box. It did drastically reduce it. The box is under extremely heavy stress as it's running a lot of stuff - dozens of firefox, many evolution windows, IRC, rhythmbox, a few VMs, etc. I'm looking forward to the IO Controller patches so I can e.g. prevent evolution from hogging more than a certain amount of disk bandwidth, which I'm sure will help. > I doubt that locking PA into memory will fix your issues. If PA drops > out often this might have various reasons, but probably not > swapping. Often the timing calls of your sound driver are inaccurate > and cause PA to miss its deadlines. The Intel HDA driver on here doesn't appear to be in your badlist any more, but maybe I am wrong: 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) > To work around that you could try > disabling timer-based scheduling mode and revert to sound card IRQ > scheduled playback. For that try passing "tsched=0" to > module-hal-detect in /etc/pulse/default.pa. I will try that. > Then restart PA. Another issue might be that PA does not actually > get scheduled often enough by the kernel. I don't think it's that. There's no closed source driver installed. I also am currently running PA as an RT task and my SMI detector shows that this box is not disappearing off into SMI land too often. > Usually running "pulseaudio -v" in a terminal might give you a > hint what might be going wrong. Not very much useful output when I set it into a debug loglevel - maybe this is different. Jon. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GDM Language list...
On 6/5/09, Nicolas Mailhot wrote: > > > Le Ven 5 juin 2009 15:06, Ankitkumar Rameshchandra Patel a écrit : >> applications like gedit, nautilus showing square boxes instead of >> Hindi text. > > Actually, in F11 they'll show a nice popup suggesting to look for and > autoinstall hindi fonts. So this part is already fixed (maybe not in > all apps but in pango-based apps at least) https://fedoraproject.org/wiki/Features/AutomaticFontInstallation Regards, Parag. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GDM Language list...
Hi, > 2. to GDM maintainers: Is it possible to change the list of languages > dynamically (based on the language-supports installed) on the GDM login > screen? We only show a language in the language list if 1) It's got at least one translation in /usr/share/locale 2) it's recognized by libc as a valid utf8 locale 3) it's listed in iso-codes 4) it's got enough font converage to at least show it's own name in the language list. --Ray -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GDM Language list...
Nicolas Mailhot wrote: Le Ven 5 juin 2009 15:06, Ankitkumar Rameshchandra Patel a écrit : applications like gedit, nautilus showing square boxes instead of Hindi text. Actually, in F11 they'll show a nice popup suggesting to look for and autoinstall hindi fonts. So this part is already fixed (maybe not in all apps but in pango-based apps at least) That's good to know. Thanks Nicolas. But, it's not only the matter of fonts, rather language support which includes - fonts, input method (and maps), spell checker, openoffice langpack, kde langpack and language packs for various other applications. So, how are we going to solve those things? -- Regards, Ankit Patel http://www.indianoss.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
Nicu Buculei wrote: > > I prefixed it with "for me", i know it works for some people. > > You might try compiling SANE 1.0.20. There were tons of changes in-between 1.0.19 and 1.0.20. I don't see a F11 or F12 build for 1.0.20 in koji... you might want to file a bug on it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On 06/05/2009 05:11 PM, Matthew Garrett wrote: On Fri, Jun 05, 2009 at 05:01:58PM +0300, Nicu Buculei wrote: On 06/05/2009 04:47 PM, Matthew Garrett wrote: If a program crashes, there's a bug in that program. There may also be a bug in whatever's triggering the crash, but that's a separate issue. So I should fill a but for both Xsane, GnomeScan and X.org? Against X.org first. Finding out why it's crashing would give insight into where the root cause is. OK FWIW I've had no trouble using xsane in F11. Different hardware, different sane backends. Almost certainly. But it's a far cry from "Scanning is broken in Fedora". I prefixed it with "for me", i know it works for some people. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ photography: http://photoblog.nicubunu.ro/ my Fedora stuff: http://fedora.nicubunu.ro/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some pulseaudio questions...
On Fri, 05.06.09 09:01, Tom spot Callaway (tcall...@redhat.com) wrote: > > On 06/05/2009 06:57 AM, Lennart Poettering wrote: > > Usually running "pulseaudio -v" in a terminal might give you a > > hint what might be going wrong. > > Lennart, > > Maybe this is a stupid question (you know I am constantly full of them), > but is there any way for pulseaudio to detect this "common" condition > where the audio is skipping and inform the user of the possible > workarounds (maybe a DBUS popup or something directly to syslog). I'm > just considering that the average user might not make the leap to > running "pulseaudio -v" in a terminal to figuring this out. We are already doing this. We verify all timing related data we get from the driver as far as possible. i.e. everything returned by snd_pcm_delay() and snd_pcm_avail() is checked whether it is in specific bounds. If it is not we log that to syslog and clamp it to something which makes more sense to us. But of couse, there's only so much you can catch and even less than you can fix by clamping with that. In fact this turned out to be very useful to track down a couple of timing overflows in the HDA driver that have now been fixed in the F11 kernel. However there are still some issues left. Just search for "snd_pcm_delay"/"snd_pcm_avail"/"snd_pcm_update_avail" in bugzilla. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Friday 05 June 2009 08:56:47 Tom "spot" Callaway wrote: > On 06/05/2009 06:23 AM, Bastien Nocera wrote: > > Heya, > > > > Yesterday, I was browsing Ubuntu's "Blueprints" for their next release, > > and saw this: > > https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnomescan > > > > gnome-scan is already packaged by Deji, but I gather that more > > integration work could be done to make setting up and using scanners > > easier in GNOME and Fedora in general. > > > > Any takers? > > > > I think a good start would be making a list of problems seen in setting > > up scanners (additional packages required, tweaks), and make sure that > > gnome-scan and the necessary plugins are installed in a default > > installation. > > Perhaps we could target some specific scanners on the first attempt? We > might be able to get some hardware donated to the effort. > > ~spot, who has several scanners of varying age and quality in a box nb: I have two scanners up here as well that can be utilized, they're actually dual firewire/usb scanners that krh got when working on the firewire stack (and I inherited when I was working on it). Of course, last I knew, they both worked just fine using the gimp sane plugin, so they may not be all that interesting. (One is an Epson somethingorother, one is a Microtek, both are reasonably nice scanners) -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, Jun 5, 2009 at 6:23 AM, Bastien Nocera wrote: > Heya, > > Yesterday, I was browsing Ubuntu's "Blueprints" for their next release, > and saw this: > https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnomescan > > gnome-scan is already packaged by Deji, but I gather that more > integration work could be done to make setting up and using scanners > easier in GNOME and Fedora in general. > > Any takers? > > I think a good start would be making a list of problems seen in setting > up scanners (additional packages required, tweaks), and make sure that > gnome-scan and the necessary plugins are installed in a default > installation. > > Cheers > > /Bastien, who doesn't own a scanner > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I'd be very interested in helping with this, scanning is one of the most abhorrently performing niches in Linux that I've dealt with recently. $dayjob essentially grants me access to a plethora of high-end Fujitsu, Kodak, Bell & Howe, and Xerox scanners. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: GDM Language list...
Le Ven 5 juin 2009 15:06, Ankitkumar Rameshchandra Patel a écrit : > applications like gedit, nautilus showing square boxes instead of > Hindi text. Actually, in F11 they'll show a nice popup suggesting to look for and autoinstall hindi fonts. So this part is already fixed (maybe not in all apps but in pango-based apps at least) -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, Jun 05, 2009 at 05:01:58PM +0300, Nicu Buculei wrote: > On 06/05/2009 04:47 PM, Matthew Garrett wrote: >> If a program crashes, there's a bug in that program. There may also be a >> bug in whatever's triggering the crash, but that's a separate issue. > > So I should fill a but for both Xsane, GnomeScan and X.org? Against X.org first. Finding out why it's crashing would give insight into where the root cause is. >> FWIW I've had no trouble using xsane in F11. > > Different hardware, different sane backends. Almost certainly. But it's a far cry from "Scanning is broken in Fedora". -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On 06/05/2009 04:47 PM, Matthew Garrett wrote: On Fri, Jun 05, 2009 at 04:32:12PM +0300, Nicu Buculei wrote: On 06/05/2009 04:14 PM, Matthias Clasen wrote: X crashing does not sound like something related to scanning in particular; but it is certainly a bug worth filing, especially if it is easily reproducible. I was not sure on which component should it be reported to, X, sane-backends/fronteds, gnomescan, xsane. If a program crashes, there's a bug in that program. There may also be a bug in whatever's triggering the crash, but that's a separate issue. So I should fill a but for both Xsane, GnomeScan and X.org? FWIW I've had no trouble using xsane in F11. Different hardware, different sane backends. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ photography: http://photoblog.nicubunu.ro/ my Fedora stuff: http://fedora.nicubunu.ro/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, Jun 05, 2009 at 08:56:47AM -0400, Tom spot Callaway wrote: > On 06/05/2009 06:23 AM, Bastien Nocera wrote: > > Heya, > > > > Yesterday, I was browsing Ubuntu's "Blueprints" for their next release, > > and saw this: > > https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnomescan > > > > gnome-scan is already packaged by Deji, but I gather that more > > integration work could be done to make setting up and using scanners > > easier in GNOME and Fedora in general. > > > > Any takers? > > > > I think a good start would be making a list of problems seen in setting > > up scanners (additional packages required, tweaks), and make sure that > > gnome-scan and the necessary plugins are installed in a default > > installation. > > Perhaps we could target some specific scanners on the first attempt? We > might be able to get some hardware donated to the effort. I'm willing to help with testing. I have a Epson 4490, and Nikon Coolscan V slide scanner. The latter has been a trainwreck with sane for a long time, but I'm told its finally possible to use it. So if we have a nice GUI front end for scanning, i'll help out with testing. Daniel, who has 'vuescan' as the only closed source software on his Fedora machine for which no practical open source replacement yet exists. -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, Jun 05, 2009 at 04:32:12PM +0300, Nicu Buculei wrote: > On 06/05/2009 04:14 PM, Matthias Clasen wrote: >> X crashing does not sound like something related to scanning in >> particular; but it is certainly a bug worth filing, especially if it is >> easily reproducible. > > I was not sure on which component should it be reported to, X, > sane-backends/fronteds, gnomescan, xsane. If a program crashes, there's a bug in that program. There may also be a bug in whatever's triggering the crash, but that's a separate issue. FWIW I've had no trouble using xsane in F11. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Rawhide moving on to Fedora 12 content
2009/6/5 Jesse Keating : > I've made the switch tonight so that rawhide will be Fedora 12 content. > This will cause a huge number of updates, if the compose actually > finishes, and will finish quite late. > > For the next few days, attempts to use mirror manager for the Fedora 11 > repo will fail. This is something we hope to fix at the Fedora Activity > Day next week. Couldn't this have waited until F11 was out? Else the people that are testing F11-preview will be out of luck with using yum to install or update. Or did I understand incorrectly the comment above? -- Martín Marqués select 'martin.marques' || '@' || 'gmail.com' DBA, Programador, Administrador -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, 2009-06-05 at 14:04 +0300, Nicu Buculei wrote: > Now F11 is a new low: when pressing the scan or preview buttons from > either xsane-gimp or gnomescan the result is X crashing and me seeing > the GDM screen. X crashing does not sound like something related to scanning in particular; but it is certainly a bug worth filing, especially if it is easily reproducible. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On 06/05/2009 04:14 PM, Matthias Clasen wrote: On Fri, 2009-06-05 at 14:04 +0300, Nicu Buculei wrote: Now F11 is a new low: when pressing the scan or preview buttons from either xsane-gimp or gnomescan the result is X crashing and me seeing the GDM screen. X crashing does not sound like something related to scanning in particular; but it is certainly a bug worth filing, especially if it is easily reproducible. I was not sure on which component should it be reported to, X, sane-backends/fronteds, gnomescan, xsane. It crashes every time when I am trying to scan with a GUI, the only way to do somehing without a crash is using scanimage from commandline, which is aborting with "scanimage: received signal 15". -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ photography: http://photoblog.nicubunu.ro/ my Fedora stuff: http://fedora.nicubunu.ro/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On Fri, Jun 05, 2009 at 08:56:47AM -0400, Tom spot Callaway wrote: > On 06/05/2009 06:23 AM, Bastien Nocera wrote: > > Heya, > > > > Yesterday, I was browsing Ubuntu's "Blueprints" for their next release, > > and saw this: > > https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnomescan > > > > gnome-scan is already packaged by Deji, but I gather that more > > integration work could be done to make setting up and using scanners > > easier in GNOME and Fedora in general. > > > > Any takers? > > > > I think a good start would be making a list of problems seen in setting > > up scanners (additional packages required, tweaks), and make sure that > > gnome-scan and the necessary plugins are installed in a default > > installation. > > Perhaps we could target some specific scanners on the first attempt? We > might be able to get some hardware donated to the effort. > > ~spot, who has several scanners of varying age and quality in a box Same here. Paul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
GDM Language list...
Hi, A non-technical Fedora desktop user chooses X language (say Hindi) while logging in assuming that he will get everything working in Hindi (e.g. technically fonts, input methods, rendering, localized applications like Firefox, Openoffice, evolution, thunderbird, etc working). After logging in, he realize that most of the things are not working. e.g. Openoffice is entirely in English, Inputting (in Hindi) is not working, applications like gedit, nautilus showing square boxes instead of Hindi text. After this experience, person would definitely ask a question, why there is an option to choose a language even if there is no support for that language enabled? So, to answer that question, 1. to all: Should we change the list of languages dynamically from GDM login screen to satisfy the end users' (local language users') needs? 2. to GDM maintainers: Is it possible to change the list of languages dynamically (based on the language-supports installed) on the GDM login screen? Thanks! -- Regards, Ankit Patel http://www.indianoss.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some pulseaudio questions...
On 06/05/2009 06:57 AM, Lennart Poettering wrote: > Usually running "pulseaudio -v" in a terminal might give you a > hint what might be going wrong. Lennart, Maybe this is a stupid question (you know I am constantly full of them), but is there any way for pulseaudio to detect this "common" condition where the audio is skipping and inform the user of the possible workarounds (maybe a DBUS popup or something directly to syslog). I'm just considering that the average user might not make the leap to running "pulseaudio -v" in a terminal to figuring this out. Just brainstorming, ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Static system level uid/gid's reservations in Fedora/RHEL - how to handle situation?
Bill McGonigle wrote: > On 04/28/2009 03:04 AM, Ondřej Vašík wrote: > > What's the best way to handle that situation? One possibility is to > > increase the threshold of system level id's (to 200? 300?) > > I guess I've been blissfully ignorant and always assumed that id's under > 500 were reserved for system use since Redhat systems have always > created the first user uid as 500. Other admins I've worked with have > been similarly misinformed, so you might get lucky here. id's under id 500 are system id's and first user id is 500. That's correct - those defaults are coming from /etc/login.defs. However - id's under 100 are handled differently in some cases (e.g. default umask in /etc/bashrc and /etc/cshrc). And those id's are assigned statically and reserved by uidgid file coming from setup package. Increasing threshold in setup could cause some conflicts, but it's probably easiest way. Greetings, Ondřej Vašík signature.asc Description: Toto je digitálně podepsaná část zprávy -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On 06/05/2009 06:23 AM, Bastien Nocera wrote: > Heya, > > Yesterday, I was browsing Ubuntu's "Blueprints" for their next release, > and saw this: > https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnomescan > > gnome-scan is already packaged by Deji, but I gather that more > integration work could be done to make setting up and using scanners > easier in GNOME and Fedora in general. > > Any takers? > > I think a good start would be making a list of problems seen in setting > up scanners (additional packages required, tweaks), and make sure that > gnome-scan and the necessary plugins are installed in a default > installation. Perhaps we could target some specific scanners on the first attempt? We might be able to get some hardware donated to the effort. ~spot, who has several scanners of varying age and quality in a box -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: package review questions
On 06/05/2009 02:30 AM, Jan Klepek wrote: > Hi, > > I'm working on unofficial package review for redmine > ( https://bugzilla.redhat.com/show_bug.cgi?id=499959 ). > Redmine is written in ruby and is using rubygem-actionwebservice, which > is shipped with redmine. > Rubygem-actionwebservice was abandoned by upstream like two years ago, > and same happened for fedora package. My question is if redmine package > should install it on system or it should be considered as blocker, until > upstream of redmine migrate to activeresource. If the redmine package needs it, I'd say the redmine maintainer needs to revive the Fedora package. Alternately, they could wait to add redmine to Fedora until it uses activeresource. > Second question is when redmine contains plugins which are separate > applications/libraries (coderay is used by redmine for example) this > applications/libraries should be shipped within this package or should > be shipped in it's own package (and package should be created when it > doesn't exists)? My thoughts are that it should be shipped separately, > so it could be used by more applications. I'd agree with that assessment. ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Static system level uid/gid's reservations in Fedora/RHEL - how to handle situation?
Bill McGonigle writes: > I guess I've been blissfully ignorant and always assumed that id's > under 500 were reserved for system use since Redhat systems have > always created the first user uid as 500. I think it was 100 with early RHL. I'm sure I had to renumerate UIDs, most probably between RHL versions Or was that Slackware->RHL? Unlikely but possible. -- Krzysztof Halasa -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
Bastien Nocera wrote: Heya, Yesterday, I was browsing Ubuntu's "Blueprints" for their next release, and saw this: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnomescan gnome-scan is already packaged by Deji, but I gather that more integration work could be done to make setting up and using scanners easier in GNOME and Fedora in general. Any takers? Am Interested I think a good start would be making a list of problems seen in setting up scanners (additional packages required, tweaks), and make sure that gnome-scan and the necessary plugins are installed in a default installation. Not sure if have the necessary skills yet. If I got some mentoring, would be up for it. Cheers /Bastien, who doesn't own a scanner Brand X Scanner (PCline?) FRank -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Interested in scanning?
On 06/05/2009 01:23 PM, Bastien Nocera wrote: I think a good start would be making a list of problems seen in setting up scanners (additional packages required, tweaks), and make sure that gnome-scan and the necessary plugins are installed in a default installation. My experience with scanning in Fedora is so awful that I dropped any expectation: I have an old HP ScanJet 5370C, for which according with sane-project.org the support is "Good" (avision backend). For me the best was around F9, when it worked 50% of the time: a scan operation produced garbage, the next one was usable, the next one garbage and so on. I always had to scan twice to get something acceptable. F8 and earlier it produced garbage most of the time and in F10 the application just got frozen, doing nothing and I had to kill it. Now F11 is a new low: when pressing the scan or preview buttons from either xsane-gimp or gnomescan the result is X crashing and me seeing the GDM screen. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ photography: http://photoblog.nicubunu.ro/ my Fedora stuff: http://fedora.nicubunu.ro/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Some pulseaudio questions...
On Fri, 05.06.09 00:21, Jon Masters (jonat...@jonmasters.org) wrote: > Folks, > > Anyone want to clarify my understanding of PA's use of > mlock/posix_madvise? From looking over the code - in particular > pa_will_need, and its callsites - it looks like PA doesn't really use > this support that it has for locking pages. Which seems weird. mlock() is not actually used anymore by PA on modern kernels. The longer story goes like this: Text book RT applications use mlock()/mlockall() to lock themselves into memory and make sure they never are swapped out. This is something we cannot really do for PA given that map a *lot* of stuff into our address space: libraries, SHM segments for communications with other clients, cached samples, and so on. If we'd lock all that into memory there wouldn't be any memory left for much else, i.e. all other programs would have to share what is remaining and would have to swap all the time. Given that PA is just an auxiliary tool and not the main reason people run computers this is hence not an option. Due to that PA doesn't use mlock()/mlockall() like textbooks suggest, and it never did. Now, just ignoring the whole locking issue is also not an option. So I tried to find a compromise: try my best to make sure that the data accessed by the RT threads is available in memory but ignore the rest of the memory. To achieve that I needed a way to safely swap in memory when *I* need it to instead of letting the kernel to do as it as late as possible. Then, whenever the non-RT threads in PA pass off data to the RT threads I first swap the data in explicitly. That way I hope that the RT threads never need to wait for swapping in and can continue to loop in their little loops and continue to do whatever else they might want to do, but not wait for disks spinning. There is a system call for requesting swapping in of memory: posix_madvise(POSIX_MADV_WILLNEED). A few kernel releases ago this didn't work for anonymous memory, only for file-backed memory. (But on my request this was then changed in the kernel). Now, to support older kernels I added a dirty dirty hack: I try to lock those pages into memory and then unlock them right away, which should have about the same effect as the madvise() call. On current kernels that mlock() is never tried however, because WILLNEEED works fine anyway. And it's a horrible hack. And I probably should remove this from PA now. > I'll admit I'm about ready to hack in some horrible mlockall hacks to > see if that'll stop the poppy/skippyness on this box. I doubt that locking PA into memory will fix your issues. If PA drops out often this might have various reasons, but probably not swapping. Often the timing calls of your sound driver are inaccurate and cause PA to miss its deadlines. To work around that you could try disabling timer-based scheduling mode and revert to sound card IRQ scheduled playback. For that try passing "tsched=0" to module-hal-detect in /etc/pulse/default.pa. Then restart PA. Another issue might be that PA does not actually get scheduled often enough by the kernel. Might be caused by a bad driver (nvidia closed source). You can run PA as RT if you wish (which we hopfully will be able to enable by default in F12). For that increase RLIMIT_RTPRIO to 10 or so in /etc/security/limits.conf and login again. Usually running "pulseaudio -v" in a terminal might give you a hint what might be going wrong. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Interested in scanning?
Heya, Yesterday, I was browsing Ubuntu's "Blueprints" for their next release, and saw this: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-karmic-gnomescan gnome-scan is already packaged by Deji, but I gather that more integration work could be done to make setting up and using scanners easier in GNOME and Fedora in general. Any takers? I think a good start would be making a list of problems seen in setting up scanners (additional packages required, tweaks), and make sure that gnome-scan and the necessary plugins are installed in a default installation. Cheers /Bastien, who doesn't own a scanner -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the end of life for flash player (HTML5)
On Viernes 05 Junio 2009 10:47:06 Matej Cepl escribió: > Christof Damian, Fri, 05 Jun 2009 09:55:08 +0200: > > youtube is testing html5 too: http://www.youtube.com/html5 > > Except they don't use OGG, but MPEG4, so Firefox is not able to handle it > (midori, epiphany/WebKit are). In Arora I can hear only audio... So it's not OK - OGG has to be THE MUST - basic codec supported on all platforms/browsers. I'm not against proprietary codecs (I don't want to use them). Jaroslav > Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the end of life for flash player (HTML5)
Christof Damian, Fri, 05 Jun 2009 09:55:08 +0200: > youtube is testing html5 too: http://www.youtube.com/html5 Except they don't use OGG, but MPEG4, so Firefox is not able to handle it (midori, epiphany/WebKit are). Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Jueves 04 Junio 2009 20:23:01 Adam Williamson escribió: > On Thu, 2009-06-04 at 17:27 +0100, Paul Howarth wrote: > > I'll happily raise upstream bugs myself but it irks me when maintainers > > close Fedora bugs with the UPSTREAM resolution without actually taking > > the upstream fix and bringing it into Fedora. > > > > If I've reported a bug in Fedora bugzilla it's because the bug is > > present in Fedora and I'd like to see it fixed *in Fedora*. So seeing a > > bug closed UPSTREAM doesn't help at all if I have a real problem with a > > Fedora package. > > In Mandriva I had it set up so Bugzilla has both an UPSTREAM > *resolution* and an UPSTREAM *keyword*. This handles this situation. > > If, say, the bug is in a package that gets frequent releases, and was > filed on the development release, you can just use CLOSED UPSTREAM, > because you can rely on the fact that there'll be a new upstream release > of the package soon after the upstream report is fixed, you (the > maintainer) will then naturally package the new release, and the fix for > the bug will have been rolled into the distribution package without you > having to do anything besides your normal packaging work. > > In other situations, you can set the UPSTREAM keyword, so the bug > remains open but you know it's being handled upstream and you need to > bring the fix downstream once it's available upstream. I like idea of some TRACKING_UPSTREAM keyword - it's easy to search and CLOSED bugs are not as easy to search for duplicates when you are reporting bug. Jaroslav > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org > http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
