Need a wall paper for Fedora Security Spin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, I just added a request for a Wall paper for Fedora Security spin, Just wanted to drop a line to you guys to let you know. Thanks a lot. - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) Research and Development Lead, Global Help Desk, Pune Phone: +91 20 4005 7322 (UTC +5.5) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 Visit the Help Desk portal at : http://helpdesk.corp.redhat.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFIxhOdzHDc8tpb2uURAslFAKCZ/4R7IyUKM0aaUB9KdnUUuDU4WACdEZzZ KGf53I8JAKQ4JuLm+Qv4OCQ= =ObEI -END PGP SIGNATURE- ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Fedora Art at FUDCon
As I can't take photos of myself, here is an excellent photo taken by Francesco Crippa with Martin and me at FUDCon: http://www.flickr.com/photos/fcrippa/2841971331/ And a couple of photos by me with Martin talking about our projects: http://www.flickr.com/photos/nicubunu/2834913723/ http://www.flickr.com/photos/nicubunu/2835751382/ Not last, a proof that Martin worked on Echo at the conference: http://www.flickr.com/photos/nicubunu/2835749746/ (I also have proof of him drinking *, but I will not shame him right now :p ) My recommendation is: if you have the opportunity to meet another member(s) of the team, do not hesitate and use it. It was really good time. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Re: Fedora Art at FUDCon
On Tue, 2008-09-09 at 15:41 +0300, Nicu Buculei wrote: http://www.flickr.com/photos/fcrippa/2841971331/ http://www.flickr.com/photos/nicubunu/2834913723/ http://www.flickr.com/photos/nicubunu/2835751382/ My recommendation is: if you have the opportunity to meet another member(s) of the team, do not hesitate and use it. It was really good time. I feel old...ish Frank ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Solar Round 3 - Almost ended
Hi all I've almost done all the requirement for Solar Theme, leftin' me only the no-wide Wallpaper. If someone checks other materials leftin me, please, let me know. U can find all here. https://fedoraproject.org/wiki/Artwork/F10Themes/Solar As usual let me know ur guest. Thanks Samuele -- Samuele Storari Art Director Byte-Code srl mobile: +39 347 50 798 32 office: +39 02 9840047 http://www.byte-code.com ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Criteria for theme selection
Hi, Since our deadline to choose a theme is Sep 21 I would like to make sure before that point the criteria for selection are clear. Our base requirements is that the theme must have all required artwork needed for round 3. We have not yet had a case where more than one theme met this basic requirement. In case we do have multiple themes that meet this requirement, we need a fair method to choose which theme is selected as the default. Some ideas: - I believe Nicu suggested at one point that the number of people involved in creating the theme should be a selection factor, as the art team is a community effort. - I think perhaps setting up a vote could also be useful. The vote could be restricted to currently-active art team contributors and/or it could be opened to the whole set of Fedora accounts. - We could let FESCO decide. My suggestion is that we have a vote within the set of active Fedora art team contributors. The problem is how do we determine who is allowed in this vote - who is active? We could do: - anyone who contributed a theme idea or artwork throughout the 3 round process - anyone who has contributed a design to the art team (via the design queue, echo theme, or art theme process) in the past 6 months (the fedora 9 release period) - anyone who is in the art group in the account system (i don't think we have cleaned this out yet though and there are a few inactive accounts still I think) What do you all think? ~m ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Solar Critique (was Re: Solar Round 3 - Almost ended)
Some feedback on solar thus far: Samuele Storari wrote: Hi all I've almost done all the requirement for Solar Theme, leftin' me only the no-wide Wallpaper. If someone checks other materials leftin me, please, let me know. U can find all here. https://fedoraproject.org/wiki/Artwork/F10Themes/Solar - Where did the icons in the firstboot splash come from? We should be using gnome-icon-theme or Echo icons ideally. However it's not clear to me where this icons came from; we can't be using artwork from elsewhere without making sure the license allows it and is appropriate for Fedora. - the syslinux splash design doesn't seem to feed the feel/mood of the rest of the artwork. I think we could make it more photo realistic even with the color restrictions. - the background of the login window is too busy/distracting. Probably just a nice dark gradient would look nice although I don't even know if this kind of theming is possible with the new gdm. - the design for GRUB is missing. Thanks, ~m ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Re: Solar Critique (was Re: Solar Round 3 - Almost ended)
On Tue, 2008-09-09 at 10:30 -0400, Máirín Duffy wrote: Some feedback on solar thus far: - Where did the icons in the firstboot splash come from? We should be using gnome-icon-theme or Echo icons ideally. However it's not clear to me where this icons came from; we can't be using artwork from elsewhere without making sure the license allows it and is appropriate for Fedora. I'd guess these are oxygen icons by the look, which should be fine - we use them as default in KDE and they have good license. - the syslinux splash design doesn't seem to feed the feel/mood of the rest of the artwork. I think we could make it more photo realistic even with the color restrictions. - the background of the login window is too busy/distracting. Probably just a nice dark gradient would look nice although I don't even know if this kind of theming is possible with the new gdm. I totally agree with those two, but AFAIK, syslinux does not have the colour restriction GRUB has. The theme is probably for KDM which still allows it and is IIRC on the KDE Spin ;-) - the design for GRUB is missing. I think we could reuse the the syslinux one, only with 16 colours (or how much it supports). Personally I think the problem both with syslinux and login window theme are the dots on background - they are too strong/too contrastive and does not really fit well with the rest of the theme. The simplified sun is also questionable, I think it works nice in the firstboot screen, but nowhere else. BTW. I liked the syslinux image from Round 2 (I think it's listed as Anaconda Prompt Screen). I think it would work (after some simplification) for the colour-limited GRUB as well. Martin ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
R: Re: Solar Round 3 - Almost ended
Hi Mairin, The aurora U see was for all created by me, in no complex mode, as u can see in the source file so u don't have to recreate it cos as I done all by myself it's totally open. I used the Cloud effect http://www.gimpguru.org/Tutorials/SimulatedFog/ but I color the cloud, and then I distort the cloud, apply the Screen Mode Blending layer Effect and that's all, i don't think we need any license. For the planet as u can see it's all maded by different layer and there aren't part of not open material. So don't worry, my works it's made right for their purpose, totally free and open source. :D Ciao Samuele - Messaggio originale - Da: Máirín Duffy [EMAIL PROTECTED] A: Discussions about the artwork included with Fedora, including icons, themes, and wallpapers. fedora-art-list@redhat.com Inviato: Martedì, 9 settembre 2008 16:26:47 GMT +01:00 Amsterdam/Berlino/Berna/Roma/Stoccolma/Vienna Oggetto: Re: Solar Round 3 - Almost ended Hi Samuele, Samuele Storari wrote: Hi all I've almost done all the requirement for Solar Theme, leftin' me only the no-wide Wallpaper. If someone checks other materials leftin me, please, let me know. U can find all here. https://fedoraproject.org/wiki/Artwork/F10Themes/Solar I apologize if you provided this earlier but I didn't see it - I was wondering if you could provide us the source/attribution info for: - the moon/planet image - the aurora image That are used in the solar wallpaper artwork. I would just like to ascertain that the licensing on them is acceptable so if not we have time to replace them with sufficiently-licensed work. I know the moon image should be easy to replace with a public-domain NASA image. The auroras I'm not sure - I tried to recreate them in gimp without much success. I would really appreciate if you could let us know the licenses/sources for the above. Thanks, ~m ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list -- Samuele Storari Art Director Byte-Code srl mobile: +39 347 50 798 32 office: +39 02 9840047 http://www.byte-code.com ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
R: Criteria for theme selection
Well I think the vote will be totally open to the whole community. Why I think that? Cos the graphic it's made for all, think about art, think about expression, it comes from the inside need of someone to express to other, to comunicate. I hope we don't think to elevate us over the other people, we aren't the keeper of a sort of graphical wisdom, we create for the community, we work for all them and I think will be the right thing let the community decide. Don't forget in first the community have to use what we create, and we have to hear to the voice of the majority. So this is my opinion. Free Art - Free World. :D Ciao Samuele - Messaggio originale - Da: Máirín Duffy [EMAIL PROTECTED] A: Discussions about the artwork included with Fedora, including icons, themes, and wallpapers. fedora-art-list@redhat.com Inviato: Martedì, 9 settembre 2008 16:36:04 GMT +01:00 Amsterdam/Berlino/Berna/Roma/Stoccolma/Vienna Oggetto: Criteria for theme selection Hi, Since our deadline to choose a theme is Sep 21 I would like to make sure before that point the criteria for selection are clear. Our base requirements is that the theme must have all required artwork needed for round 3. We have not yet had a case where more than one theme met this basic requirement. In case we do have multiple themes that meet this requirement, we need a fair method to choose which theme is selected as the default. Some ideas: - I believe Nicu suggested at one point that the number of people involved in creating the theme should be a selection factor, as the art team is a community effort. - I think perhaps setting up a vote could also be useful. The vote could be restricted to currently-active art team contributors and/or it could be opened to the whole set of Fedora accounts. - We could let FESCO decide. My suggestion is that we have a vote within the set of active Fedora art team contributors. The problem is how do we determine who is allowed in this vote - who is active? We could do: - anyone who contributed a theme idea or artwork throughout the 3 round process - anyone who has contributed a design to the art team (via the design queue, echo theme, or art theme process) in the past 6 months (the fedora 9 release period) - anyone who is in the art group in the account system (i don't think we have cleaned this out yet though and there are a few inactive accounts still I think) What do you all think? ~m ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list -- Samuele Storari Art Director Byte-Code srl mobile: +39 347 50 798 32 office: +39 02 9840047 http://www.byte-code.com ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Re: Solar Critique (was Re: Solar Round 3 - Almost ended)
Martin Sourada wrote: On Tue, 2008-09-09 at 10:30 -0400, Máirín Duffy wrote: Some feedback on solar thus far: - Where did the icons in the firstboot splash come from? We should be using gnome-icon-theme or Echo icons ideally. However it's not clear to me where this icons came from; we can't be using artwork from elsewhere without making sure the license allows it and is appropriate for Fedora. I'd guess these are oxygen icons by the look, which should be fine - we use them as default in KDE and they have good license. But it would make a lot more sense to use Echo or Mist icons, something the majority of our users will really see after the install ends. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Re: Criteria for theme selection
Máirín Duffy wrote: We could do: - anyone who contributed a theme idea or artwork throughout the 3 round process - anyone who has contributed a design to the art team (via the design queue, echo theme, or art theme process) in the past 6 months (the fedora 9 release period) - anyone who is in the art group in the account system (i don't think we have cleaned this out yet though and there are a few inactive accounts still I think) The membership queue is not in a bad shape, its main problem is people who did the tasks needed for membership and then went silent. I think we should be realistic and avoid excessive bureaucracy: I won't, and I believe you won't either, compile by hand a huge list of all the people who contributed on the wiki, mailing list, git, cvs, etc. for half of a year and compare it with a list of votes (and I don't think we can automate this). -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Re: R: Re: Solar Round 3 - Almost ended
Samuele Storari wrote: Hi Mairin, The aurora U see was for all created by me, in no complex mode, as u can see in the source file so u don't have to recreate it cos as I done all by myself it's totally open. I used the Cloud effect http://www.gimpguru.org/Tutorials/SimulatedFog/ but I color the cloud, and then I distort the cloud, apply the Screen Mode Blending layer Effect and that's all, i don't think we need any license. For the planet as u can see it's all maded by different layer and there aren't part of not open material. So don't worry, my works it's made right for their purpose, totally free and open source. At least in the round 2 graphic, which i cracked open and played around with extensively, there was indeed an image of a moon in one of the layers. Where did that image come from? ~m ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Re: R: Criteria for theme selection
+1 2008/9/10 Samuele Storari [EMAIL PROTECTED] Well I think the vote will be totally open to the whole community. Why I think that? Cos the graphic it's made for all, think about art, think about expression, it comes from the inside need of someone to express to other, to comunicate. I hope we don't think to elevate us over the other people, we aren't the keeper of a sort of graphical wisdom, we create for the community, we work for all them and I think will be the right thing let the community decide. Don't forget in first the community have to use what we create, and we have to hear to the voice of the majority. So this is my opinion. Free Art - Free World. :D Ciao Samuele - Messaggio originale - Da: Máirín Duffy [EMAIL PROTECTED] A: Discussions about the artwork included with Fedora, including icons, themes, and wallpapers. fedora-art-list@redhat.com Inviato: Martedì, 9 settembre 2008 16:36:04 GMT +01:00 Amsterdam/Berlino/Berna/Roma/Stoccolma/Vienna Oggetto: Criteria for theme selection Hi, Since our deadline to choose a theme is Sep 21 I would like to make sure before that point the criteria for selection are clear. Our base requirements is that the theme must have all required artwork needed for round 3. We have not yet had a case where more than one theme met this basic requirement. In case we do have multiple themes that meet this requirement, we need a fair method to choose which theme is selected as the default. Some ideas: - I believe Nicu suggested at one point that the number of people involved in creating the theme should be a selection factor, as the art team is a community effort. - I think perhaps setting up a vote could also be useful. The vote could be restricted to currently-active art team contributors and/or it could be opened to the whole set of Fedora accounts. - We could let FESCO decide. My suggestion is that we have a vote within the set of active Fedora art team contributors. The problem is how do we determine who is allowed in this vote - who is active? We could do: - anyone who contributed a theme idea or artwork throughout the 3 round process - anyone who has contributed a design to the art team (via the design queue, echo theme, or art theme process) in the past 6 months (the fedora 9 release period) - anyone who is in the art group in the account system (i don't think we have cleaned this out yet though and there are a few inactive accounts still I think) What do you all think? ~m ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list -- Samuele Storari Art Director Byte-Code srl mobile: +39 347 50 798 32 office: +39 02 9840047 http://www.byte-code.com ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list -- tatica Maria Gracia Leandro http://www.tatica.org http://www.iseit.net http://www.latinux.org http://www.latinux.com http://www.fedora-ve.org http://fedoraproject.org/wiki/MariaLeandro LinuxUser= 440285 GPG Public Key: E1CDCC56 Be yourself... Don't be anyone else ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Re: Solar Critique (was Re: Solar Round 3 - Almost ended)
On Tue, Sep 9, 2008 at 5:30 PM, Máirín Duffy [EMAIL PROTECTED] wrote: - the background of the login window is too busy/distracting. Probably just a nice dark gradient would look nice although I don't even know if this kind of theming is possible with the new gdm. Technically, it's possible to create such KDM theme, except userlist part. When i was crafting waves theme i couldn't find a way to make userlist widget background transparent, but probably it's fixed already, or maybe i could hack KDM source a little bit -- http://scwlab.com ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Re: Need a wall paper for Fedora Security Spin
Hi http://molaora.com/data/files/Temp/security_spin_001.jpg http://molaora.com/data/files/Temp/security_spin.jpg Mola --- Huzaifa Sidhpurwala wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, I just added a request for a Wall paper for Fedora Security spin, Just wanted to drop a line to you guys to let you know. Thanks a lot. - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) Research and Development Lead, Global Help Desk, Pune Phone: +91 20 4005 7322 (UTC +5.5) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 Visit the Help Desk portal at : http://helpdesk.corp.redhat.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFIxhOdzHDc8tpb2uURAslFAKCZ/4R7IyUKM0aaUB9KdnUUuDU4WACdEZzZ KGf53I8JAKQ4JuLm+Qv4OCQ= =ObEI -END PGP SIGNATURE- ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Re: R: Criteria for theme selection
at least 30% or 20% should be a community decision... right? 2008/9/10 Nicu Buculei [EMAIL PROTECTED] Samuele Storari wrote: Well I think the vote will be totally open to the whole community. Why I think that? Cos the graphic it's made for all, think about art, think about expression, it comes from the inside need of someone to express to other, to comunicate. I hope we don't think to elevate us over the other people, we aren't the keeper of a sort of graphical wisdom, we create for the community, we work for all them and I think will be the right thing let the community decide. The trouble is that the large community knows little about usability and good design. I said it before and I say it again: if we keep a popular vote, I bet I storm the results if I propose some softcore anime or a half-nude photo of Angelina Jolie. Don't forget in first the community have to use what we create, and we have to hear to the voice of the majority. We usually hear the voice of a loud minority. So this is my opinion. Free Art - Free World. :D And then let's make all our decisions (about defaults, application choices, packaging) based on popular vote. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list -- tatica Maria Gracia Leandro http://www.tatica.org http://www.iseit.net http://www.latinux.org http://www.latinux.com http://www.fedora-ve.org http://fedoraproject.org/wiki/MariaLeandro LinuxUser= 440285 GPG Public Key: E1CDCC56 Be yourself... Don't be anyone else ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
introduction
Hi, I am Amrita Mukherjee ,currently pursuing B-tech from Dr. B.C. Roy Engineering College. I am a member of DGPLUG group and presently doing some artwork with the help of inkscape. I would be highly delighted to be a member of this community and contribute some projects. Add more friends to your messenger and enjoy! Go to http://in.messenger.yahoo.com/invite/___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Re: R: Criteria for theme selection
2008/9/9 María Leandro [EMAIL PROTECTED]: at least 30% or 20% should be a community decision... right? Here's my view, as a Board member. I consider the multiple rounds of discussion over the themes as a prolonged community decision. The final artwork decision is a culminating event in a process. Are people encouraged to participate in the earlier stages of that process as part of the art team? if they choose not to participate in the previous rounds do they have the context to make informed decisions at the final stage? Have they earned the right to be a part of the final decision? I'm not sure they do. Everything that gets done in Fedora is done by a subset of a larger community. We don't make it a point to take a community wide poll when the technical bits need to be updated. We put the trust and authority to make decisions into the teams responsible for developing those bits. And I'm not sure we should treat the default art work any differently than we treat gdm or the installer..things which end up making use of the artwork... by opening up the decision making to a popularity contest. -jefThat being said... solar better end up being the theme cuz it makes an awesome tie in to the International Heliophysical Year which is happening nowspaleta ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Re: Solar Round 3 - Almost ended
Congratulations Samuel, our theme is more better then before round. Continuous our great work. -- Wolnei Cândido Tomazelli Junior (Charged) Brazil Fedora Ambassador Designer and TI E-mail : [EMAIL PROTECTED] Linux User #477062 ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Re: introduction
welcome. -- Wolnei Cândido Tomazelli Junior (Charged) Brazil Fedora Ambassador Designer and TI E-mail : [EMAIL PROTECTED] Linux User #477062 ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Re: Criteria for theme selection
On Tue, Sep 09, 2008 at 10:36:04AM -0400, =?ISO-8859-1?Q?M=E1ir=EDn_Duffy_ wrote: What do you all think? Flip a coin. (kidding) I don't doubt the existence of at least two of the three remaining themes, and so I'm glad we're talking about this *now* instead of at the last minute ;) I'm personally for a contributor-wide vote on it, using the FAS voting system (go talk to Nigel Jones), because we want to ask the widest audience possible, while still keeping the whole process sane and relatively organized. Or, perhaps even better, take a two-part voting approach; 50% of the vote allocated to current Art Team members (recent contributions, 6 months, yada yada) and 50% for the community. I have no freaking clue how the math for that would work, but I think it would help alleviate both concerns of 1) some of the general public not understanding usability (which I think is bunk, but whatever) and 2) not including the entire community in the process. To say it in the most crass way possible, it's the best solution to get community input, while still showing that we can override it if we really really really want to. It sounds horrible (or at least it does in my mind), but it's the fairest way, IMHO. And whatever it comes down to, it's still going to be really hard for me to choose votes, even if we use Range Voting. Gears is growing on me ;) /rant -- Ian Weller [EMAIL PROTECTED] http://ianweller.org GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 Technology is a word that describes something that doesn't work yet. ~ Douglas Adams pgp741J7UAict.pgp Description: PGP signature ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Re: R: Re: Solar Round 3 - Almost ended
Hi Samuele, On Tue, 2008-09-09 at 17:07 +0200, Samuele Storari wrote: For the planet as u can see it's all maded by different layer and there aren't part of not open material. So don't worry, my works it's made right for their purpose, totally free and open source. Just to be specific, it's this image I would like a link to the source work form: http://i61.photobucket.com/albums/h58/mairinduffy/solar_moon_image-layer2.png?t=1221015993 It's in layer 2 of the XCF. ~m ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Re: R: Criteria for theme selection
On Tue, 2008-09-09 at 13:20 -0400, Máirín Duffy wrote: María Leandro wrote: +1 2008/9/10 Samuele Storari [EMAIL PROTECTED] I think the vote will be totally open to the whole community. Well, I think with a little over a week to go on the final decision, we should maybe limit to art group members for this release, and plan a larger vote for F11. The reason I say this is because we don't really have time to plan for a Fedora-wide vote, and since there's not much time to wait on people to vote and to get the word out, we won't have a good representation of our base in the vote results. Does that seem fair? It seems like the right thing, too. I don't think a general vote on the default theme is a reasonable idea at all. Taste is not something that can be decided with simple majority. Voting for the default theme would pretty much devolve into 'which is the coolest looking background when glancing at a bunch of screenshots', which is not at all what a good default theme is about. This forum is the place for qualified and interested people to work on the art that makes up the default theme. It should also be the place where the default theme gets put together. If you want to gain more feedback on the drafts you work on, here is a proposal: next time, package up the remaining candidates in the final round (at that stage they should all be complete enough for that, I guess), and ship them with the beta, maybe with some nice paragraph in the beta release notes pointing at the available candidate themes. Matthias ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Re: introduction
amrita mukherjee a écrit : Hi, I am Amrita Mukherjee ,currently pursuing B-tech from Dr. B.C. Roy Engineering College. I am a member of DGPLUG group and presently doing some artwork with the help of inkscape. I would be highly delighted to be a member of this community and contribute some projects. Welcome to Fedora Artwork team, For the task , you can start working on design services[1]. Since you know how to use Inkscape you can help to contribute to the development of Echo icon theme [2] that also includes instruction to easily publish newly created icon set. Luya References: - [1] https://fedoraproject.org/wiki/Artwork/DesignService [2] https://fedorahosted.org/echo-icon-theme signature.asc Description: OpenPGP digital signature ___ Fedora-art-list mailing list Fedora-art-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-art-list
Re: Patch fixing a problem with --kickstart-include
Martin Langhoff wrote: By naming the kickstart file as ks.cfg, anaconda would _always_ take it, regardless of kernel boot options. This is not what was expected - it is safer to give it a different name, and then use the boot menu item to select it. So what you're saying is that anaconda picks up the kickstart file and runs away with it, even when it has not been told it should do so? It probably shouldn't do that... but I'll have to check with the anaconda guys to see if it's maybe an intended change. Kind regards, Jeroen van Meeuwen -kanarip -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Patch fixing a problem with --kickstart-include
On Tue, Sep 9, 2008 at 8:48 PM, Jeroen van Meeuwen [EMAIL PROTECTED] wrote: So what you're saying is that anaconda picks up the kickstart file and runs away with it, even when it has not been told it should do so? I am fairly sure that it does, though today I've tested ~20 different combination of builds and things, so there's a small chance I got it wrong. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Patch fixing a problem with --kickstart-include
Martin Langhoff wrote: On Tue, Sep 9, 2008 at 8:48 PM, Jeroen van Meeuwen [EMAIL PROTECTED] wrote: So what you're saying is that anaconda picks up the kickstart file and runs away with it, even when it has not been told it should do so? I am fairly sure that it does, though today I've tested ~20 different combination of builds and things, so there's a small chance I got it wrong. I know it wasn't doing this before, and I'm not sure it's supposed to now. I've not seen any changes related to kickstart loading other then for the kickstart located on an NFS share... but then again I may have subconsciously ignored the commit. I'll try and figure out how it's supposed to work and how it actually works. -Jeroen -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Patch fixing a problem with --kickstart-include
On Tue, Sep 9, 2008 at 10:55 PM, Jeroen van Meeuwen [EMAIL PROTECTED] wrote: I know it wasn't doing this before, and I'm not sure it's supposed to now. I've not seen any changes related to kickstart loading other then for the kickstart located on an NFS share... but then again I may have subconsciously ignored the commit. I'll try and figure out how it's supposed to work and how it actually works. When I crafted the patch I was reading the Anaconda/Kickstart wikipage, specifically the http://fedoraproject.org/wiki/Anaconda/Kickstart#Creating_a_Kickstart_Boot_CD-ROM section. Re-reading it now, I notice that you have to complement that with http://fedoraproject.org/wiki/Anaconda/Kickstart#Boot_CD-ROM - Hmmm. Unless a `git grep ks.cfg` of anaconda turns up a smoking gun, the patch I posted may be a misfire :-/ cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
finally... releasing an Education Spin
Ladies and Gentlemen, please start your engines... I'm happy to announce that we've another Education Spin ready for download! It's not official, though: We've got trademark approval, but please consider this only a preview for the upcoming F10 spins. The Fedora 10 Education Math Spin will follow Fedora's release cycle and will be officially endorsed by the Fedora Project. But if you want to give it a test drive, here you go! It currently includes only educational applications related to the field of mathematics, but I'd be glad to hear your suggestions and ideas on what we've done so far. Finally, I'd like to thank Rex for all his efforts, without which this wouldn't have been possible! So here's the link (currently torrent only): http://rdieter.fedorapeople.org/torrents/livecd-f9-education-math-i686-200809081518.torrent By the way: If you're interested in education, why don't you join our IRC channel? It's #fedora-edu on Freenode! --Sebastian ___ Fedora-education-list mailing list Fedora-education-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-education-list
rpms/lohit-fonts/devel .cvsignore, 1.8, 1.9 lohit-fonts.spec, 1.8, 1.9 sources, 1.8, 1.9
Author: rbhalera
Update of /cvs/pkgs/rpms/lohit-fonts/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv31721
Modified Files:
.cvsignore lohit-fonts.spec sources
Log Message:
New Upstream Version: lohit-fonts-2.3.1
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/lohit-fonts/devel/.cvsignore,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- .cvsignore 20 Aug 2008 10:37:09 - 1.8
+++ .cvsignore 9 Sep 2008 12:08:11 - 1.9
@@ -1 +1 @@
-lohit-fonts-2.3.0.tar.gz
+lohit-fonts-2.3.1.tar.gz
Index: lohit-fonts.spec
===
RCS file: /cvs/pkgs/rpms/lohit-fonts/devel/lohit-fonts.spec,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- lohit-fonts.spec20 Aug 2008 10:37:09 - 1.8
+++ lohit-fonts.spec9 Sep 2008 12:08:11 - 1.9
@@ -2,7 +2,7 @@
%define langlistbengali hindi gujarati tamil punjabi kannada
malayalam oriya telugu marathi maithili kashmiri konkani nepali sindhi
Name:lohit-fonts
-Version: 2.3.0
+Version: 2.3.1
Release: 1%{?dist}
Summary: Free Indian truetype/opentype fonts
@@ -86,7 +86,10 @@
%changelog
-* Wed Aug 20 2008 Rahul Bhalerao [EMAIL PROTECTED] - 2.3.0-1
+* Tue Sep 09 2008 Rahul Bhalerao [EMAIL PROTECTED] - 2.3.1-1
+- Bug 216400: [te_IN] anaconda GUI - Release Notes button overlaps with other
text
+
+* Wed Aug 20 2008 Rahul Bhalerao [EMAIL PROTECTED] - 2.3.0-1
- Forked Lohit Hindi into Marathi, Maithili, Kashmiri, Konkani, Sindhi and
Nepali.
- Bug 215902: [hi_IN, mr_IN]Incorrect extent of 0x093f when attached to a
composite character which has width greater than a single character (hi_IN
maybe others)
- Bug 445176: [ml_IN] Conjuncts combining with 0D30 do not form the pre based
glyph
Index: sources
===
RCS file: /cvs/pkgs/rpms/lohit-fonts/devel/sources,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- sources 20 Aug 2008 10:37:09 - 1.8
+++ sources 9 Sep 2008 12:08:11 - 1.9
@@ -1 +1 @@
-55d4e627e643ead3b44487b1347deaac lohit-fonts-2.3.0.tar.gz
+ca26218fc6323633210c674fe9e2f9d2 lohit-fonts-2.3.1.tar.gz
___
Fedora-fonts-bugs-list mailing list
Fedora-fonts-bugs-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Issue 79878] OO.o can not select modern font faces conveniently
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=79878 --- Additional comments from [EMAIL PROTECTED] Tue Sep 9 13:50:28 + 2008 --- -dtardon: Regarding your last patch (from Wed Sep 3 07:24:00 + 2008) I wouldn't separate the font styles into three ListBoxes as this enables to select combinations that are not supported by the font. It would be better to keep the single font style box that contains all the available combinations. Additionally, we need a volunteer to take care for the file format extension. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 461617] modified Sazanami-Gothic font showing vertical text rendering glitches not seen in the original
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=461617 Caolan McNamara [EMAIL PROTECTED] changed: What|Removed |Added External Bug ID||OpenOffice.org 92671 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 461617] modified Sazanami-Gothic font showing vertical text rendering glitches not seen in the original
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=461617 --- Comment #1 from Caolan McNamara [EMAIL PROTECTED] 2008-09-09 10:29:45 EDT --- Created an attachment (id=316192) -- (https://bugzilla.redhat.com/attachment.cgi?id=316192) screenshot with what we have in rawhide -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 455981] Missing locl romanian magic
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=455981 Tony Fu [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED]|[EMAIL PROTECTED] --- Comment #36 from Tony Fu [EMAIL PROTECTED] 2008-09-09 23:08:23 EDT --- requested by Jens Petersen (#27995) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 458951] [sd-IN] Sindhi language is not identified by fontconfig
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=458951 Tony Fu [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED]|[EMAIL PROTECTED] --- Comment #5 from Tony Fu [EMAIL PROTECTED] 2008-09-09 23:06:48 EDT --- requested by Jens Petersen (#27995) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 423191] [ml_IN] combination is INCorrect with 0d30 [consonant+0d4d+0d30]
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=423191 Tony Fu [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED]|[EMAIL PROTECTED] --- Comment #4 from Tony Fu [EMAIL PROTECTED] 2008-09-09 23:08:14 EDT --- requested by Jens Petersen (#27995) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 454232] xterm should require xorg-x11-fonts-misc
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=454232 Tony Fu [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED]|[EMAIL PROTECTED] --- Comment #6 from Tony Fu [EMAIL PROTECTED] 2008-09-09 23:09:37 EDT --- requested by Jens Petersen (#27995) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 455050] Review Request: padauk-fonts - Padauk font for Burmese and the Myanmar script
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=455050 Tony Fu [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED]|[EMAIL PROTECTED] --- Comment #11 from Tony Fu [EMAIL PROTECTED] 2008-09-09 23:07:09 EDT --- requested by Jens Petersen (#27995) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 445176] [ml_IN] Conjuncts combining with 0D30 do not form the pre based glyph
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=445176 Tony Fu [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED]|[EMAIL PROTECTED] --- Comment #2 from Tony Fu [EMAIL PROTECTED] 2008-09-09 23:10:18 EDT --- requested by Jens Petersen (#27995) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 461139] Review Request: arabeyes-core-fonts - Core Arabic fonts from Arabeyes.org
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=461139 Tony Fu [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED]|[EMAIL PROTECTED] --- Comment #6 from Tony Fu [EMAIL PROTECTED] 2008-09-09 23:07:37 EDT --- requested by Jens Petersen (#27995) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 230662] Faulty text-wrapping for Asian languages
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=230662 Tony Fu [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED]|[EMAIL PROTECTED] --- Comment #15 from Tony Fu [EMAIL PROTECTED] 2008-09-09 23:11:21 EDT --- requested by Jens Petersen (#27995) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 459451] Changes in glyph point settings window could not be applied.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=459451 Tony Fu [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED]|[EMAIL PROTECTED] --- Comment #8 from Tony Fu [EMAIL PROTECTED] 2008-09-09 23:12:46 EDT --- requested by Jens Petersen (#27995) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 458938] Lohit fonts need to support more languages based on Devanagari
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=458938 Tony Fu [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED]|[EMAIL PROTECTED] --- Comment #1 from Tony Fu [EMAIL PROTECTED] 2008-09-09 23:14:15 EDT --- requested by Jens Petersen (#27995) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 460090] Check all font files in liberation-fonts for hinting problems.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=460090 Tony Fu [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED]|[EMAIL PROTECTED] --- Comment #2 from Tony Fu [EMAIL PROTECTED] 2008-09-09 23:12:19 EDT --- requested by Jens Petersen (#27995) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 441213] [i18n] [zh_CN] different font used for ASCII
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=441213 Tony Fu [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED]|[EMAIL PROTECTED] --- Comment #20 from Tony Fu [EMAIL PROTECTED] 2008-09-09 23:14:50 EDT --- requested by Jens Petersen (#27995) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 428427] [kn_IN][fonts-indic] - 0CB5+0CCA is wrongly rendering
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=428427 Tony Fu [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED]|[EMAIL PROTECTED] --- Comment #5 from Tony Fu [EMAIL PROTECTED] 2008-09-09 23:18:03 EDT --- requested by Jens Petersen (#27995) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 402321] [ml_IN] Wrong combinations used for the conjunct ' ന്പ '
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=402321 Tony Fu [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED]|[EMAIL PROTECTED] --- Comment #10 from Tony Fu [EMAIL PROTECTED] 2008-09-09 23:16:31 EDT --- requested by Jens Petersen (#27995) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 402331] [ml_IN] Wrong combinations used for conjunct ' ന്റ '
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=402331 Tony Fu [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED]|[EMAIL PROTECTED] --- Comment #20 from Tony Fu [EMAIL PROTECTED] 2008-09-09 23:16:35 EDT --- requested by Jens Petersen (#27995) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 444559] [ml_IN] Wrong shape for conjuncts formed using 0D30 (xRa) in a word
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=444559 Tony Fu [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED]|[EMAIL PROTECTED] --- Comment #8 from Tony Fu [EMAIL PROTECTED] 2008-09-09 23:18:07 EDT --- requested by Jens Petersen (#27995) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 444563] [ml_IN] When 0D2F is combined with a consonant and followed by 0D15, 0D2F joins with 0D15
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=444563 Tony Fu [EMAIL PROTECTED] changed: What|Removed |Added CC|[EMAIL PROTECTED]|[EMAIL PROTECTED] --- Comment #7 from Tony Fu [EMAIL PROTECTED] 2008-09-09 23:18:11 EDT --- requested by Jens Petersen (#27995) -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Issue 88583] AutoCorrection changes Font
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=88583 User redflagzhulihua changed the following: What|Old value |New value Status|VERIFIED |CLOSED --- Additional comments from [EMAIL PROTECTED] Wed Sep 10 03:44:43 + 2008 --- Verified in OOo3.0 RC1 and closed - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[Bug 16792] [GTK] Fails to render Japanese/Chinese text with simple path
https://bugs.webkit.org/show_bug.cgi?id=16792 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #19 from [EMAIL PROTECTED] 2008-09-09 21:34 PDT --- Landed in r36309. -- Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ Fedora-fonts-bugs-list mailing list Fedora-fonts-bugs-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-bugs-list
[announcement] fedora-i18n-bugs list
A new bugs mailing-list fedora-i18n-bugs has been setup to track Fedora i18n related bugs in bugzilla. It will also be used for autocc'ing (initialcc) of i18n related Fedora packages. https://www.redhat.com/mailman/listinfo/fedora-i18n-bugs The list will be fairly high traffic but give people a way to track i18n issues also in the archives or in bugzilla. Thanks, Jens ___ Fedora-fonts-list mailing list Fedora-fonts-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-fonts-list
Re: Environments Doc
Mike McGrath wrote: Collab1 is a server focused around our collaboration tools. Right now it has some mailing lists and a sobby server. It will probably also have our pastebin in the future once it gets ready. Cool, definitely sounds like I need to ping you more online about this. Next thing I'm probably going to be looking at is shindig, might be useful. Gotta run to some meetings first though :/ --Bret ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Removal of old projects from fedorahosted.
Hi, This is w.r.t to ticket #714[1]. As explained by mmcgrath, Fedora has a policy to remove _any_ hosted projects that are not altered or updated for last six months. Here is the list of projects, which falls into this category and they will soon be removed. These directories have not been altered for 6 months /srv/svn/hardlinkgroup: svnhardlink /srv/svn/package-jitsu group: svnpackage-jitsu /srv/svn/repoviewgroup: svnrepoview /srv/svn/ols group: svnols /srv/svn/setarch group: svnsetarch /srv/svn/authd group: svnauthd /srv/svn/system-config-keyboard.old group: svnsystem-config-keyboard /srv/hg/camelus group: hgcamelus /srv/hg/passwd group: hgpasswd /srv/hg/bodhi.oldgroup: gitbodhi /srv/hg/guest-accountgroup: hgguest-account /srv/hg/timeconfig group: hgtimeconfig /srv/hg/LHCP group: hgLHCP /srv/hg/virt-manager group: hgvirt-manager /srv/hg/pam-redhat group: hgpam-redhat /srv/hg/tmpwatch group: hgtmpwatch /srv/git/splatbind.git group: gitsplatbind /srv/git/system-config-securitylevel.git group: gitsystem-config-securitylevel If you have any update with respect to this, and don't want any/some project(s) be removed, please let us know. Thanks. [1]https://fedorahosted.org/fedora-infrastructure/ticket/714 -- Regards, Susmit. = ssh 0x86DD170A http://www.fedoraproject.org/wiki/user:susmit = ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
Mike McGrath ([EMAIL PROTECTED]) said: [1]https://fedorahosted.org/fedora-infrastructure/ticket/714 So I guess the best thing from here is to send an email to each group notifying them of what has happened and why we'd like to remove their project. tell them how to get the code off if they still want it, etc, etc. Lots of people on this list use hosted projects, what do you think? I'm leery of having a hard and fast 6-month-rule; especially for projects which aren't translated, it's possible to have a decent period without code changes. Maybe review-at-six-months? Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, 2008-09-09 at 20:33 +0530, susmit shannigrahi wrote: As explained by mmcgrath, Fedora has a policy to remove _any_ hosted projects that are not altered or updated for last six months. Hmmm -- this seems a little problematic. It's definitely possible to have a mature project which doesn't see a lot of changes. Not that all of these necessarily fall into that case, but some of them definitely do Jeremy ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, 9 Sep 2008, Jeremy Katz wrote: On Tue, 2008-09-09 at 20:33 +0530, susmit shannigrahi wrote: As explained by mmcgrath, Fedora has a policy to remove _any_ hosted projects that are not altered or updated for last six months. Hmmm -- this seems a little problematic. It's definitely possible to have a mature project which doesn't see a lot of changes. Not that all of these necessarily fall into that case, but some of them definitely do It's not actually a hard and fast rule. The wording is: https://fedorahosted.org/web/terms The Fedora Project reserves the right to remove any project from our system that does not meet the following criteria: 1. Code contained in the project does not meet our license requirements 2. No significant changes have been committed or applied for at least six (6) months -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
As explained by mmcgrath, Fedora has a policy to remove _any_ hosted projects that are not altered or updated for last six months. I am pleasantly suprised to see that Opyum is not in that list. :-) The thing with Opyum is that its functionality has been very nicely ported to PackageKit by one of my friends during this year's Google Summer of Code. Fedora 8 still caries Opyum, but its useless for Fedora 9 and onwards. I just want to wait till Fedora 8 is EOLed after which I would not want it to hog resources on fedorahosted.org any more. Happy hacking, Debarshi ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, Sep 09, 2008 at 12:02:04PM -0400, Jeremy Katz wrote: On Tue, 2008-09-09 at 20:33 +0530, susmit shannigrahi wrote: As explained by mmcgrath, Fedora has a policy to remove _any_ hosted projects that are not altered or updated for last six months. Hmmm -- this seems a little problematic. It's definitely possible to have a mature project which doesn't see a lot of changes. Not that all of these necessarily fall into that case, but some of them definitely do yeah, like setarch. Isn't likely to change much... -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com www.dell.com/linux ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, Sep 09, 2008 at 10:20:25PM +0530, Debarshi Ray wrote: The thing with Opyum is that its functionality has been very nicely ported to PackageKit by one of my friends during this year's Google Summer of Code. Fedora 8 still caries Opyum, but its useless for Fedora 9 and onwards. I just want to wait till Fedora 8 is EOLed after which I would not want it to hog resources on fedorahosted.org any more. SourceForge.net (gah! I know) has a policy that not only prevents projects from being automatically removed simply for the sake of being idle, but that prevents most projects from being removed at all, even at the developer's request; this policy is for the contingency of source code, making it still available to people who still want it, even though the project may be dead. If there's no way to retrieve the source code for a project that has been removed from Fedora Hosted, is the project not gone forever -- and more importantly, do we want that? -- Ian Weller [EMAIL PROTECTED] http://ianweller.org GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 Technology is a word that describes something that doesn't work yet. ~ Douglas Adams pgp9TI1MZpHGT.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, 9 Sep 2008, Ian Weller wrote: On Tue, Sep 09, 2008 at 10:20:25PM +0530, Debarshi Ray wrote: The thing with Opyum is that its functionality has been very nicely ported to PackageKit by one of my friends during this year's Google Summer of Code. Fedora 8 still caries Opyum, but its useless for Fedora 9 and onwards. I just want to wait till Fedora 8 is EOLed after which I would not want it to hog resources on fedorahosted.org any more. SourceForge.net (gah! I know) has a policy that not only prevents projects from being automatically removed simply for the sake of being idle, but that prevents most projects from being removed at all, even at the developer's request; this policy is for the contingency of source code, making it still available to people who still want it, even though the project may be dead. This is one of the things we're hoping to prevent with fedorahosted. The hope is that the fedorahosted brand will be known for good, active projects. Not vaporware. If there's no way to retrieve the source code for a project that has been removed from Fedora Hosted, is the project not gone forever -- and more importantly, do we want that? Depends. We'll certainly be contacting the project members and let them know whats up giving them the option to grab the raw source tree (already available via rsync) and the trac install. In general from the infrastructure side I'd say we want to keep the barrier to enter low but the quality high. Certainly there's projects that don't need to be updated every 6 months but we can identify those and deal accordingly. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, Sep 09, 2008 at 03:35:41PM -0500, Mike McGrath wrote: This is one of the things we're hoping to prevent with fedorahosted. The hope is that the fedorahosted brand will be known for good, active projects. Not vaporware. We'll certainly be contacting the project members and let them know whats up giving them the option to grab the raw source tree (already available via rsync) and the trac install. In general from the infrastructure side I'd say we want to keep the barrier to enter low but the quality high. Certainly there's projects that don't need to be updated every 6 months but we can identify those and deal accordingly. None of this seems to agree with the open source philosophy. From what I understand, one should always be able to access code, whether dead, buggy, or release candidate, or whatever. I understand the idea of keeping a code center clean and newish, but I think it would turn away more projects than dead codebases would. -- Ian Weller [EMAIL PROTECTED] http://ianweller.org GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 Technology is a word that describes something that doesn't work yet. ~ Douglas Adams pgpiHuaXHfGfx.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, 9 Sep 2008, Ian Weller wrote: On Tue, Sep 09, 2008 at 03:35:41PM -0500, Mike McGrath wrote: This is one of the things we're hoping to prevent with fedorahosted. The hope is that the fedorahosted brand will be known for good, active projects. Not vaporware. We'll certainly be contacting the project members and let them know whats up giving them the option to grab the raw source tree (already available via rsync) and the trac install. In general from the infrastructure side I'd say we want to keep the barrier to enter low but the quality high. Certainly there's projects that don't need to be updated every 6 months but we can identify those and deal accordingly. None of this seems to agree with the open source philosophy. From what I understand, one should always be able to access code, whether dead, buggy, or release candidate, or whatever. I understand the idea of keeping a code center clean and newish, but I think it would turn away more projects than dead codebases would. Let me know when you get archives.fedorahosted.org up, I'll make sure to send all this unused code your way ;-) We're not trying to be the end all hosting for everyone. If that turns people away, there are plenty of alternatives. We're looking for people who have active and interesting projects. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, Sep 09, 2008 at 02:35:56PM -0500, Matt Domsch wrote: On Tue, Sep 09, 2008 at 12:02:04PM -0400, Jeremy Katz wrote: On Tue, 2008-09-09 at 20:33 +0530, susmit shannigrahi wrote: As explained by mmcgrath, Fedora has a policy to remove _any_ hosted projects that are not altered or updated for last six months. Hmmm -- this seems a little problematic. It's definitely possible to have a mature project which doesn't see a lot of changes. Not that all of these necessarily fall into that case, but some of them definitely do good point. yeah, like setarch. Isn't likely to change much... Bad example. setarch(1) was merged into util-linux-ng one year ago. Karel -- Karel Zak [EMAIL PROTECTED] ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath [EMAIL PROTECTED] wrote: In general from the infrastructure side I'd say we want to keep the barrier to enter low but the quality high. Certainly there's projects that don't need to be updated every 6 months but we can identify those and deal accordingly. How about 'delisting' instead of deleting? I'm operating under the assumption that the infrastructure burden of hosting the project isn't the problem you're trying to solve, and that keeping the projects at fedora hosted relevant is. A delisted project simply wouldn't appear on the main fedora hosted list of projects, but would still be available via direct link. That way, nothing is lost, but the clutter vanishes. You could even have yet another category for projects that are known to be abandoned. -RN -- Robin Norwood The Sage does nothing, yet nothing remains undone. -Lao Tzu, Te Tao Ching ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
RE: Removal of old projects from fedorahosted.
-Original Message- From: [EMAIL PROTECTED] [mailto:fedora- [EMAIL PROTECTED] On Behalf Of Robin Norwood Sent: Tuesday, September 09, 2008 6:11 PM To: Fedora Infrastructure Subject: Re: Removal of old projects from fedorahosted. On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath [EMAIL PROTECTED] wrote: In general from the infrastructure side I'd say we want to keep the barrier to enter low but the quality high. Certainly there's projects that don't need to be updated every 6 months but we can identify those and deal accordingly. How about 'delisting' instead of deleting? I'm operating under the assumption that the infrastructure burden of hosting the project isn't the problem you're trying to solve, and that keeping the projects at fedora hosted relevant is. A delisted project simply wouldn't appear on the main fedora hosted list of projects, but would still be available via direct link. That way, nothing is lost, but the clutter vanishes. You could even have yet another category for projects that are known to be abandoned. What about using a Sourceforge-style project classification scheme? Allow projects to self-identify their status (Alpha, Beta, Stable, Abandoned, etc.). That would allow us to craft policies around project updates that are more in line with their current development status. It would also allow us to filter the main project page according to development status. For example: maybe alpha projects need to be updated at least every 3-6 months, but stable projects would only need a minimum of a yearly or bi-yearly update to be considered actively maintained. ---Brett. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, 9 Sep 2008, Robin Norwood wrote: On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath [EMAIL PROTECTED] wrote: In general from the infrastructure side I'd say we want to keep the barrier to enter low but the quality high. Certainly there's projects that don't need to be updated every 6 months but we can identify those and deal accordingly. How about 'delisting' instead of deleting? I'm operating under the assumption that the infrastructure burden of hosting the project isn't the problem you're trying to solve, and that keeping the projects at fedora hosted relevant is. A delisted project simply wouldn't appear on the main fedora hosted list of projects, but would still be available via direct link. That way, nothing is lost, but the clutter vanishes. You could even have yet another category for projects that are known to be abandoned. Nope, the terms of use are already pretty clear. And no one has provided a compelling reason to keep these projects around, just lots of suggestions on how to keep them around. Deleted is what we want, not delisted or saved forever or anything like that. We're not going to commit any resources to a project that choosed not to use this free service. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
RE: Removal of old projects from fedorahosted.
On Tue, 9 Sep 2008, Brett Lentz wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:fedora- [EMAIL PROTECTED] On Behalf Of Robin Norwood Sent: Tuesday, September 09, 2008 6:11 PM To: Fedora Infrastructure Subject: Re: Removal of old projects from fedorahosted. On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath [EMAIL PROTECTED] wrote: In general from the infrastructure side I'd say we want to keep the barrier to enter low but the quality high. Certainly there's projects that don't need to be updated every 6 months but we can identify those and deal accordingly. How about 'delisting' instead of deleting? I'm operating under the assumption that the infrastructure burden of hosting the project isn't the problem you're trying to solve, and that keeping the projects at fedora hosted relevant is. A delisted project simply wouldn't appear on the main fedora hosted list of projects, but would still be available via direct link. That way, nothing is lost, but the clutter vanishes. You could even have yet another category for projects that are known to be abandoned. What about using a Sourceforge-style project classification scheme? Allow projects to self-identify their status (Alpha, Beta, Stable, Abandoned, etc.). That would allow us to craft policies around project updates that are more in line with their current development status. It would also allow us to filter the main project page according to development status. For example: maybe alpha projects need to be updated at least every 3-6 months, but stable projects would only need a minimum of a yearly or bi-yearly update to be considered actively maintained. Why? -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
RE: Removal of old projects from fedorahosted.
On Tue, 9 Sep 2008, Brett Lentz wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:fedora- [EMAIL PROTECTED] On Behalf Of Robin Norwood Sent: Tuesday, September 09, 2008 6:11 PM To: Fedora Infrastructure Subject: Re: Removal of old projects from fedorahosted. On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath [EMAIL PROTECTED] wrote: In general from the infrastructure side I'd say we want to keep the barrier to enter low but the quality high. Certainly there's projects that don't need to be updated every 6 months but we can identify those and deal accordingly. How about 'delisting' instead of deleting? I'm operating under the assumption that the infrastructure burden of hosting the project isn't the problem you're trying to solve, and that keeping the projects at fedora hosted relevant is. A delisted project simply wouldn't appear on the main fedora hosted list of projects, but would still be available via direct link. That way, nothing is lost, but the clutter vanishes. You could even have yet another category for projects that are known to be abandoned. What about using a Sourceforge-style project classification scheme? Allow projects to self-identify their status (Alpha, Beta, Stable, Abandoned, etc.). That would allow us to craft policies around project updates that are more in line with their current development status. It would also allow us to filter the main project page according to development status. For example: maybe alpha projects need to be updated at least every 3-6 months, but stable projects would only need a minimum of a yearly or bi-yearly update to be considered actively maintained. Actually re-reading this I think people are confused about my intent. We're going to contact the individuals to let them know their options. If they really want to keep the repo around and they have a good reason, it'll probably stay around. not all repos are active every 6 months but they are still important projects. However there are probably lots of projects that don't fit into this category, and they're more then welcome to host their projects elsewhere. As I explained earlier its not a hard and fast rule, we just reserve the right to remove it. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath [EMAIL PROTECTED] wrote: Nope, the terms of use are already pretty clear. And no one has provided a compelling reason to keep these projects around, just lots of suggestions on how to keep them around. Deleted is what we want, not delisted or saved forever or anything like that. We're not going to commit any resources to a project that choosed not to use this free service. Well, because sooner or later, you'll delete a project that someone didn't want deleted, and they'll be ticked off. Maybe they'll open a ticket and convince the infra. team to restore the data from a backup, or maybe they'll just be ticked off and rant about how much Fedora sucks for deleting this thing they didn't want deleted. Again, I'm assuming the per-project maintenence cost is near zero (ie, a little bit of disk space). If not, then maybe I could see a case for automatically deleting old projects. -RN -- Robin Norwood The Sage does nothing, yet nothing remains undone. -Lao Tzu, Te Tao Ching ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
RE: Removal of old projects from fedorahosted.
-Original Message- From: [EMAIL PROTECTED] [mailto:fedora- [EMAIL PROTECTED] On Behalf Of Mike McGrath Sent: Tuesday, September 09, 2008 6:37 PM To: Fedora Infrastructure Subject: RE: Removal of old projects from fedorahosted. On Tue, 9 Sep 2008, Brett Lentz wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:fedora- [EMAIL PROTECTED] On Behalf Of Robin Norwood Sent: Tuesday, September 09, 2008 6:11 PM To: Fedora Infrastructure Subject: Re: Removal of old projects from fedorahosted. On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath [EMAIL PROTECTED] wrote: In general from the infrastructure side I'd say we want to keep the barrier to enter low but the quality high. Certainly there's projects that don't need to be updated every 6 months but we can identify those and deal accordingly. How about 'delisting' instead of deleting? I'm operating under the assumption that the infrastructure burden of hosting the project isn't the problem you're trying to solve, and that keeping the projects at fedora hosted relevant is. A delisted project simply wouldn't appear on the main fedora hosted list of projects, but would still be available via direct link. That way, nothing is lost, but the clutter vanishes. You could even have yet another category for projects that are known to be abandoned. What about using a Sourceforge-style project classification scheme? Allow projects to self-identify their status (Alpha, Beta, Stable, Abandoned, etc.). That would allow us to craft policies around project updates that are more in line with their current development status. It would also allow us to filter the main project page according to development status. For example: maybe alpha projects need to be updated at least every 3-6 months, but stable projects would only need a minimum of a yearly or bi-yearly update to be considered actively maintained. Why? This would help prevent having more stable projects up on the chopping block every six months simply because they haven't done anything recently. Obviously, each time this comes up, fedora-admin will gradually collect this information anyway just by virtue of having the discussion of whom to delete. However, it doesn't make sense to me to discard this information each time the current discussion ends. It also doesn't makes sense to continually rehash this same discussion over the same projects every six months if everyone suddenly forgets that the foo project is a stable app that doesn't see many updates because it just works. Or, more plausibly, whenever we have a new member that asks what about project foo? Why doesn't it get deleted? It seems like it would be better to just have a more robust process and encourage project state information to be better documented for future discussions and future admins. It's also entirely possible that I'm over-thinking the issue. :-) ---Brett. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, 9 Sep 2008, Robin Norwood wrote: On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath [EMAIL PROTECTED] wrote: Nope, the terms of use are already pretty clear. And no one has provided a compelling reason to keep these projects around, just lots of suggestions on how to keep them around. Deleted is what we want, not delisted or saved forever or anything like that. We're not going to commit any resources to a project that choosed not to use this free service. Well, because sooner or later, you'll delete a project that someone didn't want deleted, and they'll be ticked off. Maybe they'll open a ticket and convince the infra. team to restore the data from a backup, or maybe they'll just be ticked off and rant about how much Fedora sucks for deleting this thing they didn't want deleted. I'm fine with that. Its well documented. and its not like we're going to rm -rf the thing. We'll keep it around for a while but no promises. Again, I'm assuming the per-project maintenence cost is near zero (ie, a little bit of disk space). If not, then maybe I could see a case for automatically deleting old projects. Ah, thats an incorrect assumption. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, 2008-09-09 at 20:34 -0500, Mike McGrath wrote: On Tue, 9 Sep 2008, Robin Norwood wrote: On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath [EMAIL PROTECTED] wrote: In general from the infrastructure side I'd say we want to keep the barrier to enter low but the quality high. Certainly there's projects that don't need to be updated every 6 months but we can identify those and deal accordingly. How about 'delisting' instead of deleting? I'm operating under the assumption that the infrastructure burden of hosting the project isn't the problem you're trying to solve, and that keeping the projects at fedora hosted relevant is. A delisted project simply wouldn't appear on the main fedora hosted list of projects, but would still be available via direct link. That way, nothing is lost, but the clutter vanishes. You could even have yet another category for projects that are known to be abandoned. Nope, the terms of use are already pretty clear. And no one has provided a compelling reason to keep these projects around, just lots of suggestions on how to keep them around. Deleted is what we want, not delisted or saved forever or anything like that. We're not going to commit any resources to a project that choosed not to use this free service. Compelling reason: application is in Fedora today, maintained in fedorahosted and ends up in RHEL. A year after RHEL release, the app is obsoleted by something else in Fedora. Thus, the app in hosted basically gets very little in the way of updates. But keeping the source repository available is very important for any updates later needed for RHEL. Jeremy ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, 9 Sep 2008, Jeremy Katz wrote: On Tue, 2008-09-09 at 20:34 -0500, Mike McGrath wrote: On Tue, 9 Sep 2008, Robin Norwood wrote: On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath [EMAIL PROTECTED] wrote: In general from the infrastructure side I'd say we want to keep the barrier to enter low but the quality high. Certainly there's projects that don't need to be updated every 6 months but we can identify those and deal accordingly. How about 'delisting' instead of deleting? I'm operating under the assumption that the infrastructure burden of hosting the project isn't the problem you're trying to solve, and that keeping the projects at fedora hosted relevant is. A delisted project simply wouldn't appear on the main fedora hosted list of projects, but would still be available via direct link. That way, nothing is lost, but the clutter vanishes. You could even have yet another category for projects that are known to be abandoned. Nope, the terms of use are already pretty clear. And no one has provided a compelling reason to keep these projects around, just lots of suggestions on how to keep them around. Deleted is what we want, not delisted or saved forever or anything like that. We're not going to commit any resources to a project that choosed not to use this free service. Compelling reason: application is in Fedora today, maintained in fedorahosted and ends up in RHEL. A year after RHEL release, the app is obsoleted by something else in Fedora. Thus, the app in hosted basically gets very little in the way of updates. But keeping the source repository available is very important for any updates later needed for RHEL. I don't see why that project would get removed. I really think I'm getting misunderstood here. 1) we send an email to the group members explaining their project is stale and asking to remove it. 2) they respond saying they'd like to not have it removed. (it stays) 3) they respond saying its no longer used and it can be removed (we remove it or they move it elsewhere) 4) no one responds (it gets removed) -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, 2008-09-09 at 22:11 -0400, Jeremy Katz wrote: On Tue, 2008-09-09 at 20:34 -0500, Mike McGrath wrote: On Tue, 9 Sep 2008, Robin Norwood wrote: On Tue, Sep 9, 2008 at 4:35 PM, Mike McGrath [EMAIL PROTECTED] wrote: In general from the infrastructure side I'd say we want to keep the barrier to enter low but the quality high. Certainly there's projects that don't need to be updated every 6 months but we can identify those and deal accordingly. How about 'delisting' instead of deleting? I'm operating under the assumption that the infrastructure burden of hosting the project isn't the problem you're trying to solve, and that keeping the projects at fedora hosted relevant is. A delisted project simply wouldn't appear on the main fedora hosted list of projects, but would still be available via direct link. That way, nothing is lost, but the clutter vanishes. You could even have yet another category for projects that are known to be abandoned. Nope, the terms of use are already pretty clear. And no one has provided a compelling reason to keep these projects around, just lots of suggestions on how to keep them around. Deleted is what we want, not delisted or saved forever or anything like that. We're not going to commit any resources to a project that choosed not to use this free service. Compelling reason: application is in Fedora today, maintained in fedorahosted and ends up in RHEL. A year after RHEL release, the app is obsoleted by something else in Fedora. Thus, the app in hosted basically gets very little in the way of updates. But keeping the source repository available is very important for any updates later needed for RHEL. Also, isn't there something in the GPL about keeping everything around for (at least) three years? I think delisting is better than removing, I'd even be prepared to say delisting+read only is an even better choice (think: disappears off main fh.o and the commit group gets disabled or set to inactive (i.e. shell access isn't given as part of that group)), after three years, then by all means. Six months just seems short (that's my only thought). - Nigel Jeremy ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list -- Nigel Jones [EMAIL PROTECTED] ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, 2008-09-09 at 21:02 -0500, Mike McGrath wrote: On Tue, 9 Sep 2008, Robin Norwood wrote: On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath [EMAIL PROTECTED] wrote: Nope, the terms of use are already pretty clear. And no one has provided a compelling reason to keep these projects around, just lots of suggestions on how to keep them around. Deleted is what we want, not delisted or saved forever or anything like that. We're not going to commit any resources to a project that choosed not to use this free service. Well, because sooner or later, you'll delete a project that someone didn't want deleted, and they'll be ticked off. Maybe they'll open a ticket and convince the infra. team to restore the data from a backup, or maybe they'll just be ticked off and rant about how much Fedora sucks for deleting this thing they didn't want deleted. I'm fine with that. Its well documented. and its not like we're going to rm -rf the thing. We'll keep it around for a while but no promises. Again, I'm assuming the per-project maintenence cost is near zero (ie, a little bit of disk space). If not, then maybe I could see a case for automatically deleting old projects. Ah, thats an incorrect assumption. Is there a way to balance deactivating the greater project needs with the value of the source code as a useful historical artifact? In other words, if we reduced (for example) an active git-based project to just the .git stuff, and made it available for download only, then the cost really is just disk space, right? I wouldn't want to see Infrastructure roped into committing lots of resources to carry a ton of dead projects. If there's a significant per-project maintenance cost, even if it just adds up to something significant over hundreds of projects, the work has to be justified somehow. Is there a way to keep the source around but not induce the maintenance cost? Am I being naive about this? -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Wed, 10 Sep 2008, Paul W. Frields wrote: On Tue, 2008-09-09 at 21:02 -0500, Mike McGrath wrote: On Tue, 9 Sep 2008, Robin Norwood wrote: On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath [EMAIL PROTECTED] wrote: Nope, the terms of use are already pretty clear. And no one has provided a compelling reason to keep these projects around, just lots of suggestions on how to keep them around. Deleted is what we want, not delisted or saved forever or anything like that. We're not going to commit any resources to a project that choosed not to use this free service. Well, because sooner or later, you'll delete a project that someone didn't want deleted, and they'll be ticked off. Maybe they'll open a ticket and convince the infra. team to restore the data from a backup, or maybe they'll just be ticked off and rant about how much Fedora sucks for deleting this thing they didn't want deleted. I'm fine with that. Its well documented. and its not like we're going to rm -rf the thing. We'll keep it around for a while but no promises. Again, I'm assuming the per-project maintenence cost is near zero (ie, a little bit of disk space). If not, then maybe I could see a case for automatically deleting old projects. Ah, thats an incorrect assumption. Is there a way to balance deactivating the greater project needs with the value of the source code as a useful historical artifact? In other words, if we reduced (for example) an active git-based project to just the .git stuff, and made it available for download only, then the cost really is just disk space, right? Nope not just disk space. I wouldn't want to see Infrastructure roped into committing lots of resources to carry a ton of dead projects. If there's a significant per-project maintenance cost, even if it just adds up to something significant over hundreds of projects, the work has to be justified somehow. Is there a way to keep the source around but not induce the maintenance cost? Am I being naive about this? Backups, time to maintain, bandwidth for the backups, testing when we make changes, people to notify should our Infrastructure get compromised again, etc, the unknown. Its all those little things that people don't think about that I worries me. What's the benefit of keeping them around? I mean, I can commit to saying we'll remove a project and keep it offline for a year if someone complains we'll give it to them. I guess I'm just putting my foot down on this since almost all the support for keep everything around forever has come from people that don't have to deal with the consequences of that decision. This isn't a file being kept on someones desktop... -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, 2008-09-09 at 21:20 -0500, Mike McGrath wrote: I don't see why that project would get removed. I really think I'm getting misunderstood here. I think that part of the misunderstanding is that I don't see six months as equivalent to stale. We're not even to the seven year point of RHEL 2.1. And there are definitely things that I personally migrated from elvis - fedorahosted that, while not relevant with current distros still are for older RHEL. 1) we send an email to the group members explaining their project is stale and asking to remove it. 2) they respond saying they'd like to not have it removed. (it stays) It stays for how long? If we look at the set of what's being talked about here, I can already tell you that the vast majority are going to fall into the wanting to be kept category. Which means that we're doing a lot of administrative overhead for how much gain? 3) they respond saying its no longer used and it can be removed (we remove it or they move it elsewhere) 4) no one responds (it gets removed) Within what time period? And if it later becomes relevant/needed again we just hope that someone has a backup? Jeremy ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, 2008-09-09 at 21:33 -0500, Mike McGrath wrote: On Wed, 10 Sep 2008, Paul W. Frields wrote: On Tue, 2008-09-09 at 21:02 -0500, Mike McGrath wrote: On Tue, 9 Sep 2008, Robin Norwood wrote: On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath [EMAIL PROTECTED] wrote: Nope, the terms of use are already pretty clear. And no one has provided a compelling reason to keep these projects around, just lots of suggestions on how to keep them around. Deleted is what we want, not delisted or saved forever or anything like that. We're not going to commit any resources to a project that choosed not to use this free service. Well, because sooner or later, you'll delete a project that someone didn't want deleted, and they'll be ticked off. Maybe they'll open a ticket and convince the infra. team to restore the data from a backup, or maybe they'll just be ticked off and rant about how much Fedora sucks for deleting this thing they didn't want deleted. I'm fine with that. Its well documented. and its not like we're going to rm -rf the thing. We'll keep it around for a while but no promises. Again, I'm assuming the per-project maintenence cost is near zero (ie, a little bit of disk space). If not, then maybe I could see a case for automatically deleting old projects. Ah, thats an incorrect assumption. Is there a way to balance deactivating the greater project needs with the value of the source code as a useful historical artifact? In other words, if we reduced (for example) an active git-based project to just the .git stuff, and made it available for download only, then the cost really is just disk space, right? Nope not just disk space. I wouldn't want to see Infrastructure roped into committing lots of resources to carry a ton of dead projects. If there's a significant per-project maintenance cost, even if it just adds up to something significant over hundreds of projects, the work has to be justified somehow. Is there a way to keep the source around but not induce the maintenance cost? Am I being naive about this? Backups, time to maintain, bandwidth for the backups, testing when we make changes, people to notify should our Infrastructure get compromised again, etc, the unknown. Backups really are equivalent to disk space. Testing for changes -- maybe. But if it's really that inactive, then a change is unlikely to break it. And if it does, then when someone notices, they'll holler. As for the people to notify bit, I liked Nigel's idea of delist +read-only -- then you don't have to worry about notifying, but at the same time, it's easy to have access restored if it becomes relevant. Its all those little things that people don't think about that I worries me. What's the benefit of keeping them around? I mean, I can commit to saying we'll remove a project and keep it offline for a year if someone complains we'll give it to them. The benefit of keeping them around is the same as the benefit for why we don't prune historical src.rpms or tarballs from distcvs. Or why we don't prune the history of source repos in general. Yes, it may be ancient history, but it's still history. And there's a lot that can be learned from history. Just ask the people that have done things like importing _all_ kernel history since the dawn of time (that at least they can find tarballs for). Or ajax and his X since the dawn of time archive. I guess I'm just putting my foot down on this since almost all the support for keep everything around forever has come from people that don't have to deal with the consequences of that decision. This isn't a file being kept on someones desktop... You're right, it's not a file that's being kept on someone's desktop. It's something far more important -- it's the DNA of the evolution of open source. Jeremy ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, 9 Sep 2008, Jeremy Katz wrote: On Tue, 2008-09-09 at 21:20 -0500, Mike McGrath wrote: I don't see why that project would get removed. I really think I'm getting misunderstood here. I think that part of the misunderstanding is that I don't see six months as equivalent to stale. We're not even to the seven year point of RHEL 2.1. And there are definitely things that I personally migrated from elvis - fedorahosted that, while not relevant with current distros still are for older RHEL. 1) we send an email to the group members explaining their project is stale and asking to remove it. 2) they respond saying they'd like to not have it removed. (it stays) It stays for how long? If we look at the set of what's being talked about here, I can already tell you that the vast majority are going to fall into the wanting to be kept category. Which means that we're doing a lot of administrative overhead for how much gain? Till they say otherwise or until the board says to take it down. 3) they respond saying its no longer used and it can be removed (we remove it or they move it elsewhere) 4) no one responds (it gets removed) Within what time period? And if it later becomes relevant/needed again we just hope that someone has a backup? Yep, its well documented and if thats not ok for them, there's other offerings out there. I will not let our offering become another sourceforge and become the butt of every packagers jokes. Bottom line, hosting isn't what _WE_ do. its a value added service and I'm keeping that well in mind. As far as administrative overhead. I've spent far more time on sending emails about it then it took for us to run the scripts and contact the hosts. fedorahosted != elvis fedorahosted != sourceforge If you want elvis, you can put your stuff there. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, 9 Sep 2008, Jeremy Katz wrote: Backups, time to maintain, bandwidth for the backups, testing when we make changes, people to notify should our Infrastructure get compromised again, etc, the unknown. Backups really are equivalent to disk space. Testing for changes -- maybe. But if it's really that inactive, then a change is unlikely to break it. And if it does, then when someone notices, they'll holler. yeah, when you backup to disk over a LAN, neither of which we do. Yes, it may be ancient history, but it's still history. And there's a lot that can be learned from history. Just ask the people that have done things like importing _all_ kernel history since the dawn of time (that at least they can find tarballs for). Or ajax and his X since the dawn of time archive. I guess I'm just putting my foot down on this since almost all the support for keep everything around forever has come from people that don't have to deal with the consequences of that decision. This isn't a file being kept on someones desktop... You're right, it's not a file that's being kept on someone's desktop. It's something far more important -- it's the DNA of the evolution of open source. Then they can keep their DNA somewhere else. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, 9 Sep 2008, Mike McGrath wrote: On Tue, 9 Sep 2008, Jeremy Katz wrote: Backups, time to maintain, bandwidth for the backups, testing when we make changes, people to notify should our Infrastructure get compromised again, etc, the unknown. Backups really are equivalent to disk space. Testing for changes -- maybe. But if it's really that inactive, then a change is unlikely to break it. And if it does, then when someone notices, they'll holler. yeah, when you backup to disk over a LAN, neither of which we do. Actually this isn't true, we do local backup to remote disk over a LAN via a sync, we also do a remote backup to tape. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Removal of old projects from fedorahosted.
On Tue, 9 Sep 2008, Jeremy Katz wrote: On Tue, 2008-09-09 at 21:33 -0500, Mike McGrath wrote: On Wed, 10 Sep 2008, Paul W. Frields wrote: On Tue, 2008-09-09 at 21:02 -0500, Mike McGrath wrote: On Tue, 9 Sep 2008, Robin Norwood wrote: On Tue, Sep 9, 2008 at 9:34 PM, Mike McGrath [EMAIL PROTECTED] wrote: Nope, the terms of use are already pretty clear. And no one has provided a compelling reason to keep these projects around, just lots of suggestions on how to keep them around. Deleted is what we want, not delisted or saved forever or anything like that. We're not going to commit any resources to a project that choosed not to use this free service. Well, because sooner or later, you'll delete a project that someone didn't want deleted, and they'll be ticked off. Maybe they'll open a ticket and convince the infra. team to restore the data from a backup, or maybe they'll just be ticked off and rant about how much Fedora sucks for deleting this thing they didn't want deleted. I'm fine with that. Its well documented. and its not like we're going to rm -rf the thing. We'll keep it around for a while but no promises. Again, I'm assuming the per-project maintenence cost is near zero (ie, a little bit of disk space). If not, then maybe I could see a case for automatically deleting old projects. Ah, thats an incorrect assumption. Is there a way to balance deactivating the greater project needs with the value of the source code as a useful historical artifact? In other words, if we reduced (for example) an active git-based project to just the .git stuff, and made it available for download only, then the cost really is just disk space, right? Nope not just disk space. I wouldn't want to see Infrastructure roped into committing lots of resources to carry a ton of dead projects. If there's a significant per-project maintenance cost, even if it just adds up to something significant over hundreds of projects, the work has to be justified somehow. Is there a way to keep the source around but not induce the maintenance cost? Am I being naive about this? Backups, time to maintain, bandwidth for the backups, testing when we make changes, people to notify should our Infrastructure get compromised again, etc, the unknown. Backups really are equivalent to disk space. Testing for changes -- maybe. But if it's really that inactive, then a change is unlikely to break it. And if it does, then when someone notices, they'll holler. As for the people to notify bit, I liked Nigel's idea of delist +read-only -- then you don't have to worry about notifying, but at the same time, it's easy to have access restored if it becomes relevant. So it seems I'm alone here, if we have to keep everything forever, thats what it'll be. I'll just have to see to it we have the resources and backup materials in the future when that time comes. I have a question and a suggestion for people. 1) What do we do with projects to which no owner or responsible party can be found? This caused major headaches during the elvis move... headaches we still have today. What would you have us do? 2) Right before we start removing projects is _not_ the time to discuss the policy. When the policy is put in place... thats the time to discuss it. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
[Fedora-legal-list] Re: Metasploit Framework License (Is it ok for Fedora?)
On Tue, 2008-09-09 at 15:36 -0700, Conrad Meyer wrote: Is this license ok for a package in Fedora (i.e. metasploit)? The full text can be found here[0]. [0]: http://metasploit.com/svn/framework3/trunk/documentation/LICENSE PS: I'm not subscribed to fedora-legal so please CC replies to me. Not sure why you didn't see this the first time, but the answer is no. That license is non-free, and thus, not okay for Fedora. ~spot ___ Fedora-legal-list mailing list Fedora-legal-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legal-list
Re: fedora-list Digest, Vol 55, Issue 69
--- On Mon, 8/9/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: fedora-list Digest, Vol 55, Issue 69 To: fedora-list@redhat.com Date: Monday, 8 September, 2008, 8:51 PM Send fedora-list mailing list submissions to fedora-list@redhat.com To subscribe or unsubscribe via the World Wide Web, visit https://www.redhat.com/mailman/listinfo/fedora-list or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of fedora-list digest... Today's Topics: 1. Spam: Open source alternative to Microsoft's System Management Server (Arch Willingham) 2. Re: Fedora 9 i386 CD images (Kevin J. Cummings) 3. Re: Fedora 9 i386 CD images (Nigel Henry) 4. grandma-rated mail reader (Wolfgang S. Rupprecht) 5. To All EEEpc and Fedora Users, getting Wlan0 and Webcam working (Jim) 6. Re: Spam: Open source alternative to Microsoft's System ManagementServer (Markku Kolkka) 7. Re: Fedora 9 i386 CD images (Patrick O'Callaghan) 8. eth0 died on reboot (Dennis Kaptain) 9. Re: Backup Server RAID Suggestions - Resend (Les Mikesell) 10. Re: Spam: Open source alternative to Microsoft's System ManagementServer (Dave Ihnat) 11. Re: help (Steve Repo) 12. Re: Spam: Open source alternative to Microsoft's System Management Server (Les Mikesell) 13. RE: Spam: Open source alternative to Microsoft's System Management Server (Arch Willingham) 14. Re: grandma-rated mail reader (Les Mikesell) 15. Re: Fedora 9 i386 CD images (Alan Cox) 16. Re: Dell OptiPlex 745 reboot problem -- BIOS update went poorly (Johnathan Hegge) -- Message: 1 Date: Mon, 8 Sep 2008 13:30:49 -0400 From: Arch Willingham [EMAIL PROTECTED] Subject: Spam: Open source alternative to Microsoft's System Management Server To: 'fedora-list@redhat.com' fedora-list@redhat.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Does anyone have an open source alternative to Microsoft's System Management Server (SMS)? SMS will do a ton of stuff but the main thing we need it for is keeping up with IT hardware assets (what computers we have, disk space on each, processors, memory, etc) and need it to keep up with Windows machines as well as Linux machines. Thanks! Arch -- next part -- An HTML attachment was scrubbed... URL: https://www.redhat.com/archives/fedora-list/attachments/20080908/d71c69a9/attachment.html -- Message: 2 Date: Mon, 08 Sep 2008 13:32:01 -0400 From: Kevin J. Cummings [EMAIL PROTECTED] Subject: Re: Fedora 9 i386 CD images To: Community assistance, encouragement, and advice for using Fedora. fedora-list@redhat.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Bing wrote: Hi, I am new to this and seeking advice. I downloaded the 6 CD images ok and run the checksum and they all were ok.. I burned the images to CD and only CD 1 and 6 show no errors on the media check. I re-burnt CD 2 to see if it was a glitch but the new disk also came up with errors. The machines I have do not have DVD drives only CD Before I try again and spend a fortune on CDs wanted to know if anybody has successfully downloaded, burnt and installed from these images. Try burning the CDs at a lower speed. This often helps. Especially with marginal media. Many thanks in anticipation. Bing -- Kevin J. Cummings [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Registered Linux User #1232 (http://counter.li.org) -- Message: 3 Date: Mon, 8 Sep 2008 19:36:17 +0200 From: Nigel Henry [EMAIL PROTECTED] Subject: Re: Fedora 9 i386 CD images To: fedora-list@redhat.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=utf-8 On Monday 08 September 2008 19:12, Bing wrote: Hi, I am new to this and seeking advice. I downloaded the 6 CD images ok and run the checksum and they all were ok.. I burned the images to CD and only CD 1 and 6 show no errors on the media check. I re-burnt CD 2 to see if it was a glitch but the new disk also came up with errors. The machines I have do not have DVD drives only CD Before I try again and spend a fortune on CDs wanted to know if anybody has successfully downloaded, burnt and installed from these images. Many thanks in anticipation. Bing A while back, not sure now which Fedora version, but the first cd was burnt to one make of CD media, and the rest of the disks were on another. the first CD passed the media check, and the rest failed, but the Fedora version installed ok with no problems with
[Fwd: Re: Fedora 8 and 9 updates status]
Thought I would forward this so anyone not on the announce lists know what is going on. Mike Chambers Madisonville, KY The best lil town on Earth! Forwarded Message From: Jesse Keating [EMAIL PROTECTED] Reply-to: fedora-list@redhat.com To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Fedora 8 and 9 updates status Date: Mon, 08 Sep 2008 14:06:47 -0700 On Fri, 2008-09-05 at 09:09 -0700, Jesse Keating wrote: Announcements regarding the location of said document and how to help with content will be coming shortly. Time for another update on the F8 and F9 updates status. Our testing with the live update content as gone well. We identified a couple issues with the current PackageKit and thanks to Richard Hughes we'll have an updated PackageKit to offer as well as an updated fedora-release package for our users. The combination of the two (or just the fedora-release package for you non-packagekit users) will be all that you will need in order to gain access to our newly signed and relocated updates. We're in the final stages of testing a few corner cases, and preparing the official builds of fedora-release, PackageKit, gnome-packagekit, and unique (needed as a new dep for gnome-packagekit). All existing updates in the old update locations will be purged, and just these updates will be put in their place, signed with our old key. Once you've updated to these packages, the next update attempt will point you to our new locations with our new keys and you should be able to process any further pending updates. You'll be prompted to import the new key along the way. A wiki page has been created that covers some of this, https://fedoraproject.org/wiki/Enabling_new_signing_key and will be updated throughout the day as we finish the above listed tasks. A more formal announcement along with links to the official FAQ will be published to same lists this mail is going out to, and likely picked up by various news sites. We expect things to wrap up by the end of today or early tomorrow. Once again we thank you for your continued patience and be aware that we're nearly there! -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Script Test [OT]
On 08Sep2008 21:04, Kevin J. Cummings [EMAIL PROTECTED] wrote: Alan Evans wrote: On Mon, Sep 8, 2008 at 6:40 AM, Steven Tardy [EMAIL PROTECTED] wrote: kwhiskerz wrote: man hostid On my Fedora 9... $ hostid Now I haven't bothered to check any other machines, but my initial impression is that this is not going to work... I just checked the hostids on my 2 primary machines on the same local network. They just seem to be encodings of the machine's IP addresses. And since both are PC class machines, the addresses look to be syllable swapped (but not byte swapped). 192.168.6.94 and 192.168.6.106 a8c05e06 and a8c06a06 So, I have to ask, does the machine you tried it on have an IP address? So, let us turn to the docs: man hostid says: hostid - print the numeric identifier for the current host [...] The full documentation for hostid is maintained as a Texinfo manual [...] Gah. I hate this info-so-no-f'n-man-page rubbish! But let's go: info hostid: 21.4 `hostid': Print numeric host identifier. = `hostid' prints the numeric identifier of the current host in hexadecimal. This command accepts no arguments. The only options are `--help' and `--version'. *Note Common options::. For example, here's what it prints on one system I use: $ hostid 1bac013d On that system, the 32-bit quantity happens to be closely related to the system's Internet address, but that isn't always the case. Gah! Again! I don't think I'd rely on hostid for anything:-( Cheers, -- Cameron Simpson [EMAIL PROTECTED] DoD#743 http://www.cskk.ezoshosting.com/cs/ A good newspaper is never good enough, but a lousy newspaper is a joy forever.- Garrison Keillor -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Script Test [OT]
Cameron Simpson wrote: On 08Sep2008 21:04, Kevin J. Cummings [EMAIL PROTECTED] wrote: Alan Evans wrote: On Mon, Sep 8, 2008 at 6:40 AM, Steven Tardy [EMAIL PROTECTED] wrote: kwhiskerz wrote: man hostid On my Fedora 9... $ hostid Now I haven't bothered to check any other machines, but my initial impression is that this is not going to work... I just checked the hostids on my 2 primary machines on the same local network. They just seem to be encodings of the machine's IP addresses. And since both are PC class machines, the addresses look to be syllable swapped (but not byte swapped). 192.168.6.94 and 192.168.6.106 a8c05e06 and a8c06a06 So, I have to ask, does the machine you tried it on have an IP address? So, let us turn to the docs: man hostid says: hostid - print the numeric identifier for the current host [...] The full documentation for hostid is maintained as a Texinfo manual [...] Gah. I hate this info-so-no-f'n-man-page rubbish! But let's go: info hostid: 21.4 `hostid': Print numeric host identifier. = `hostid' prints the numeric identifier of the current host in hexadecimal. This command accepts no arguments. The only options are `--help' and `--version'. *Note Common options::. For example, here's what it prints on one system I use: $ hostid 1bac013d On that system, the 32-bit quantity happens to be closely related to the system's Internet address, but that isn't always the case. Gah! Again! I don't think I'd rely on hostid for anything:-( Cheers, Hi, seeing the same (using dhcp for getting an ip address): [EMAIL PROTECTED] [backes]: hostid [EMAIL PROTECTED] [backes]: ifconfig eth0 Link encap:Ethernet HWaddr 00:0C:76:C0:40:36 inet addr:192.168.179.182 Bcast:192.168.179.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:284 errors:0 dropped:0 overruns:0 frame:0 TX packets:256 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:86392 (84.3 KiB) TX bytes:25620 (25.0 KiB) Interrupt:22 Base address:0x2000 Not seeing this effect on systems without dhcp usage. Regards -- Joachim Backes [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Dell OptiPlex 745 reboot problem -- BIOS update went poorly
Reply below V V On Fri, Sep 5, 2008 at 2:51 PM, Johnathan Hegge [EMAIL PROTECTED] wrote: Forwarded Message From: Bjørn Tore Sund [EMAIL PROTECTED] Reply-To: Community assistance, encouragement, and advice for using Fedora. fedora-list@redhat.com To: fedora-list@redhat.com fedora-list@redhat.com Subject: Re: Dell OptiPlex 745 reboot problem Date: Fri, 05 Sep 2008 21:21:46 +0200 Tony Molloy wrote: On Friday 05 September 2008 16:05:04 Mike McCarty wrote: Tony Molloy wrote: Hi, I've just installed Fedora-9 on a lab of Dell OptiPlex 745 (SFF) machines. ( only in 1 lab TG ) After running firstboot when I went to reboot the machines they just hang and I had to do a hard reboot. I thought this was a minor glitch and ignored it. Now however when the machines boot into Fedora-9 the reboot and suspend buttons do not work. The windowing system just shuts down and I get a text prompt and the machines just hang there. Hang? That's a vague term. If you type on the keyboard, do characters get echoed? If you have a text prompt, then can you not do a Hang means exactly what it means. The machines just go dead!!! No input from the keyboard accepted. Only thing to do is a hard reboot. Got tons of Dell Optiplex 7XX, had that exact problem. Solution is two-step: 1. Flash up the bios. The ones they're shipped with suck bigtime. 2. Add the kernel parameter reboot=bios to all kernel lines in /boot/grub/menu.lst Solved it for us. -BT Ugh, I was having the same problem with my 745. So, I drug out a USB floppy and applied the latest BIOS -- going from 2.3.1 to 2.6.2 from Dell. Whoops. Starting up looks fine, all services showed OK. Gets to local, X starts and the box freezes at the spinning dots with a frozen mouse. Can't break with Ctrl-Alt-Del or Ctrl-Backspace. Hard power, restart, interactive init. Allow all, but skip local. X starts fine. rc.local contains: #!/bin/sh # # This script will be executed *after* all the other init scripts. # You can put your own initialization stuff in here if you don't # want to do the full Sys V style init stuff. touch /var/lock/subsys/local Reset BIOS to defaults for kicks, no change. I have a PCI Express graphics card, ATI x1300 installed. Any ideas? I guess I can revert BIOS one by one backward to see if it works. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines Hi Johnathan Hegge! Did you try doing a CTL+ALT+F1 (evokes a login terminal - as does CTL+ALT+F2 to F6 - F7 to X and F8 to just before the start of X)? From there, or by using a rescue or Live CD booted to a terminal you can check several places in /var/log - I would look at Xorg.0.log, messages, dmesg, and possibly syslog. Doing a word search on EE in Xorg.0.log and fail or error etc... can often get you to the problem quickly. You may also try some boot options designed to help in other areas. The problem you mention, espically with the small form factor machines seems to have a history. Amongst many I found this link: http://lkml.org/lkml/2008/3/12/201 -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: eject: unable to find or open device for: `cdrom'
On Tue, Sep 9, 2008 at 1:09 AM, Mikkel L. Ellertson
[EMAIL PROTECTED] wrote:
The problem has partially returned. In my case, I have
# ls /dev/cdrom*
/dev/cdrom1
#
And I do the following:
# cd /dev
# ln -s ./cdrom1 cdrom
that solves the problem until a new reboot. After a new reboot, I have
to apply the solution above explained; otherwise, I get
$ eject
eject: unable to find or open device for: `cdrom'
$
What can I do to make this solution permanent, i.e., not destroyed by a
reboot?
You may have to edit /etc/udev/rules.d/70-persistent-cd.rules and
make sure that the rules for creating the cdrom and cdrom0 are
correct. In your case, I suspect that the rules for cdrom1 should be
for cdrom0. Depending on the drive, it may also have dvd and dvdrw
rules.
The fix is fairly simple - comment out, or delete the devicd0
rules, change the device1 rules to device0, and copy the first
of the old cdrom1 (new cdrom0) rules and change cdrom1 to cdrom in
the copied rule.
When you reboot, all should be fine.
Thanks, Mikkel, but my /etc/udev/rules.d/70-persistent-cd.rules does
not look as you describe:
# more /etc/udev/rules.d/70-persistent-cd.rules
# This file was automatically generated by the /lib/udev/write_cd_rules
# program, probably run by the cd-aliases-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line
# and set the $GENERATED variable.
# DVD_RW_ND-3520A (pci-:04:06.0-scsi-0:0:1:0)
ENV{ID_CDROM}==?*, ENV{ID_PATH}==pci-:04:06.0-scsi-0:0:1:0,
SYMLINK+=cdrom, ENV{GENERATED}=1
ENV{ID_CDROM}==?*, ENV{ID_PATH}==pci-:04:06.0-scsi-0:0:1:0,
SYMLINK+=cdrw, ENV{GENERATED}=1
ENV{ID_CDROM}==?*, ENV{ID_PATH}==pci-:04:06.0-scsi-0:0:1:0,
SYMLINK+=dvd, ENV{GENERATED}=1
ENV{ID_CDROM}==?*, ENV{ID_PATH}==pci-:04:06.0-scsi-0:0:1:0,
SYMLINK+=dvdrw, ENV{GENERATED}=1
# (pci-:00:1f.2-scsi-1:0:1:0)
ENV{ID_CDROM}==?*, ENV{ID_PATH}==pci-:00:1f.2-scsi-1:0:1:0,
SYMLINK+=cdrom1, ENV{GENERATED}=1
ENV{ID_CDROM}==?*, ENV{ID_PATH}==pci-:00:1f.2-scsi-1:0:1:0,
SYMLINK+=cdrw1, ENV{GENERATED}=1
ENV{ID_CDROM}==?*, ENV{ID_PATH}==pci-:00:1f.2-scsi-1:0:1:0,
SYMLINK+=dvd1, ENV{GENERATED}=1
ENV{ID_CDROM}==?*, ENV{ID_PATH}==pci-:00:1f.2-scsi-1:0:1:0,
SYMLINK+=dvdrw1, ENV{GENERATED}=1
#
Paul
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Script Test [OT]
[EMAIL PROTECTED] wrote: Cameron Simpson wrote: On 08Sep2008 21:04, Kevin J. Cummings [EMAIL PROTECTED] wrote: Alan Evans wrote: On Mon, Sep 8, 2008 at 6:40 AM, Steven Tardy [EMAIL PROTECTED] wrote: kwhiskerz wrote: man hostid On my Fedora 9... $ hostid Now I haven't bothered to check any other machines, but my initial impression is that this is not going to work... I just checked the hostids on my 2 primary machines on the same local network. They just seem to be encodings of the machine's IP addresses. And since both are PC class machines, the addresses look to be syllable swapped (but not byte swapped). 192.168.6.94 and 192.168.6.106 a8c05e06 and a8c06a06 So, I have to ask, does the machine you tried it on have an IP address? So, let us turn to the docs: man hostid says: hostid - print the numeric identifier for the current host [...] The full documentation for hostid is maintained as a Texinfo manual [...] Gah. I hate this info-so-no-f'n-man-page rubbish! But let's go: info hostid: 21.4 `hostid': Print numeric host identifier. = `hostid' prints the numeric identifier of the current host in hexadecimal. This command accepts no arguments. The only options are `--help' and `--version'. *Note Common options::. For example, here's what it prints on one system I use: $ hostid 1bac013d On that system, the 32-bit quantity happens to be closely related to the system's Internet address, but that isn't always the case. Gah! Again! I don't think I'd rely on hostid for anything:-( Cheers, Hi, seeing the same (using dhcp for getting an ip address): [EMAIL PROTECTED] [backes]: hostid [EMAIL PROTECTED] [backes]: ifconfig eth0 Link encap:Ethernet HWaddr 00:0C:76:C0:40:36 inet addr:192.168.179.182 Bcast:192.168.179.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:284 errors:0 dropped:0 overruns:0 frame:0 TX packets:256 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:86392 (84.3 KiB) TX bytes:25620 (25.0 KiB) Interrupt:22 Base address:0x2000 Not seeing this effect on systems without dhcp usage. Regards FYI, the hostid does not use information from ifconfig. It looks for a match between hostname -s and information in /etc/hosts. It then uses the IP address contained there. No match then hostid returns . -- Television is a medium because anything well done is rare. -- attributed to both Fred Allen and Ernie Kovacs -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Fedora 9 i386 CD images
On Mon, Sep 8, 2008 at 10:12 AM, Bing [EMAIL PROTECTED] wrote: Hi, I am new to this and seeking advice. I downloaded the 6 CD images ok and run the checksum and they all were ok. I burned the images to CD and only CD 1 and 6 show no errors on the media check. I re-burnt CD 2 to see if it was a glitch but the new disk also came up with errors. The machines I have do not have DVD drives only CD Before I try again and spend a fortune on CDs wanted to know if anybody has successfully downloaded, burnt and installed from these images. Many thanks in anticipation. Bing -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines Hi Bing! Try running a checksum or shasum on the disks. If they pass I would tend to use them. The media check seems to be sometimes unreliable. Have Fun! Tod -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Script Test [OT]
Ed Greshko wrote: [EMAIL PROTECTED] wrote: Cameron Simpson wrote: On 08Sep2008 21:04, Kevin J. Cummings [EMAIL PROTECTED] wrote: Alan Evans wrote: On Mon, Sep 8, 2008 at 6:40 AM, Steven Tardy [EMAIL PROTECTED] wrote: kwhiskerz wrote: man hostid On my Fedora 9... $ hostid Now I haven't bothered to check any other machines, but my initial impression is that this is not going to work... I just checked the hostids on my 2 primary machines on the same local network. They just seem to be encodings of the machine's IP addresses. And since both are PC class machines, the addresses look to be syllable swapped (but not byte swapped). 192.168.6.94 and 192.168.6.106 a8c05e06 and a8c06a06 So, I have to ask, does the machine you tried it on have an IP address? So, let us turn to the docs: man hostid says: hostid - print the numeric identifier for the current host [...] The full documentation for hostid is maintained as a Texinfo manual [...] Gah. I hate this info-so-no-f'n-man-page rubbish! But let's go: info hostid: 21.4 `hostid': Print numeric host identifier. = `hostid' prints the numeric identifier of the current host in hexadecimal. This command accepts no arguments. The only options are `--help' and `--version'. *Note Common options::. For example, here's what it prints on one system I use: $ hostid 1bac013d On that system, the 32-bit quantity happens to be closely related to the system's Internet address, but that isn't always the case. Gah! Again! I don't think I'd rely on hostid for anything:-( Cheers, Hi, seeing the same (using dhcp for getting an ip address): [EMAIL PROTECTED] [backes]: hostid [EMAIL PROTECTED] [backes]: ifconfig eth0 Link encap:Ethernet HWaddr 00:0C:76:C0:40:36 inet addr:192.168.179.182 Bcast:192.168.179.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:284 errors:0 dropped:0 overruns:0 frame:0 TX packets:256 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:86392 (84.3 KiB) TX bytes:25620 (25.0 KiB) Interrupt:22 Base address:0x2000 Not seeing this effect on systems without dhcp usage. Regards FYI, the hostid does not use information from ifconfig. It looks for a match between hostname -s and information in /etc/hosts. It then uses the IP address contained there. No match then hostid returns . Oooop... Correction. It uses hostname for the matchnot hostname -r Also, it will take the info in /etc/hosts first and if no match will do a DNS lookup. -- He knew the tavernes well in every toun. -- Geoffrey Chaucer -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Ntpdate fails to start
On Sun, Sep 7, 2008 at 5:20 PM, Björn Persson [EMAIL PROTECTED] wrote: On a typical setup ntpdate runs first (and exits) and syncs the clock close but not exactly on. If this is not done and the time is off by more than a certain amount then ntpd *WON'T* be able to sync things, and will exit with an error. Then after ntpdate gets things close, then ntpd keeps things in proper sync. The flag -g to NTPD should do the same thing in a cleaner way. This flag is set in /etc/sysconfig/ntpd in Fedora 9. In my case, I have the flag -g already active: # more /etc/sysconfig/ntpd # Drop root to id 'ntp:ntp' by default. OPTIONS=-u ntp:ntp -p /var/run/ntpd.pid -g # Paul -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Ntpdate fails to start
On Mon, Sep 8, 2008 at 1:55 PM, Tim [EMAIL PROTECTED] wrote: At booting, ntpdate fails to start, and also the following command fails: # /sbin/service ntpdate start ntpdate: Synchronizing with time server: [FAILED] The log messages are: Sep 7 12:50:50 localhost ntpdate[2908]: the NTP socket is in use, exiting Any ideas? Do you use NetworkManager to bring your network up? If so, it's not up in time for NTP to do its trick, and will be sort of running (freewheeling without synchronising to external servers) and preventing ntpdate from being usable. Thanks, Tim, but how can I check it out? Paul -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Ntpdate fails to start
On Sun, Sep 7, 2008 at 4:05 PM, Roger Heflin [EMAIL PROTECTED] wrote: At booting, ntpdate fails to start, and also the following command fails: # /sbin/service ntpdate start ntpdate: Synchronizing with time server: [FAILED] # The log messages are: Sep 7 12:50:50 localhost ntpdate[2908]: the NTP socket is in use, exiting Any ideas? service ntpd status Should show you that the ntp daemon is already running. You can't run both ntpd (the server) and ntpdate (the client) at the same time. Thanks, Stuart and Edward. Got this: # /sbin/service ntpd status ntpd (pid 2059) is running... # ntpdate tries to start at booting. So, should I disable it? Which one of the two should I have running in order to have always a correct time on my computer? either, but not both. I suggest ntpd, particularly if you run more than one machine. A local time server can be specified with the prefer (from memory) option, and that will be used if available. See the man pages on this. The nice thing about running your own server is that if your network connection drops your machines will all stay together, handy if you are trying to match logs from one machine to another. If you run just one machine it probably doesn't matter. Thanks, Bill. I am running only one machine. How can I remove one of them from trying to start at booting? Paul You may actually want both. On a typical setup ntpdate runs first (and exits) and syncs the clock close but not exactly on. If this is not done and the time is off by more than a certain amount then ntpd *WON'T* be able to sync things, and will exit with an error. Then after ntpdate gets things close, then ntpd keeps things in proper sync. stop both ntpd and ntpdate, and then start ntpdate and then start ntpd and if both succeed things is likely correct and ntpdate runs and then exits. In F8 ntpdate is ran in the ntpd script to sync things in, and then ntpd is started, they could have separated it in F9. The only way ntpdate would be sensible as a replacement is *if* something is running it every so often to keep things close, otherwise one the machine came up things would start to drift, and things would get worse the longer things were up. Thanks, Roger. How can I check whether ntpdate is ran in the ntpd script on F9? Paul -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Ntpdate fails to start
On Tuesday 09 September 2008 10:04:46 Paul Smith wrote: On Mon, Sep 8, 2008 at 1:55 PM, Tim [EMAIL PROTECTED] wrote: At booting, ntpdate fails to start, and also the following command fails: # /sbin/service ntpdate start ntpdate: Synchronizing with time server: [FAILED] The log messages are: Sep 7 12:50:50 localhost ntpdate[2908]: the NTP socket is in use, exiting Any ideas? Do you use NetworkManager to bring your network up? If so, it's not up in time for NTP to do its trick, and will be sort of running (freewheeling without synchronising to external servers) and preventing ntpdate from being usable. Thanks, Tim, but how can I check it out? Paul # service NetworkManager status will tell you if NetworkManager is running # service network status will tell you if the networkservice is running. You shouldn't have both running. Try the following and post the results # ntpq -p Tony -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: Ntpdate fails to start
On Tue, Sep 9, 2008 at 10:24 AM, Tony Molloy [EMAIL PROTECTED] wrote: At booting, ntpdate fails to start, and also the following command fails: # /sbin/service ntpdate start ntpdate: Synchronizing with time server: [FAILED] The log messages are: Sep 7 12:50:50 localhost ntpdate[2908]: the NTP socket is in use, exiting Any ideas? Do you use NetworkManager to bring your network up? If so, it's not up in time for NTP to do its trick, and will be sort of running (freewheeling without synchronising to external servers) and preventing ntpdate from being usable. Thanks, Tim, but how can I check it out? # service NetworkManager status will tell you if NetworkManager is running # service network status will tell you if the networkservice is running. You shouldn't have both running. Try the following and post the results # ntpq -p Thanks, Tony. The results: # /sbin/service NetworkManager status NetworkManager (pid 2319) is running... # # ntpq -p bash: ntpq: command not found # but # /sbin/service ntpd status ntpd (pid 2049) is running... # Paul -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: [Fwd: Re: Fedora 8 and 9 updates status]
On Tue, 2008-09-09 at 02:05 -0500, Mike Chambers wrote: Thought I would forward this so anyone not on the announce lists know what is going on. Mike Chambers Madisonville, KY The best lil town on Earth! You can join here: http://www.redhat.com/mailman/listinfo/fedora-announce-list Low volume Frank -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
