[gentoo-dev] stepping out
Hello all, I cannot keep up with my duties as a maintainer of my packages anymore (listed below). My development machine died and I ended up installing Debian on it. Gentoo was (and still is) a very good development platform but I do not have the time to maintain a Gentoo install in my desktop anymore, much less maintaining Gentoo packages. I still use Gentoo for a few embedded projects I have, I'm building the embedded images using Gentoo in a chroot, fuck buildroot, crossdev +portage is the way to go. While it is certain I cannot keep up with maintain packages anymore, I also need to rethink my role in the embedded team. I'm going to see this with them. Thank you, - Angelo Arrifano packages: - * gpe-* We should probably talk about removal of the gpe category. GPE made sense when Linux in cellphones was still on its infancy. Nowadays I doubt anymore is using it anymore. * games-simulation/corsix-th development is active in upstream, has quite a few Gentoo users. * dev-embedded/arduino does not need introduction * dev-lang/logtalk upstream is active, the version in portage is old and there haven't been any bug reports from users. I wonder if anyone is using it. * media-sound/gnaural upstream is somewhat active but their last version is old. it works though, no bug reports * sci-misc/mendeleydesktop very active upstream, you get a new version nearly every month. big user base at gentoo * media-plugins/gst-plugins-jack the version in portage is old
Re: [gentoo-dev] TrueCrypt and it's lovely license
On Seg, 2011-04-25 at 17:39 +0200, Ulrich Mueller wrote: > >>>>> On Mon, 25 Apr 2011, Dane Smith wrote: > > > These are all good enough reasons for me. Re-Restricted mirror and > > fetch in CVS. > > Maybe the description should be updated too. "Free open-source disk > encryption software" is misleading, when it's neither free software > nor fulfills the open source definition. > > Ulrich > What about enumerating some alternatives (dm-crypt+luks etc ..) in post install? Sometimes people are not aware of them and when they do, it is too late because no one in their sane mind (except me maybe) will migrate all the data again into another encryption format. - Angelo -- Angelo Arrifano (miknix) Developer / GPE maintainer http://www.gentoo.org/~miknix http://miknix.homelinux.com
Re: [gentoo-dev] no more time for SynCE
On Seg, 2011-04-11 at 17:33 +0300, Samuli Suominen wrote: > On 04/11/2011 03:01 AM, Iain Buchanan wrote: > > Hi, > > > > Since I posted about looking for help[1] I'm sad to say I've barely > > touched SynCE. Family commitments have changed, and I'm studying again > > for the degree I started 10 years ago! > > > > I'm therefore asking to be removed as the proxy for Synce. Hopefully > > this means it won't die in Gentoo :) > > > > Massive thanks to everyone who helped with my bad ebuild programming and > > testing along the way - volker, mescalinum, ssuominen, the SynCE team > > and everyone else. > > > > The original testing overlay remains here[2] for anyone who wants to > > take it over, just contact the SynCE dev team. > > > > If there are any questions please cc me directly as I may not be on the > > -dev list much more. > > > > [1] http://article.gmane.org/gmane.linux.gentoo.devel/69230 > > [2] https://synce.svn.sourceforge.net/svnroot/synce/dist/gentoo > > > > many thanks! > > np > > We should have all of SynCE in Portage again, except for the GNOME bits > like synce-trayicon (hardcoded depend on sys-apps/hal) and the KDE bits > (haven't even looked). > > Just by pulling synce-sync-engine as well as synce-connector the deps > should get pulled in -> No need for a meta package. > > The overlay was, when I last checked entirely uncompatible with the > packages in tree as well as has confusing amount of deprecated ebuilds. > I would love if someone could wipe it clean so people stop accidentally > shooting themself in the foot with it. > > I'll add the synce-trayicon to tree soon as upstream produces a HAL-free > version of it... > > And it's up the KDE team to add the KDE bits if they want. > Hello, I want to help in sanitizing the overlay and bring the ebuilds into portage. We can see that next weekend if you have the time. Regards, -- Angelo Arrifano (miknix) Developer / GPE maintainer http://www.gentoo.org/~miknix http://miknix.homelinux.com
Re: [gentoo-dev] Please enhance your USE descriptions!
On Ter, 2011-03-29 at 17:08 +0200, Amadeusz Żołnowski wrote: > Excerpts from justin's message of Tue Mar 29 16:24:57 +0200 2011: > > the descriptions of USE flags should explain what the USE is good for. > > In my opinion some thing like > > > > Enables foo intergration > > or > > Enables support for foo > > > > if it isn't totally clear what "foo" is, sucks!! There are many, many > > description which do not tell me as a user without googling what I > > could enable or not. That doesn't make gentoo very user friendly! > > > > So please enhance you descriptions!! > > I 100% agree with you! This is something what is always pissing me off > when reading equery uses foo to find out how to set flags. > > I'm actually describing even global USE flags in my package's > metadata.xml if their purpose might not be clear and I'd like to expect > that from others. It is not a problem to write one sentence for each > flag while you already know what flag does. > > Maybe it should even become our policy and not just recommendation? Why do we have to turn everything into policies? This case would be easily solved by making a list of use flags that we find poorly described, then improving the description of each. - Angelo
Re: [gentoo-dev] rfc: New global USE flag called "ios", not same as "ipod" ?
On Ter, 2011-03-29 at 14:46 +0200, Hanno Böck wrote: > Am Tue, 29 Mar 2011 06:23:04 +0300 > schrieb Samuli Suominen : > > > The magic number is often 5, this is 4 but it's only magic! > > When I hear "ios" I first think of Cisco's IOS rather than Apple's. Is > this an issue? > Yes, it means you were not consumed by Apple madness yet :) Now seriously, people should check use flag descriptions before enabling them so IMHO this is not an issue. - Angelo
Re: [gentoo-dev] rfc: New global USE flag called "ios", not same as "ipod" ?
On Ter, 2011-03-29 at 14:16 +0300, Samuli Suominen wrote: > On 03/29/2011 02:07 PM, Angelo Arrifano wrote: > > On Ter, 2011-03-29 at 06:23 +0300, Samuli Suominen wrote: > >> The magic number is often 5, this is 4 but it's only magic! > >> > >> ios (gnome-base/gvfs): > >> ios (media-libs/libgpod): > >> ios (media-sound/clementine): > >> ios (sys-power/upower): > >> > >> > >> Does this look proper? > >> > >> "Enable imobiledevice support for Apple's iPhone, iPod, and iPad with > >> iOS operating system." > >> > >> Hints from here: > >> > >> http://www.libimobiledevice.org/ > >> http://en.wikipedia.org/wiki/IOS_(Apple) > >> > > > > Not quite. ipod flag usually covers the old iPod versions without iOS. > > The iphone use flag covers some features present on the iPhone and not > > necessarily present on all iPods (with iOS). So yeah, the ios use flag > > makes sense to cover all devices with iOS ipod or iphone. > > > > Regards, > > What do you mean by "Not quite." when you basically confirmed everything > I've said? Sorry, I was answering the question in the email's subject... I also apologize for the double reply, but that is evolution's fault. So yeah, thumbs up for new "ios" use flag.
Re: [gentoo-dev] rfc: New global USE flag called "ios", not same as "ipod" ?
On Ter, 2011-03-29 at 06:23 +0300, Samuli Suominen wrote: > The magic number is often 5, this is 4 but it's only magic! > > ios (gnome-base/gvfs): > ios (media-libs/libgpod): > ios (media-sound/clementine): > ios (sys-power/upower): > > > Does this look proper? > > "Enable imobiledevice support for Apple's iPhone, iPod, and iPad with > iOS operating system." > > Hints from here: > > http://www.libimobiledevice.org/ > http://en.wikipedia.org/wiki/IOS_(Apple) > Not quite. ipod flag usually covers the old iPod versions without iOS. The iphone use flag covers some features present on the iPhone and not necessarily present on all iPods (with iOS). So yeah, the ios use flag makes sense to cover all devices with iOS ipod or iphone. Regards, -- Angelo Arrifano (miknix) Developer / GPE maintainer http://www.gentoo.org/~miknix http://miknix.homelinux.com
Re: [gentoo-dev] rfc: New global USE flag called "ios", not same as "ipod" ?
On Ter, 2011-03-29 at 06:23 +0300, Samuli Suominen wrote: > The magic number is often 5, this is 4 but it's only magic! > > ios (gnome-base/gvfs): > ios (media-libs/libgpod): > ios (media-sound/clementine): > ios (sys-power/upower): > > > Does this look proper? > > "Enable imobiledevice support for Apple's iPhone, iPod, and iPad with > iOS operating system." > > Hints from here: > > http://www.libimobiledevice.org/ > http://en.wikipedia.org/wiki/IOS_(Apple) > Not quite. ipod flag usually covers the old iPod versions without iOS. The iphone use flag covers some features present on the iPhone and not necessarily present on all iPods (with iOS). So yeah, the ios use flag makes sense to cover all devices with iOS ipod or iphone. Regards, -- Angelo Arrifano (miknix) Developer / GPE maintainer http://www.gentoo.org/~miknix http://miknix.homelinux.com
Re: [gentoo-dev] gtk 3 preparation work
On Ter, 2011-03-01 at 13:02 +0530, Nirbheek Chauhan wrote: > On Tue, Mar 1, 2011 at 4:04 AM, Nirbheek Chauhan wrote: > > On Mon, Feb 28, 2011 at 8:28 AM, Donnie Berkholz > > wrote: > >> On 11:13 Sun 27 Feb , Gilles Dartiguelongue wrote: > >>> a quick mail to announce that the gnome team, in order to prepare for > >>> gnome 3, started slotting a lot of gnome team managed packages. If you > >>> find yourself using such a package, please update your ebuilds to use > >>> slot notations or other EAPI compliant notation resulting in the same > >>> effect. > >> > >> This email would be much more useful if it included a list of affected > >> packages, sorted by maintainer and/or herd. > >> > > > > As requested, here is a (probably) complete list of packages which > > depend on x11-libs/gtk+ without a slot. The list was generated using > > the tinderbox rindex, so it may be slightly out of date. > > > > I just realized that there was a bug in my script which caused the > maintainer-sorted list to not group packages together. Attached is an > updated list. > Thanks for the list, things for gpe herd are done. -- Angelo Arrifano (miknix) Developer / GPE maintainer http://www.gentoo.org/~miknix http://miknix.homelinux.com
Re: [gentoo-dev] Re: Re: .la files and their future on Gentoo
On 05-10-2010 13:49, Luca Barbato wrote: > On 10/5/10 9:52 AM, Angelo Arrifano wrote: > >> By removing .la files, you are taking away that choice from the user. >> For you they might be useless, for some user (or entire software house) >> it can be its holly grail for library versioning and linking. I don't >> really feel like forcing users to change their build setups just because >> we think they are useless, do you? >> - It is decisions like this one that *might* give us bad reputation. > > Bluntly put, you seem to not know how libtool exactly works and further > down in the thread how linking exactly works. Please try to learn the > fine Gentoo docs on the subject and feel free to ask more details on irc. > > lu > > I just talked with Samuli and Luca at IRC and indeed there were some issues in my reasoning about libtool's behavior. Applications expecting overlinking to link correctly would be broken anyway due to -Wl,--as-needed . Since all the issues I tried to point will not be verified anyway, I don't see anymore why we can't proceed with the proposal. Moreover, due to my past in fixing .la files to let programs cross-compile correctly I actually welcome this change. So here it is my +1
Re: [gentoo-dev] Re: Re: Re: Re: .la files and their future on Gentoo
On 05-10-2010 13:28, Diego Elio Pettenò wrote: > Il giorno mar, 05/10/2010 alle 13.25 +0200, Diego Elio Pettenò ha > scritto: >> Definitely not from /usr/lib/libGL.la given that libGL is part of mesa >> and mesa did not use libtool for linking until very recently, > > Actually, scratch that, mesa IS NOT USING LIBTOOL AT ALL. > > So you hit the jackpot: you brought up a libtool use case that... does > not use libtool at all! Congratulations! > > Now, can you please let people express _informed_ opinions? > I don't want to interrupt your celebration of winning a war or something. Just want to say that mesa is not the only opengl implementation. The examples I gave work with any other libtool managed library.
Re: [gentoo-dev] Re: Re: Re: .la files and their future on Gentoo
On 05-10-2010 12:03, Diego Elio Pettenò wrote: > Il giorno mar, 05/10/2010 alle 09.52 +0200, Angelo Arrifano ha scritto: >> >> Like Richard said "Gentoo is about choice... >> >> By removing .la files, you are taking away that choice from the user. >> For you they might be useless, for some user (or entire software >> house) >> it can be its holly grail for library versioning and linking. I don't >> really feel like forcing users to change their build setups just >> because >> we think they are useless, do you? >> - It is decisions like this one that *might* give us bad reputation. >> >> Should we also start removing package-config files just because there >> are better ways to detect if a certain package is installed? > > Again, I ask you: how do libtool archive work? What is lost by removing > them? How can any software out there rely on them? You can extract from a .la things like the library name, version and linking information (lib dependencies and paths). The information is there and nothing prevented anyone from using it. > > Can you provide any specific use case, or are you now arguing for > "choice for choice's sake"? There are a lot of packages that need this information to correctly link against libtool managed libraries, for example, there are packages that linked against GL but didn't set -lGL -lGLU because it was relying on libtool to get that information (guess from where?). Things get worse when they also expect libtool to also provide libraries path. There are even packages that expects libtool to provide linker flags for its direct dependencies and flags for the dependencies of its dependencies. For example: foo links with GL (expects libtool to provide -lGL -lGLU) foo also links with the backend of GL (expects libtool to provide -lX11 for example, which is a dependency of GL) In a perfect world everyone would be using pkg-config or whatever, but not. I happen to be bitching about this because I came across some of these when cross-compiling. > > Should we remove /usr/bin/xml2-config? No. Why? Because there are > packages out there not using pkg-config to detect libxml2, upstream > libxml2 provides that explicitly and allows it to be used as such: > > $(CC) $(CFLAGS) $(LDFLAGS) `xml2-config --cflags` foo.c -o foo > `xml2-config --libs` > > Should we remove /usr/lib/libxml2.la? Yes. Why? Because upstream does > not explicitly provide it (it's a byproduct of libtool), and they don't > require/ask to rely on it (otherwise it wouldn't provide pkg-config > or .pc files). > > Again, I'm not arguing over semantics or feelings here, I'm arguing with > facts; can you argue with facts or are you just going to quote Richard > again and propose "choice for choice's sake"? > Mind you that the community is wider than one can imagine. I happen to work in the academia and I know a lot of nasty stuff people do to save time (at least is what they think) for deadlines. As a user, I would hate to have my research program/script broken just because some dev decided to make the distribution I use his personal sandbox. Besides, doesn't this kind of changes belong in upstream and then eventually come to the distros? Why don't you make a patch and send upstream if these libtool files are so useless?
Re: [gentoo-dev] Re: Re: .la files and their future on Gentoo
On 05-10-2010 03:55, Diego Elio Pettenò wrote: > Il giorno lun, 04/10/2010 alle 11.19 -0400, Richard Freeman ha scritto: >> >> That said, supporting this use case should not interfere with more >> mainstream use of the distro. I like the USE flag proposal because it >> lets us have our cake and eat it too. Those who don't need .la files >> don't get them except where absolutely essential, and those who need >> and >> are willing to live with tons of them can have it their way. > > USE flags add complexity, and in real use cases there are near to no > good reasons at all to keep .la files around. Like Richard said "Gentoo is about choice... By removing .la files, you are taking away that choice from the user. For you they might be useless, for some user (or entire software house) it can be its holly grail for library versioning and linking. I don't really feel like forcing users to change their build setups just because we think they are useless, do you? - It is decisions like this one that *might* give us bad reputation. Should we also start removing package-config files just because there are better ways to detect if a certain package is installed? > > I don't want to sound like a douchebag, but can you (or anyone else > supporting the USE flag notion) explain what .la files actually do? You don't sound like a douchebag, just someone who wants to force stuff into others. It happens all the time when we have strong feelings about something or when we think we are totally correct. - But hey, guess what? The world spins around sun after all. > > What I'm quite sure of is that about half the people who express their > opinion regarding .la files have no idea what they are used for, they > expect them to be some kind of magic problem-solving fairy dust. They > are not. Careful.. There is people that might take this as an "attack".. > > They are a legacy of older operating system and static linking notions; > they are also not magical enough as they are only consumed back by > libtool. And not all the packages out there use libtool to link the > final application even if they were to use autotools. > >
Re: [gentoo-dev] .la files and their future on Gentoo
On 03-10-2010 15:29, Luca Barbato wrote: > On 10/03/2010 01:53 PM, David Leverton wrote: >> While I do agree that the underlying problem we're trying to solve is >> worth solving, I do have a couple of small concerns about how it's >> being done. The first is that it seems people are judging whether a >> particular .la file is "needed" by checking whether anything currently >> in the tree needs it, but this doesn't take into account anything that >> /isn't/ in the tree yet. > > I think the simpler solution is that if it needs .la, before reaching > the tree it has to be fixed... Was libtool deprecated or something? Judging by your reply, it really made me think so. The farther we walk from upstream, the greater is the quantity of work we have to do to maintain their packages. > > lu >
Re: [gentoo-dev] .la files and their future on Gentoo
On 03-10-2010 12:53, David Leverton wrote: > On 2 October 2010 20:54, Jorge Manuel B. S. Vicetto > wrote: >> Given the recent activity around .la files and conflict about how to >> deal with them, I propose we discuss this issue in this mailing list, >> and take this issue to the council. >> That way, we can make a global decision, taking into account all the >> arguments for and against, find a balance, opt for a policy, inform >> users and developers about it and move on. > > While I do agree that the underlying problem we're trying to solve is > worth solving, I do have a couple of small concerns about how it's > being done. The first is that it seems people are judging whether a > particular .la file is "needed" by checking whether anything currently > in the tree needs it, but this doesn't take into account anything that > /isn't/ in the tree yet. This is a very good point. However, in the case of out-of-tree packages, I think most "regular" users just use ebuilds from bugzilla (and third party places like forums etc). Users that contribute their cooked ebuilds should know more or less what are doing, so I guess they will have the corresponding packages patched in one way or another, if they require a certain .la file. > The second is that removing .la files > everywhere makes it hard for people to experiment with alternative > solutions, as testing an alternative would require modifying all the > affected ebuilds to stop removing them. (And yes, I am interested in > doing so myself, although time constraints mean it might not > happening.) > > Would it be too much trouble to have a standardised variable that > means .la files should be kept? It maybe /shouldn't/ be exposed as a > USE flag because very few people will need it, but if it's easy to > implement (maybe by having an eutils function to do the removal, > checking the variable first) it would remove any objections I could > imagine. This seems like a very good solution. For example - usually, people building packages manually just want the build process to work. They don't want to spend time making an ebuild or digging around. One being able to simply USE="libtool" emerge foo to restore the foo's .la files would be great. A gentoo page properly indexed in Google and explaining what to do when a libtool library is not found, should take care of most. Another positive point about an .la USE flag is that users are already used to put their USE flags on bugzilla, which should help package maintainers to acknowledge .la related problems. > > As I said, these are minor points, and I wouldn't expect people to go > to great effort to satisfy them. Just something to consider. > Me being one of the persons that initially contributed code to allow portage to fix .la files, I'm indeed happy to see the direction Gentoo is heading. Libtool archives were (and still are for those not using portage) a pain in the ass for cross-compilation. Regards, - Angelo
Re: [gentoo-dev] What the hell is going on here?
On 17-09-2010 17:33, Alex Alexander wrote: > On Fri, Sep 17, 2010 at 03:52:03PM +0100, Markos Chandras wrote: >> On Fri, Sep 17, 2010 at 12:51:52PM +0200, Maciej Mrozowski wrote: >>> On Friday 17 of September 2010 12:41:51 Angelo Arrifano wrote: >>>> Every single QA commit review coming into my Inbox during the past week >>>> was directed to arfrever. I *know* he is on probation, I *know* he made >>>> mistakes - in fact every one makes mistakes. But you guys are hammering >>>> all over him for picky stuff. >>>> >>>> Remind you that while it is a pleasure to be member of Gentoo, we are >>>> not your slaves; we chose to spend our free time contributing to Gentoo >>>> for several reasons - fun, knowledge and team work. Satisfying somebody >>>> else's flavors and wishes is certainly *not* one of them. >>>> >>>> I never had the chance to talk with arfrever, nor I ever looked to his >>>> work at Gentoo. But there is one thing I definitely got right, he has a >>>> lot of motivation to continue in Gentoo and *offer* his time and >>>> knowledge, otherwise he would just raise the middle finger and go away >>>> after all of this bashing. >>> >>> The other important thing is such "lecturing" should probably take place in >>> private, like gentoo-core. >>> >>> -- >>> regards >>> MM >> >> Well, Angelo is quite right for posting in this ML because QA members >> wants anything to be publicly visible. Angelo, I do agree with you. It >> seems like everyone is forcing himself to find mistakes on Arfrevers >> commits even the slightest one. Whilst I do agree that pointing the >> mistakes is a good thing, however I am totally against targeting one >> person just to satisfy our ego. So I you spot a commit mistake and >> report it via the ML make sure you do it again when someone != Arfrever >> do it in the future. >> >> Bye >> >> -- >> Markos Chandras (hwoarang) >> Gentoo Linux Developer >> Web: http://hwoarang.silverarrow.org >> Key ID: 441AC410 >> Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410 > > I don't think ego has anything to do with this. Arfrever brought this on > himself. His [multiple] past mistakes and lack of cooperation are > forcing the other devs to screen all his commits now, to make sure > history doesn't repeat itself. «forcing other devs to screen all his commits now» - like torture and pay-back? That's exactly what I feel it is entirely wrong. It just makes Gentoo look bad. Anyway, I think QA should keep their commit acceptability threshold in the same level for everyone. Of course this is easier to say than to do, we are humans after all, and feelings are always involved. Usually, personal interference is avoided by making the review process blind. That is, the person that commits would remain anonymous during the QA review process, but this is hard to apply in practice. Regards, - Angelo > > Angelo, while I agree with your general thoughts on why everyone is > contributing, I believe you should have gathered more intel before > sending an email like this. We do respect Arfrever's motivation, we just > need to make sure it translates to good, trustworthy work. If we didn't, > his request to return to Gentoo would have been denied. > > Regards,
[gentoo-dev] What the hell is going on here?
Every single QA commit review coming into my Inbox during the past week was directed to arfrever. I *know* he is on probation, I *know* he made mistakes - in fact every one makes mistakes. But you guys are hammering all over him for picky stuff. Remind you that while it is a pleasure to be member of Gentoo, we are not your slaves; we chose to spend our free time contributing to Gentoo for several reasons - fun, knowledge and team work. Satisfying somebody else's flavors and wishes is certainly *not* one of them. I never had the chance to talk with arfrever, nor I ever looked to his work at Gentoo. But there is one thing I definitely got right, he has a lot of motivation to continue in Gentoo and *offer* his time and knowledge, otherwise he would just raise the middle finger and go away after all of this bashing. Best regards, -- Angelo Arrifano AKA MiKNiX Gentoo Embedded developer GPE maintainer http://www.gentoo.org/~miknix http://miknix.homelinux.com
Re: [gentoo-dev] Improve devaway system
On 31-08-2010 10:03, Robin H. Johnson wrote:
> On Mon, Aug 30, 2010 at 11:13:15PM +0200, Michael Weber wrote:
>> Hello fellow developers.
>>
>> On 08/30/2010 04:20 PM, Dirkjan Ochtman wrote:
>>> Sounds good to me, but I'd actually be more interested in having
>>> something the other way around; i.e. monitoring for activity in
>>> commits, bugzilla, IRC and maybe the -dev mailing list to see if
>>> people are still active and send them a message to encourage them to
>>> set devaway if they haven't been active in, say, 15 days.
>>
>> I think the intention was to force actually active developers to
>> remove their out-of-date .away message, which isn't very representative
>> for the project.
> .away age statistics, as of right now (2010/08/31, 07:27 UTC).
> - 53 developers with .away files.
> - Oldest: 2007/Mar/01 (1278.8 days old).
> - Mean: 153 days old.
> - Median: 55.5 days.
> - First, Third quartiles: 23.3, 136.5 days.
>
> What do the numbers mean? My opinion looking at them is that MOST
> developers are using the .away system correctly, however some developers
> just have forgotten to remove old .away files (they claimed they would
> be back by a date, and commits started up after that).
>
> I'll fully admit that I neglected to remove my last .away until I
> double-checked earlier today.
Yes, it was my case also. I thought I removed it though, but it was just
my memory playing tricks.
Thanks for raising the thread :)
>
> How about this as an idea:
> 1. Include a parsaable return date I suggest ("Returning:/MM/DD",
> "Returning:Unknown")
> 2. Automated emails when:
> 2.1. It's after the return date (weekly).
> 2.2. You start committing again.
>
Notifying about the away state when you commit, sounds great.
Re: [gentoo-dev] Tone in Gentoo
On 19-06-2010 05:20, Jorge Manuel B. S. Vicetto wrote: > On 19-06-2010 02:25, Sebastian Pipping wrote: >> Hello. > >> As some people seem to be interested in examples of out of the line tone >> in Gentoo I feel like sharing an example just happened a few minutes ago: > >> In #gentoo-infra people are talking about banging each others moms >> right now. I was told this is normal in there. As I mentioned it's >> not funny at all I was told that it's not funny to _me_ and that I >> don't have to hang around there if I don't like it. > >> Now that's tone in Gentoo. Brilliant. > > Sebastian, > > you're confusing talk and jokes between developers on a particular > private room with tone between members of the global community in public > mediums. I corroborate Jorge, I usually (or used to when there was time) hang there and #gentoo-infra is like a big family. While I agree there is sometimes a certain tone in gentoo, #gentoo-infra is for sure *not* an example. - Angelo > You're also missing an important point that some channels have their own > environment and so one should start by understanding it. Furthermore, > pushing for change and or imposing one's view on an established channel > is not a "nice" way to deal with the residents of that channel. > Another thing you've just done and should be aware of, is that you chose > to air into the public private conservations. When any Gentoo developer > decides to reveal a private discussion in the core ml or some other > private medium into the general public without the other parties > knowledge and or consent, that developer is abusing the other members' > "trust". > > You have shown to be very attached to this topic, so much so that you've > just blown this completely out of proportion. There was no "foul play" > intended in that conservation nor was there any abusive tone between the > involved parties. It may have sounded that way to you, but there was no > doubt for the involved parties. > Please consider that some of the developers in this distribution have > known each other for years and have their own communication code and > style. Don't be too quick judging the other people and as others have > said in this thread, assume others to have the best possible intention > in their messages, until proven otherwise. > >> Good night. > > Good night. > >> Sebastian > >
Re: [gentoo-dev] Adding AdobeFlash-10{,.1} licenses to EULA group
On 18-06-2010 12:16, Alec Warner wrote: > On Fri, Jun 18, 2010 at 2:08 AM, Lars Wendler wrote: >> Am Freitag 18 Juni 2010, 03:42:29 schrieb Brian Harring: >>> On Thu, Jun 17, 2010 at 05:14:16PM -0500, Dale wrote: >>>> Lars Wendler wrote: >>>>> Am Mittwoch 16 Juni 2010, 14:45:21 schrieb Angelo Arrifano: >>>>>> On 16-06-2010 14:40, Jim Ramsay wrote: >>>>>>> Chí-Thanh Christopher Nguyễn wrote: >>>>>>>> One notable section is 7.6 in which Adobe reserves the right to >>>>>>>> download and install additional Content Protection software on the >>>>>>>> user's PC. >>>>>>> >>>>>>> Not like anyone will actually *read* the license before adding it to >>>>>>> their accept group, but if they did this would indeed be an important >>>>>>> thing of which users should be aware. >>>>>> >>>>>> I defend it is our job to warn users about this kind of details. To me >>>>>> it sounds that a einfo at post-build phase would do the job, what do >>>>>> you guys think? >>>>> >>>>> Definitely yes! This is a very dangerous snippet in Adobe's license >>>>> which should be pretty clearly pointed at to every user. >>>> >>>> Could that also include a alternative to adobe? If there is one. >>> >>> The place to advocate free alternatives (or upstreams that are >>> nonsuck) isn't in einfo messages in ebuilds, it's on folks blogs or at >>> best in metadata.xml... einfo should be "this is the things to watch >>> for in using this/setting it up" not "these guys are evil, use one of >>> the free alternatives!". Why? You are running a free and opensource operating system, what's wrong suggesting *other* free and opensource alternatives? You are just providing the user a choice, not to actually oblige him to install anything. Also, I'm pretty sure seeing nvidia-drivers suggesting the use of the kernel driver when using the hardened profile. >> >> Maybe I expressed myself a bit misinterpretative. I don't want to request an >> elog message telling users about alternative packages. But in my opinion an >> elog message pointing at the bald-faced parts of Adobe's license should be >> added. These parts about allowing Adobe to install further content protection >> software is just too dangerous in my opinion. > > I will ignore the technical portion where basically any binary on your > system; even binaries you compiled yourself have the ability to > 'install things you do not like' when run as root (and sometimes when > run as a normal user as well.) For all the years running Linux, I never found that case. > > The real meat here is that you want Gentoo to take some kind of stand > on particular licensing terms. I don't think this is a good > precedent[0] to set for our users. It presumes we will essentially > read the license in its entirety and inform users of the parts that we > think are 'scary.'[1] The user is the person who is installing and > running the software. The user is the person who should be reading > and agreeing with any licensing terms lest they find the teams > unappealing. I don't find it unreasonable to implement a tool as > Duncan suggested because it is not a judgement but a statement of > fact. "The license for app/foo has changed from X to Y. You should > review the changes accordingly by running " I'm the person who initially proposed warning users on elog. The initial proposal only states about: 1) A warning about change of licensing terms. 2) A warning that "additional Content Protection software" might be installed without users consent. In fact, portage already warns the users about bad coding practices, install of executables with runtime text relocations, etc.. How is this different? If me, as a user, didn't know about such detail (who reads software license agreements anyway?) and someday I hypothetically find a executable running without my permission as my user account and I'm able to associate it with Adobe's flash, I would be pissed off to no extent. And guess what? First thing I would *blame* is flash maintainers. I expect package maintainers to be more familiar with the packages they maintain than me. As consequence, I expect them to advice me about non-obvious details on those packages. At least that's what I try to do on the packages I maintain. GNU/Linux is all about choice. Stating, during install, that a package might later install additional
Re: [gentoo-dev] Tone in Gentoo
On 17-06-2010 12:17, Ciaran McCreesh wrote: > On Thu, 17 Jun 2010 12:08:05 +0200 > Angelo Arrifano wrote: I had some text written here. Why did you just remove it like this? Next time, please write some kind of marker "(...)" to tell you did crop some text. >> That choice can be to join the Gentoo community, or leave it. > > The choice can be to use Gentoo, or not use Gentoo. > > If using Gentoo means being required to use bugzilla, the mailing > lists, forums and IRC, then Gentoo has huge scalability problems. I believe using Gentoo means reading the handbook, read forums, bugs and learn from them.. That's what I felt when I read the Gentoo philosophy for the first time. > Providing one on one support takes an awful lot of manpower; the goal > should be to improve the distribution so that most people don't > encounter many bugs and can get all the support they need from the > documentation. Are we trying to make Gentoo some kind of ubuntu? > > Thus things like GLEP 42 news items: they're a way of avoiding having > thousands of users running to get support because they don't know what > to do when a large change happens. If you think the community's the > important part, you'd do the opposite: you'd not provide upfront > instructions, and would instead see big changes as an opportunity to > persuade more users to participate in the community by trying to help > each other. > - Angelo, PS: I'm exceeding my email bulk-reply quotas for today. I don't want to flood the mailing list so I'll step back and leave other people express their opinion.
Re: [gentoo-dev] Tone in Gentoo
On 17-06-2010 12:08, Ciaran McCreesh wrote: > On Thu, 17 Jun 2010 11:58:21 +0200 > Auke Booij wrote: >> Wouldn't you agree that unless you're a genius who can understand the >> entire system upfront with just the bit of documentation out there, >> the support given, in this case by the community, is part of the >> product? > > No. The community is what you fall back on when the product (of which > the documentation is an important part) fails. > > The goal of the community should be to improve the product, not to > perpetuate itself. > Sounds like we need to nuke our forums (oh wait..), nuke our IRC channels and create a direct phone line for end-user support. - Angelo
Re: [gentoo-dev] Tone in Gentoo
On 17-06-2010 12:08, Angelo Arrifano wrote: > On 17-06-2010 11:51, Ciaran McCreesh wrote: >> On Thu, 17 Jun 2010 02:32:51 +0200 >> Sebastian Pipping wrote: >>> I wouldn't feel to bad if Gentoo is widely recognized as the >>> distribution with the most friendly community around in 2011. >> >> Wouldn't you rather it be recognised as the distribution with the best >> product? >> > > When I read that, the first question that was raised on me was: > - The best product for what, whom? > We can't simply put all possible Gentoo applications and users in one bag. > > Is it really good to think on Gentoo as a product? Can we do like Apple > and treat our users like crap while still making them use our product? > *No!* > Unless we provide locking, GNU/Linux users will always have a choice. > That choice can be to join the Gentoo community, or leave it. > > - Angelo > I apologize for replying to self but I felt we should all remember *what is Gentoo*. Or at least what it used to be.. http://www.gentoo.org/main/en/about.xml "What is Gentoo? Gentoo is a free operating system based on either Linux or FreeBSD that can be automatically optimized and customized for just about any application or need. Extreme configurability, performance and a top-notch user and developer community are all hallmarks of the Gentoo experience. (...) *Of course, Gentoo is more than just the software it provides. It is a community built around a distribution* which is driven by more than 300 developers and thousands of users. The distribution project provides the means for the users to enjoy Gentoo: documentation, infrastructure (mailinglists, site, forums ...), release engineering, software porting, quality assurance, security followup, hardening and more. "
Re: [gentoo-dev] Tone in Gentoo
On 17-06-2010 11:51, Ciaran McCreesh wrote: > On Thu, 17 Jun 2010 02:32:51 +0200 > Sebastian Pipping wrote: >> I wouldn't feel to bad if Gentoo is widely recognized as the >> distribution with the most friendly community around in 2011. > > Wouldn't you rather it be recognised as the distribution with the best > product? > When I read that, the first question that was raised on me was: - The best product for what, whom? We can't simply put all possible Gentoo applications and users in one bag. Is it really good to think on Gentoo as a product? Can we do like Apple and treat our users like crap while still making them use our product? *No!* Unless we provide locking, GNU/Linux users will always have a choice. That choice can be to join the Gentoo community, or leave it. - Angelo
Re: [gentoo-dev] Tone in Gentoo
On 16-06-2010 18:39, "Paweł Hajdan, Jr." wrote: > On 6/16/10 5:33 AM, Sebastian Pipping wrote: >> As I have heard there are people not joining Gentoo because the >> atmosphere in Gentoo is lacking respect and empathy. You are not the only one hearing that. If we jump over our own fences, that will be much more visible. > > This is really sad. And the kind of people who value that often make > good developers if they also have good technical skills. > >> I have searched a few places for rules on tone, > > I believe one can't solve this problem by using rules. > >> - With these Code of Conduct rules in place how come DevRel >>is not publicly reminding of these rules where necessary? > > I think the initiative is on the offended person's side. If a developer > is being aggressive and needlessly argumentative towards other people, > that's clearly a misconduct. Similarly for aggressive users. > >> Could it be we expect perfection from each other instead seeking to >> understand and complement each other? > > That might be a part of it. > >> What can we do to make Gentoo a friendlier community? > > We need leadership. I remember very well when the leader of one of the > Gentoo projects I participate in reminded me to always say "thanks" to > people who are helping us on Bugzilla. A small thing, but wasn't he right? Damn right. Motivation is something that is very easy to lose. If we developers don't show users that we appreciate their contributions (even when we don't), we risk losing potential contributions in the future. I've seen some bugs [sorry no references right now] where some developers point out facts in a *very* aggressive way. Even when what they have to say is true, they will scare away people. Is this what we want? I understand there are a lot of factors that leads into a aggressive response: private life, karma, the persistence of people doing things *wrong*, etc.. we are humans after all. But if such behavior is the rule instead of the exception, then I believe something is wrong and devrel should be brought into attention. - Angelo > > I believe it's the project leaders and the Council who ultimately set > the tone. > > Paweł >
Re: [gentoo-dev] Adding AdobeFlash-10{,.1} licenses to EULA group
On 16-06-2010 14:40, Jim Ramsay wrote: > Chí-Thanh Christopher Nguyễn wrote: >> I propose that this license be added to the EULA group. The previous >> AdobeFlash-10 license is similar in this regard, and could possibly >> also be added to that group. > > Agreed, on both points, and done. Thanks for finding and airing this > issue! > >> One notable section is 7.6 in which Adobe reserves the right to >> download and install additional Content Protection software on the >> user's PC. > > Not like anyone will actually *read* the license before adding it to > their accept group, but if they did this would indeed be an important > thing of which users should be aware. > I defend it is our job to warn users about this kind of details. To me it sounds that a einfo at post-build phase would do the job, what do you guys think?
Re: [gentoo-dev] Re: [RFC][NEW] Utility to find orphaned files
On 03-05-2010 15:34, Peter Hjalmarsson wrote: > fre 2010-04-30 klockan 18:24 +0200 skrev Enrico Weigelt: >> * Daniel Pielmeier schrieb: >> >>> What about searching the complete file system but using an exclude file >>> where >>> you can put directories and files which should not be searched. It is >>> tedious to >>> tell every path on the command-line. Also for instance if you specify /lib >>> it >>> will also search under /lib/modules and I am sure you do not consider all >>> contents there as unneeded. >> >> hmm, perhaps there's some way to assign these files to some package ? >> > > Eh, no and it should not be since files in that directory is kernel > modules, and most of the files there is created by "cd /usr/src/linux && > make" or genkernel or something alike and it is supposed to be that way. Indeed. /lib/firmware is another candidate > Looking at the contents of that directory is pretty easy to see if a > directory there should be left alone or removed (as there is just one > directory per kernel. not any longer running a kernel anymore? remove > the corresponding dir). That is dangerous. For example, I always keep the previous 2 kernels just in case I detect some problem with the latest and I need to quickly go back. > It is better to have the script not tuch that directory at all or at > most point out "the directory contains directories for more kernels then > the currently running (i.e. there is more then one dir) and it is > totally THIS big. Sounds like a plan. You may want to take a look if you have files from > older kernels that you do not longer need." > That would leave up to the user to figure out what kernel modules to > keep and what kernel to pount. Or you suggest autocleaning of /boot > and /usr/src/linux-* as well? Dangerous! > > > I'm seeing that there is enough interest (including me) on such utility. Since it is difficult to please everyone at start, I'll first open a project page on sf.net and develop a more powerful PoC that matches my ideas. There was a lot of good ideas and observations here, so keep them coming that I'll certainly read them. When, and only if, the thing grows to a more mature state; I'll try to open a Gentoo project by the appropriate means. I'm not very good on free time lately, so I can't promise anything. But, as long as my interest on it doesn't die I'll slowly keep working on. Regards, - Angelo
Re: [gentoo-dev] [RFC][NEW] Utility to find orphaned files
On 25-04-2010 17:34, Yuri Vasilevski wrote: > Hello, > > On Sun, 25 Apr 2010 13:18:25 +0200 > Angelo Arrifano wrote: > >> Hello developers developers and developers, >> >> Ever wondered how much crap is left in your X-years old Gentoo box? >> >> I just developed a python utility to efficiently find orphaned files >> in the system. By orphaned files I mean the files that are present on >> system directories and don't belong to any installed package. >> >> The package builds a virtual filesystem (cache) on the RAM using >> python hash tables. Then it uses the cache to find the ownership of >> files inside user-specified dirs. >> >> Building the cache takes less than 10 seconds here in a system with >> 1366 installed packages. >> >> This is not intended to be a finished program yet, I'm looking forward >> for your constructive commentaries. > > There is a tool that does that, qfile from app-portage/portage-utils. > Check the "-o, --orphans* List orphan files" option. > > It's not as straight forward as it could be, as it checks only for > files specified as arguments or read from file. > > But you can trivially use it like: > # find /dir/you/want/to/check/for/orphans | qfile -o -f - > > Best, > Yuri. > Based on the comments so far, I'll try to make my PoC a better tool. My primary objective is to make this some kind of disk cleanup utility for Gentoo boxens. I don't expect Gentoo systems to be *that* polluted but sometimes we all have to do ugly things to fix broken systems real fast. - If you know what I mean. There are other things that came to my mind, like using stored hashes to check the system files integrity (as in security). My next steps in regard to this utility will be: * Follow harring suggestion and use available PM API. * Make the application handle symlinks so we start getting a more informative output. * To store the generated cache on disk and to only regenerate it if needed. Regards, - Angelo
[gentoo-dev] [RFC][NEW] Utility to find orphaned files
Hello developers developers and developers, Ever wondered how much crap is left in your X-years old Gentoo box? I just developed a python utility to efficiently find orphaned files in the system. By orphaned files I mean the files that are present on system directories and don't belong to any installed package. The package builds a virtual filesystem (cache) on the RAM using python hash tables. Then it uses the cache to find the ownership of files inside user-specified dirs. Building the cache takes less than 10 seconds here in a system with 1366 installed packages. This is not intended to be a finished program yet, I'm looking forward for your constructive commentaries. [Attached] Regards, -- Angelo Arrifano AKA MiKNiX Gentoo Embedded/OMAP850 Developer Linwizard Developer http://www.gentoo.org/~miknix http://miknix.homelinux.com find-orphaned-0.01.tar.bz2 Description: application/bzip
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On 13-04-2010 18:12, Matti Bickel wrote: > Nirbheek Chauhan wrote: >> From my PoV, editing ChangeLog is like editing history. Complete no-no. > > It is possible in all major SCMs for a reason. And I (as a user) would > laugh at Changelog entries saying "um, I got that bug number wrong, it > is really #1234". If I (as a developer) log such edits, I'm wasting my > users time. > > So I'll continue to edit and commit Changelogs without additional notice. > Can't we just create a commit hook that appends the bug summary as a comment if a #X bug string is present on the commit log? Something like: - - Foobar commit Description bl a bla bla # bug 1234: Show summary for those that don't double check the bug # number. # # Other git crap that usually appears at end of log # ... - -
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On 13-04-2010 13:25, Peter Volkov wrote: > В Втр, 06/04/2010 в 07:43 +0530, Nirbheek Chauhan пишет: >> * It makes zero sense to manually manage ChangeLogs in git[1] > > Once I had stupid cut&paste mistake and entered wrong credits in > ChangeLog. I don't see how to resolve this issue in case ChangeLog's > will be generated from git log and until somebody suggests how to edit > ChangeLogs generated from git I think have to keep ChangeLogs in > gentoo-x86. > If in kernel.org they don't seem to need to edit changelogs, why would we? Between all of us developers, how many needed to change a ChangeLog after commit? I guess we would be pretty low in number. And lets not forget that we can --amend commits (log included) until we push them to origin. - Angelo
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On 07-04-2010 00:21, Robin H. Johnson wrote: > On Tue, Apr 06, 2010 at 09:06:24AM -0400, Richard Freeman wrote: >> Why not just get rid of the in-tree Changelogs entirely? The scm >> logs already document this information, so why have it in a file? > The major concern with this is users that are NOT connected to the > internet always. > If you are connected, you can just use --exclude Changelog in your rsync > options. > That's a good point. But can't we generate the ChangeLogs automatically from git on the main rsync server?
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
First, I've been using git to hack Linux for some embedded devices. My development was in sync with upstream linux-omap to which I sent several patches. So, consider yourself that I have some experience with git. On 06-04-2010 08:41, Fabian Groffen wrote: > On 06-04-2010 07:43:02 +0530, Nirbheek Chauhan wrote: >> * It makes zero sense to manually manage ChangeLogs in git[1] >> - Irritating conflicts while merging branches or remote master >> + Similar argument for having only distfile manifests; but I digress... >> - Duplication of effort and information >> - Saves space for local checkouts > > This seems to assume > a) that we will do branches, and > b) that those branches somehow are official and in use > > In CVS we are not allowed to use branches, as a policy, that somehow > makes sense. Our stable tree is visible via keywords instead. > > Why would we suddenly do branches? It still isn't a good thing. If you > talk about branches in the sense of a clone of the entire repo, why > would we suddenly do massive concurrent development on the same ebuilds? IMHO repository branching would be greatly useful on Gentoo portage, specially for third-party and other Gentoo-based distros. It will be a lot easier for them to keep their own changes to ebuilds while in sync with main Gentoo tree. This is a big win for everyone. With my experience in Gentoo-embedded I can also present a problem where branching is extremely useful: 1) Package foobar-1.2 is in the tree and keyworded only for ~x86 ~amd64. 2) Some dev at -embedded decides that package is useful and applies his traditional cross-compile hackery. 3) The usual route would be to open a shi*load of bugs, wait a cr*pload of time for the maintainer response and if the weather feels like it, there is authorization to commit. Then there is also need to retest for already keyworded arches so we know we don't break others. 3*) With git, one would just branch (lets call it embedded branch) the package. Apply the patches there and let people using embedded profiles to emerge from that branch instead of master. Benefits? I think they are pretty obvious - people can start putting quick patches in the tree for specific arches while not breaking others. IMHO, the only bottleneck I see on Gentoo development is the massive policy (not saying it is not needed) a -dev has to follow just to commit a simple fix. Git my friends, will be our holly grail. > > I can tell you from good experience that you only do such things if you > really have to, e.g. when you are in an overlay that needs to have > modifications to nearly everything and you try to keep that overlay > up-to-date with its origin, gentoo-x86. It's no fun, because it > conflicts pretty much on lots of things, not ChangeLogs. > > It seems to me, that if you are in a clone working on something, you > just only write the ChangeLog once you merge it with its origin, > gentoo-x86. You have to review what happened at that stage anyway. > > If you really have lots of changes, you will find that many commits on > the other side will cause you conflicts, so the ChangeLog is just a very > small part of it. Conclusion, if you can, try hard to keep your changes > minimal, and preferably zero compared to the origin, gentoo-x86. > > I don't know why but people seem to have eternal scarring to merge conflicts. Yes, they happen and yes they are trivial to fix if people don't commit crap that touches a lot of stuff. In portage, the tree is very well organized and with some good policies like restricting each commit to one package will pretty much prevent conflicts. I will not comment on if Changelogs are going to give conflicts or not. That would be best answered by the people that is running portage git for some time.
Re: [gentoo-dev] bug-wranglers queue is large
On 23-03-2010 19:15, Jeremy Olexa wrote: > > Given that the b-w queue is over 200 bugs and some have not been wrangled > for 3 weeks... > > Could everyone spend 5 minutes wrangling 5 bugs? (or more if you are > willing :) > > Thanks, > Jeremy > I'm going to grab this one and ask how is Gentoo going in terms of fresh souls. I understand the recruiting process is slow and the recruiters are understaffed. But I imagine somehow that there is less people joining us now a days compared to a few years.. I'm currently guiding a friend to potentially join Gentoo in the future. My plan is first to prepare him for Arch Testing, since it was also my entry point on Gentoo. I would like to hear your experience and ideas how to successfully guide people towards Gentoo development. Regards, - Angelo
Re: [gentoo-dev] [RFC]: Proxy-maintainer project
On 18-03-2010 18:24, Sébastien Fabbro wrote: > On Thursday 18 March, Markos Chandras wrote: > >> 1) Should we use a new overlay? A new branch on sunrise? or work >> ebuilds in Gentoo bugzilla?I think the latter is the best >> 2) I think an email alias is not needed We can "monitor" >> maintainer-wanted/- needed alias if needed. What do you think? >> 3) Maybe a new KEYWORD needs to be added on bugzilla so ppl get >> informed that the specific bug is already taking by another developer >> and that somebody is working on it. So marking a bug with a keyword >> e.g. "PROXY" might be useful. > > 0) Switch portage cvs tree to multiple git ones. +1 This is exactly the case where the use of repository branching makes sense. - Angelo > > Sebastien >
Re: [gentoo-dev] [RFC] ebuild function to show package changelog
On Sex, 2010-03-12 at 17:59 +0100, Matti Bickel wrote: > Angelo Arrifano wrote: > > What do you people think on a new pkg_changelog function that would > > instruct the ebuild how to retrieve this kind of information from the > > package? > > No, please don't. I'm okay with it if your mean "at the end of > emerge -u ", but wouldn't it be pointless to see what changed > *after* you just installed the thing? Not pointless. If people don't read package changelogs/releasenotes, then it is highly probable they miss new features in the packages. > > The reason i'm against it is the complexity involved. You need to pull > down the source (up to hunderts of megabytes for openoffice), run > src_unpack and eventually src_configure phases. Then you need to know > where to look and what to show. A ChangeLog in the root of the source dir. is almost mandatory in autotools distributions. Despite the existence of a somewhat standard format for ChangeLogs, it is not enforced leaving the need to parse all the crap they through at us. > > But i agree it's cool to know what i will gain from my daily emerge run. > > As an alternative, let the ebuild provide a variable that points to > upstreams online Changelog or something, so you as a human can go parse > it yourself. But then you could also just take the HOMEPAGE variable > that's already there. > As Jeremy pointed out: "There is an optional tag in metadata.xml." That really looks like a better solution and it is something I might start putting on the packages I maintain. -- Angelo Arrifano AKA MiKNiX Gentoo Embedded/OMAP850 Developer Linwizard Developer http://www.gentoo.org/~miknix http://miknix.homelinux.com
Re: [gentoo-dev] [RFC] ebuild function to show package changelog
On Sex, 2010-03-12 at 09:33 -0600, William Hubbs wrote: > On Fri, Mar 12, 2010 at 04:16:05PM +0100, Angelo Arrifano wrote: > > Hello all, > > > > [Speaking as user] I find myself many times stumbling through package > > ChangeLogs to see what is new/changed after a emerge -u world. As some > > of you might agree, this is time consuming. > > > > What do you people think on a new pkg_changelog function that would > > instruct the ebuild how to retrieve this kind of information from the > > package? Most of packages have a somewhat standard place for it in the > > source tree, so I guess a default pkg_changelog function could, in > > theory, be implemented. > > > > This function could be then called at user request by means of e.g. > > emerge --showchangelog or at the end of emerge update (controlled > > through a FEATURES="show-changelog" or something). > > Actually there is already an option for emerge to show the changelogs > of packages that will be upgraded. Take a look at the --changelog > option for emerge. It can be used along with --pretend to show you the > changelogs of packages that will be upgraded. For a moment, you really tricked me into believing I've been missing this feature. Specially by reading man emerge: "This will show the ChangeLog entries for all the packages" btw: shouldn't it read "ebuilds" here? /\ What I meant originally was to show the ChangeLog of the package (ChangeLog inside source tree), not the ebuild ChangeLog. > > Thanks, > > William > Regards, -- Angelo Arrifano AKA MiKNiX Gentoo Embedded/OMAP850 Developer Linwizard Developer http://www.gentoo.org/~miknix http://miknix.homelinux.com
[gentoo-dev] [RFC] ebuild function to show package changelog
Hello all, [Speaking as user] I find myself many times stumbling through package ChangeLogs to see what is new/changed after a emerge -u world. As some of you might agree, this is time consuming. What do you people think on a new pkg_changelog function that would instruct the ebuild how to retrieve this kind of information from the package? Most of packages have a somewhat standard place for it in the source tree, so I guess a default pkg_changelog function could, in theory, be implemented. This function could be then called at user request by means of e.g. emerge --showchangelog or at the end of emerge update (controlled through a FEATURES="show-changelog" or something). I know we are all busy with a lot of things and I know what Gentoo don't really need right now is more cruft in the ebuilds (just think on QA!). Regards, -- Angelo Arrifano AKA MiKNiX Gentoo Embedded/OMAP850 Developer Linwizard Developer http://www.gentoo.org/~miknix http://miknix.homelinux.com
Re: [gentoo-dev] Low hanging bug fruit patterns
On Seg, 2010-03-08 at 11:06 +0100, Sebastian Pipping wrote: > Hello! > > > There are a few patterns for potentially low hanging fruits among Gentoo > bugs: > > SRC_URI errors > Missing depencies > ... > > What else? > > Anything you look after repeatedly that doesn't "take days" to get it fixed? > > > > Sebastian > * Missing/crappy ebuild USE flag description on metadata. That is something, I think, that always help users. There is nothing worse than rebuilding a entire package just because the USE flag purpose was not what we think it was. Regards, -- Angelo Arrifano AKA MiKNiX Gentoo Embedded/OMAP850 Developer Linwizard Developer http://www.gentoo.org/~miknix http://miknix.homelinux.com
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On Sex, 2010-03-05 at 19:03 +0100, Dawid Węgliński wrote: > On Friday 05 March 2010 17:12:23 Roy Bamford wrote: > > > > > That's not a new install as per the handbook. Neither are you a new > > user as you have a premade make.conf and world file and some experience > > with Gentoo. > > > > Put yourself in the place of a brand new Gentoo user doing his/her > > first install. > > > > It needs to just work out of the box, one way or another, without > > forums posts or calls for help in #gentoo about circular dependences. > > That's not just cups - thats all circular dependencies. > > Brand new gentoo user goes throu handbook -> reads "set up USE variables in > make.conf" and does it according to his/her needs following use.*.desc. If > gentoo was new to me i *would* enter cups as i use printers often at work. > +1 Most people trying Gentoo already had some history with other Linux distros. So, I'm sure they will recognize the cups USE flag when they see it. Most everyone I know also have a printer (some with a pile of dust on it) so I think most of people will enable that USE flag anyway. -- Angelo Arrifano AKA MiKNiX Gentoo Embedded/OMAP850 Developer Linwizard Developer http://www.gentoo.org/~miknix http://miknix.homelinux.com
Re: [gentoo-dev] openrc stabilization todo
On Qui, 2009-12-03 at 15:06 +0100, Rémi Cardona wrote: > Le 03/12/2009 02:22, Jeremy Olexa a écrit : > > Can parallel init script startup be made the default yet? I've been > > running with it for months and never noticed a problem.. > > I've been running it for more than a year on half a dozen boxes, without > any issues as well. > > +1 for making it the default. > > Thanks > I just migrated my laptop to openrc-0.5.2-r2 along with baselayout-2.0.1 and sysvinit-2.87-r1 . [as user] Everything went smoothly and without problems. I spotted two things during boot though: * Autoloaded 0 module(s) * device-mapper uses addon code which is deprecated * and may not be available in the future. and * Adding routes * 127.0.0.0/8 via 127.0.0.1... * Adding static routes... SIOCADDRT: Network is unreachable Looking at the routing table we have: Destination Gateway Genmask Flags Metric Ref Use Iface 127.0.0.0 - 255.0.0.0 ! 0 - 0 - 127.0.0.0 127.0.0.1 255.0.0.0 UG0 0 0 lo Why do we need a reject route for 127.0.0.0? Packets with destination 127.0.0.0 going through interfaces other than lo aren't dropped anyway? Does the loopback interface need a gateway set? Regards, -- Angelo Arrifano AKA MiKNiX Gentoo Embedded/OMAP850 Developer Linwizard Developer http://www.gentoo.org/~miknix http://miknix.homelinux.com
Re: [gentoo-dev] Re: DistroWatch and Gentoo packages: status quo and future
Duncan wrote: > Sebastian Pipping posted on Sun, 13 Sep 2009 22:00:03 +0200 as excerpted: > >> Duncan wrote: >>> [L]et's get some context here. layman's no difficulty at all, really, >>> when compared to the ordinary stuff we expect Gentoo users to do all >>> the time. >> I think you forget about the learning curve: Gentoo users are not born >> as Gentoo users. They are coming from other distros (say Debian or >> Ubuntu). > > Not forgetting that, but perhaps forgetting how "unordinary" my own > experience was. I came from Mandrake, but researched Gentoo well enough > that I was already explaining portage basics based on the material in the > Handbook, etc, on the user list (and reading the dev list), before I even > had Gentoo installed. My first distro was also Mandrake. I eventually moved endlessly between Red Hat (before forking into Fedora) and Mandrake. The reason was the broken rpm package manager (and repo) which had a peculiar way of naming library .so names which interfered with my "hand-built" packages. I found Gentoo when a friend of mine told me there was a distro which was capable of producing CPU *optimized* code because all the packages were built from source. At the time (6~7 years ago?), I didn't have idea such distro could exist but that idea made sense and was left hard-coded in my head. That is when I read the *Gentoo philosophy* page (yes, there is people that reads it) and immediately got in love with it. That was Gentoo's biggest selling point for me. Then the handbook followed and you can probably guess the rest of the story. > > I like to think that if I can do it, everybody can, but regardless of > whether they /can/ or not, it's a fact that not everybody /does/, as > demonstrated by the fact that people were asking the questions I was > answering. I think it is not a matter of capable of doing it or not but rather matching one's needs. It is also a fact that most people *don't get it* when it comes to the question *why gentoo*. > > I /do/ sometimes forget /that/ end of it, that for whatever reason, not > everybody chooses to read the handbook, etc, even if it's ultimately only > making the job of sysadmining their own Gentoo boxen an order of > magnitude harder than it should be. > >> For me it was unmasking that confused me a lot in the beginning. There >> is three different kinds, one is not in "the books" afaik and it's no >> fun to me to do. I guess without autounmask by now I would be so >> frustrated to not use Gentoo anymore. The most confusing stuff for me was to learn all the GNU/Linux basics that I had as granted while using other distros. (...) Just my 2 cents about what mattered to *me* (and still matters) when I moved to Gentoo. -- Angelo Arrifano AKA MiKNiX Gentoo Embedded/OMAP850 Developer Linwizard Developer http://www.gentoo.org/~miknix http://miknix.homelinux.com
[gentoo-dev] gpe-games: new category
Hello all, I have the following packages that need a home in the portage tree: gpe-go gpe-julia gpe-life gpe-lights gpe-othello gpe-tetris gsoko xdemineur They are only a few and they won't increase much in the future. For this reason I'm reticent in creating the gpe-games category in the portage tree as we currently have in the overlay. However, I find useful for users to have this category created since it would allow them quickly spotting another place for games (these games are targeted to -embedded but work on desktop too) while still providing the information that they belong to GPE. Moving each game to the games- category would be another solution but that would pretty much hide the relation with the GPE Palm Environment. There is of course another solution, like moving everything into gpe-base or gpe-utils and STFU. So fellow devs, I'm evoking your experience powers to help me with this oh-not-so-important decision. PS: Please but please, just don't tell me that adding another category will make a longer "ls -l" output in /usr/portage. -- Angelo Arrifano AKA MiKNiX Gentoo Embedded/OMAP850 Developer Linwizard Developer http://www.gentoo.org/~miknix http://miknix.homelinux.com
Re: [gentoo-dev] net-www category
j.romi...@gmail.com wrote: > On Tue, Apr 07, 2009 at 10:08:19AM -0600, Jacob Floyd wrote: >> Brasilian Portuguese below (potentially useful for portugal portuguese >> as well, though I have not been there and do not know if they'd use >> anything different) >> >> On Mon, Apr 6, 2009 at 2:42 AM, Ulrich Mueller wrote: >>> en: The www-plugins category contains plugins for Web browsers. >>> de: Die Kategorie www-plugins enthält Plugins für Webbrowser. >>> fr: La catégorie www-plugins contient des greffons pour butineurs Web. >> pt-BR: A categoria www-plugins contém plugins por navegadores da Web. > > It seems that the preposition is wrong. I would write: > pt-BR: A categoria www-plugins contém plugins para navegadores da Web. > > Romildo > pt-BR: A categoria www-plugins contém plugins para navegadores da Web. Indeed
Re: [gentoo-dev] Category tags on packages (was: new categories:)
I would keep existing categories and add a new TAG metadata to existing ebuilds. Something like TAG="kde music player lyrics lastfm visualization" for amarok, as example. A public list of *ALLOWED* tags would be published on our www infrastructures. Then during the portage metadata regeneration process, a new tags dir (under portage metadata dir) would be created with files for EACH tag. Each tag file would include the fully qualified name for the ebuilds in which the tag is present. This way, given a set of tags, it is easy and fast too lookup which ebuilds match the given tags and how much (percentage) they match them. For example: The user searches for "music gnome lyrics" exaile is tagged as "(...) music gnome lyrics" gnome-mplayer is tagged as "(...) music gnome" amarok is tagged as "(...) music lyrics" (...) So we can give an interest-ordered list to the user. Just my two cents, Thanks all -- Angelo Arrifano Gentoo Linux ARM/OMAP850 Developer
Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds
# Copyright 2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#
# @ECLASS: gpe.eclass
# @MAINTAINER:
#
# Original Authors:
# Rene Wagner
# Ned Ludd
# Angelo Arrifano
#
# @BLURB: Provides common functionality for the G Palmtop Environment.
# @DESCRIPTION: Provides common functionality for the G Palmtop Environment.
#
# Thanks to:
# loki_val for EAPI->EAPI2 patch
#
# Based on:
# gnome2.eclass and gpe.bbclass (the latter from OpenEmbedded)
inherit libtool toolchain-funcs
case "${EAPI:-0}" in
0|1)
EXPORT_FUNCTIONS src_unpack src_compile src_install
;;
*)
EXPORT_FUNCTIONS src_unpack src_prepare src_configure
src_compile src_install
;;
esac
ELTCONF="" # extra options passed to elibtoolize
GPE_DOCS="" # documentation files to be installed with dodoc
[ -z "${GPE_MIRROR}" ] && GPE_MIRROR="http://gpe.linuxtogo.org/download/source";
[ -z "${GPE_TARBALL_SUFFIX}" ] && GPE_TARBALL_SUFFIX="gz"
SRC_URI="${GPE_MIRROR}/${P}.tar.${GPE_TARBALL_SUFFIX}"
HOMEPAGE="http://gpe.linuxtogo.org";
IUSE="nls"
GPECONF="${GPECONF} --enable-debug=no --disable-debug"
RDEPEND=""
DEPEND="
>=dev-util/intltool-0.29
>=dev-util/pkgconfig-0.12.0"
# @FUNCTION: gpe_src_unpack
# @DESCRIPTION: Unpacks and applies some required patches for GPE.
gpe_src_unpack() {
unpack ${A}
cd "${S}"
has "${EAPI:-0}" 0 1 && gpe_src_prepare "$@"
}
# Do not call, use gpe_src_unpack() instead.
gpe_src_prepare() {
# let portage handle stripping.
for file in $(find . -name 'Makefile*') ; do
sed -i -e s/'install -s'/'install'/g \
-e s/'install -Ds'/'install -D'/g \
-e 's/$(INSTALL) -s/$(INSTALL) /g' \
-e 's;strip ;#strip ;g' \
${file} \
||die "Sedding ${file} failed."
done
[[ -f configure ]] && elibtoolize
}
# @FUNCTION: gpe_src_configure
# @DESCRIPTION: Configures a GPE package in a cross-compile aware environment.
gpe_src_configure() {
tc-export CC
[[ -f configure ]] && econf "$@" ${GPECONF}
}
# @FUNCTION: gpe_src_compile
# @DESCRIPTION: (Cross-)Compiles a GPE package.
gpe_src_compile() {
tc-export CC
has "${EAPI:-0}" 0 1 && gpe_src_configure "$@"
# miknix: Code belo must NOT die, some packages dont really build
anything,
# just install.
emake PREFIX=/usr
}
# @FUNCTION: gpe_src_install
# @DESCRIPTION: Installs a GPE package in the correct way.
gpe_src_install() {
local use_nls
use_nls=yes
use nls || use_nls=no
if [ -f configure ]; then
einstall "$@" || die "einstall failed"
else
emake DESTDIR=${D} ENABLE_NLS=${use_nls} \
"$@" install || die "emake install failed"
fi
if [[ "${GPE_DOCS}" ]]; then
dodoc ${GPE_DOCS} || die "dodoc failed"
fi
}
Thanks all for the suggestions/patches
--
Angelo Arrifano
Gentoo Linux ARM/OMAP850 Developer
Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds
On Qua, 2009-02-04 at 18:36 +0200, Petteri Räty wrote:
> Angelo Arrifano wrote:
> >
> > # Copyright 2008 Gentoo Foundation
> > # Distributed under the terms of the GNU General Public License v2
> > # $Header: $
> > #
> > # Authors:
> > # Rene Wagner
> > # Ned Ludd
> > # Angelo Arrifano
> >
>
> Should use eclass-manpages syntax.
Thanks, fixed on next revision
>
> >
> > # GPE ECLASS
> > #GPECONF="" # extra configure opts passed to econf
> > ELTCONF="" # extra options passed to elibtoolize
> > DOCS="" # documentation files to be installed with dodoc
> >
>
> If other eclass that comes before in the inherit hierarchy and sets
> DOCS, do we want to override it?
Yes, we want. If we will make dodoc die by default like you proposed
below, DOCS must be explicitly set by each ebuild sourcing any common
DOC provided by the eclass.
>
> > [ -z "${GPE_MIRROR}" ] && export
> > GPE_MIRROR="http://gpe.linuxtogo.org/download/source";
> >
> > [ -z "${GPE_TARBALL_SUFFIX}" ] && export GPE_TARBALL_SUFFIX="gz"
> >
>
> Is there a binary called that makes use of those two?
Yes, some packages uses bz2 but most of them gz. Ebuilds fetching bz2
from the default URI will use both.
>
> >
> > IUSE="${IUSE} nls"
> >
>
> This is the first use of IUSE in the eclass so there is nothing to
> append to.
True, fixed on next revision.
>
> >
> > gpe_src_configure() {
> > tc-export CC
> > if [ -f configure ]; then
> > elibtoolize ${ELTCONF}
> > econf "$@" ${GPECONF} || die "./configure failure"
> > fi
> > }
> >
>
> Ebuilds/Eclasses should use [[ instead of [ and econf dies on it's own
> any way.
Fixed on next revision.
>
>
> > gpe_src_install() {
> > USE_NLS=yes
> > use nls || USE_NLS=no
> >
>
> I don't see USE_NLS used outside install so it should be local and
> written in lower case.
This is an ancient issue where almost (but not all) packages provides an
--enable-nls flag. I'll discuss with solar about the usefulness of this
code. Thanks.
>
> > if [ -f configure ]; then
> > einstall "$@"
> > else
>
> If you really need to use einstall, it would be best to add a comment
> about why it's needed.
Some packages are not automake driven. We have to detect those.
>
> > make DESTDIR=${D} PREFIX=/usr \
> > STRIP=true ENABLE_NLS=${USE_NLS} \
> > "$@" install
> > fi
> >
>
> Should use emake. Stripping should be left to the package manager.
Stripping is problematic when cross-compiling. I'll do some more tests
to figure out the best way. Although, we are doing this for a long time
now and it works. IMHO, changing things in the last "hour" usually leads
to breakage.
>
> > # manual document installation
> > [ -n "${DOCS}" ] && dodoc ${DOCS}
> >
> > }
> >
>
> dodoc should have || die with it
There are some ebuilds that don't provide all the DOCS, I'll try to fix
the ebuilds first and then we'll see..
>
> >
> > EXPORT_FUNCTIONS src_compile src_install src_unpack
> >
>
> Never exports configure for EAPI 2.
Already fixed, thanks to loki_val for his patch.
>
> Regards,
> Petteri
>
>
>
Thank you,
--
Angelo Arrifano
Gentoo Linux ARM/OMAP850 Developer
Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds
On Qua, 2009-02-04 at 13:56 +0200, Petteri Räty wrote:
> Angelo Arrifano wrote:
> >
> > Since we are maintaining this over half a year now, we think that its
> > time to finally starting moving step-by-step the GPE suite into the
> > portage tree - starting with the eclass and toplevel categories.
> >
>
> Please start by posting the new eclasses for review then.
>
> Regards,
> Petteri
>
# Copyright 2008 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#
# Authors:
# Rene Wagner
# Ned Ludd
# Angelo Arrifano
# based on gnome2.eclass and gpe.bbclass (the latter from OpenEmbedded)
inherit libtool toolchain-funcs
# GPE ECLASS
#GPECONF="" # extra configure opts passed to econf
ELTCONF="" # extra options passed to elibtoolize
DOCS="" # documentation files to be installed with dodoc
[ -z "${GPE_MIRROR}" ] && export
GPE_MIRROR="http://gpe.linuxtogo.org/download/source";
[ -z "${GPE_TARBALL_SUFFIX}" ] && export GPE_TARBALL_SUFFIX="gz"
SRC_URI="${GPE_MIRROR}/${PN}-${PV}.tar.${GPE_TARBALL_SUFFIX}"
HOMEPAGE="http://gpe.handhelds.org/";
IUSE="${IUSE} nls"
GPECONF="${GPECONF} --enable-debug=no --disable-debug"
RDEPEND=""
DEPEND=">=dev-util/intltool-0.29 >=dev-util/pkgconfig-0.12.0"
gpe_src_configure() {
tc-export CC
if [ -f configure ]; then
elibtoolize ${ELTCONF}
econf "$@" ${GPECONF} || die "./configure failure"
fi
}
gpe_src_compile() {
tc-export CC
has "${EAPI:-0}" 0 1 && gpe_src_configure "$@"
emake PREFIX=/usr || die "compile failure"
}
gpe_src_install() {
USE_NLS=yes
use nls || USE_NLS=no
if [ -f configure ]; then
einstall "$@"
else
make DESTDIR=${D} PREFIX=/usr \
STRIP=true ENABLE_NLS=${USE_NLS} \
"$@" install
fi
# manual document installation
[ -n "${DOCS}" ] && dodoc ${DOCS}
}
gpe_src_unpack() {
unpack ${A}
cd "${S}"
# let portage handle stripping.
for x in $(find "${S}" -name 'Makefile*') ; do
sed -i -e s/'install -s'/'install'/g \
-e s/'install -Ds'/'install -D'/g \
-e 's/$(INSTALL) -s/$(INSTALL) /g' $x
done
}
EXPORT_FUNCTIONS src_compile src_install src_unpack
Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds
On Ter, 2009-02-03 at 11:47 -0800, Donnie Berkholz wrote: > On 11:24 Tue 03 Feb , Donnie Berkholz wrote: > > > We currently provide an eclass and ebuilds arranged by top level > > > categories following upstream categorization. Explicitly gpe.eclass and > > > top level gpe-base gpe-net gpe-pim gpe-games gpe-utils gpe-media > > > gpe-xsession. > > > We know we have a lot of them but upstream finds useful to classify them > > > like that and so do we. > > > > Could you expand on how each new category is useful? In my maintainer point of view, it just make sense to follow upstream categorization of packages. In the user centric view, it will be a lot more easier to know what package is for by looking at each category. gpe- is intended for embedded devices, one might want to keep it clean and minimal. > > > > > The eclass and some ebuilds were based on bugzie #101393. We started > > > playing with them as big flat gpe-base category which evolved over time > > > by means of consecutive testing on ARMv5 handheld devices and needs. > > > > > > Since we are maintaining this over half a year now, we think that its > > > time to finally starting moving step-by-step the GPE suite into the > > > portage tree - starting with the eclass and toplevel categories. > > > > What are the stats on package count per category? > > I got this from solar: > > 30 gpe-base > 8 gpe-games > 4 gpe-media > 9 gpe-misc > 2 gpe-net > 32 gpe-phone > 6 gpe-pim > 18 gpe-utils > 8 gpe-xsession > > Unless those tiny ones are going to be growing a lot, I'm not terribly > convinced of this many new ones. > They won't grow much over time so I understand your point. Although, I would like to ask the drawbacks of adding those new categories to portage. Adding confusion and mess won't be an issue because these are very specific categories which won't affect other ebuilds or other categories. After all we don't want to introduce something like dev-gpe mail-gpe x11-gpe net-embedded ... which, IMHO, would be messy. So, despite "looking" a *lot* of new categories with not so much stuff inside, will this slow down portage sync/metadata-regen/loopkup in some way? Thank you, -- Angelo Arrifano Gentoo Linux ARM/OMAP850 Developer
Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds
On Ter, 2009-02-03 at 11:28 -0500, Richard Freeman wrote: > Angelo Arrifano wrote: > > We at -embedded would like to introduce GPE - The G Palmtop Environment. > > < > palmtop/handheld computers running the GNU/Linux or any other UNIX-like > > operating system.>> > > > > Sounds neat? How long until I'm running gentoo on my android? :) > Right away: http://tinderbox.dev.gentoo.org/embedded/linwizard/overlay/ Take the gpe-base/gpe meta ebuild which should pull all the stuff. Happy xcompiling, -- Angelo Arrifano Gentoo Linux ARM/OMAP850 Developer
[gentoo-dev] Announcement of The G Palmtop Environment ebuilds
Hello ladies and gentlemen, We at -embedded would like to introduce GPE - The G Palmtop Environment. <> GPE is currently under active development, being version 2.8 already very usable providing a modern mobile desktop environment. We currently provide an eclass and ebuilds arranged by top level categories following upstream categorization. Explicitly gpe.eclass and top level gpe-base gpe-net gpe-pim gpe-games gpe-utils gpe-media gpe-xsession. We know we have a lot of them but upstream finds useful to classify them like that and so do we. With the running discussion at -dev about new top level categorization models and tagging system, maybe a better solution is found. The eclass and some ebuilds were based on bugzie #101393. We started playing with them as big flat gpe-base category which evolved over time by means of consecutive testing on ARMv5 handheld devices and needs. Since we are maintaining this over half a year now, we think that its time to finally starting moving step-by-step the GPE suite into the portage tree - starting with the eclass and toplevel categories. Sincerely, /me in the name of the embedded team. -- Angelo Arrifano Gentoo Linux ARM/OMAP850 Developer at Gentoo Embedded
Re: [gentoo-dev] QEMU Sick!
On Qui, 2009-01-22 at 11:07 +, AllenJB wrote: > Mateusz Mierzwinski (me.matheos.org) wrote: > > - No main packages updates. > Define "main packages". If there are packages you know to be out of > date, file a bug at http://bugs.gentoo.org > > > > - No serious Gentoo-Wiki - rewritten after great boom! > Yes, the loss of content on Gentoo Wiki was unfortunate. An offsite > backup system has now been put in place so this won't happen again on > the same scale. Others have scraped Google Cache for most of the old > content and put it up at http://gentoo-wiki.info. Many have been busy > working on articles on the new wiki and it is fast returning to its > former glory (it's even better in some respects IMO - the rewrite has > been an opportunity to correct some issues). > > > > - Portage blocks! - in 2005 there was no blocks, system was stable and > > working with max performance - now blocks are needed - WHY?! > Portage blockers did exist in 2005. What's more, as of portage 2.1.6, > most blocks are now resolved automatically. > > > > - Amd64 have oldest packages developed by devs (much don't work). > This is completely false. I use amd64 on most of my machines and the > only thing I have issues with is Flash - but that's certainly not the > fault of the Gentoo developers. I don't know if you are still using the 32bit version of Adobe's flash but if you are, I really recommend using the 64bit Flash 10. It has HUGE improvements in speed (it doesn't look I'm running flash anymore). It's only a alpha version but I find it more stable than previous versions: net-www/netscape-flash-10.0.21.1_alpha It might also have a lot of security issues, I don't care though. I use flashblock to run trusted flash content only. Just my 2 cents, Greetings all. > > > > - GLI death! People used GLI! You write OS for PPL, not for Your usage. > The GLI has, in my opinion, been in a poor state since its inception. It > has slowly gotten a bit better, but not enough. In my opinion it should > never have been an icon on the desktop of the livecd. It wasn't ready. > And for whatever reasons, progress on fixing its issues never seemed to > be that good. > > Also, you'll actually find most open source developers are in it to > "scratch an itch". It may seem completely selfish, but it works. > Developers volunteer their time on projects they are interested in. You > can't force people to work on things they aren't interested in in their > free time - it'll never work. > > I also believe there's an alternative project which is replacing the GLI > for what it was intended to be used for. Details of this will be in the > announcement when it is released. > > > > - Stupid ideas about kicking off creator of Gentoo - You using his work! > > That's sucks! Try to rewrite whole portage by Your own then You can kick > > off anyone You like! > No one "kicked off" Daniel Robbins - As far as I know he left of his own > accord. His relatively recent "return" is a long story and another issue > entirely. > > > > - KDE 4.1 packages updates... or should I say - none of it! Latest > > unstable version of KDE 4 is 4.2 version!!! > KDE is being worked on in overlays at the moment. Personally I don't > think it's ready for everyday use yet. I tried the 4.2 SVN versions > recently and it still had many issues. > > > > Check DistroWatch what You done with Gentoo! In 2007 Yr. Gentoo was 7-th > > place, and now? > Distrowatch ranks distros based on page views on its site. It's hardly a > great way to rank distros. > > AllenJB > -- Angelo Arrifano Gentoo Linux ARM/OMAP850 Developer
