Re: [gentoo-dev] Welcome Back, Cummings
Seemant Kulleen wrote: [Mike is back] Yai! Welcome, we really needed you back (beside that ruby is quite nice, *cough*) lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
Nathan L. Adams wrote: So you're saying that Gentoo consists of projects that are completely 'silo'd up' and have no bearing whatsoever on each other. Then the DevRel project only has bearing on those who actually join DevRel. Neat, a group formed for the sole purpose of coordinating itself. Security need only concern itself with securing its members (from who knows what!), and infra can just ignore the needs of everyone else (different project!). I wonder how any of the other projects *ever* made it onto the website... Sigh, every project can set up it's own rules for internal project tasks, that means that internal docs could be a set of nice ascii art and then, you have a nice GuideXML page to point to them than happens to be translated on html/pdf/plaintext/whatever upon the necessities. The errata.g.o (not the summaries w/ link that emerge would output) would obviously be documentation, would obviously be governed by the Doc rules, and it would be irrelevant which staff member happened to publish a particular guide. If Gentoo really is as balkanized as you state, then it is a sad state of affairs indeed. Maybe the 'full fledged' versions should be GuideXML-lite or something, I'm not sure, but your argument is just silly. ARGH looks like MANY people do not get what is good about xml and what is not so good. The whole point of using GuideXML is to make EASY convert to something else. NOT to use it. The problem of using xml everywhere is that it is harder to write and has some work required in order to be parsed and translated. So, if I have to set up an infrastructure that would require me to generate pdf, webpages, text, younameitwegetit and to update/write it not so often and not so quickly, I'd use xml. If there is something that I'd have to write often by hand and quickly and has to be used as is mostly. I'd stay with a simpler format (that maybe is still machine parsable). That said the format Ciaranm suggests for news looks ok for me. XML won't add anything but slowing me. For an errata site GuideXML or an _extended_ version of it could be useful. lu -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDa5WH2QTTR4CNEQARAlERAKCeVue4ATD4fXBgLGdRAWt4Gi7vWgCcCs7R w/Pvjk9vv2C00HmrTkhBnHU= =Eiba -END PGP SIGNATURE- -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] divx4linux sudden death
Mike Frysinger wrote: can ffmpeg/xvid be used as drop-in replacements ? or do upstream peeps need to write completely new code to use ffmpeg/xvid ? -mike Given that almost every application has support for xvid and ffmpeg and divx4linux is a legacy in most case... -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two
Ciaran McCreesh wrote: On Thu, 10 Nov 2005 16:07:37 -0800 Mike Owen <[EMAIL PROTECTED]> wrote: | What about something like "/etc/portage/news.read", which contains a | single news file per line. Perhaps have support for something like | "<=2006-01-01" in order to be able to manually mark date ranges as | read. Eh, yet another file. No real need for it really, it just adds complexity. Besides, /etc isn't for program-generated data. Modify anything within PORTDIR is wrong. I'd put a /var/db/news and a /etc/portage/news to handle that. Which should be a reasonable timeframe for the news to stay? Till the next gentoo release? lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 "Critical News Reporting" Round Two
Dan Meltzer wrote: Forever. Too long for the not infinite space in the server/mirror Gentoo releases mean absolutely nothing, they do absolutely nothing. Beside adding some profiles, deprecating and removing others, provide an updated installation media... The news should stay until the upgrade occurs If they are delivered by portage they will be rsynced back to their original form. I guess that the news could be removed as we do for the ebuilds. (in this case about once the versions related to the news got removed more or less). lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Email subdomain
Kurt Lieber wrote: On Fri, Nov 18, 2005 at 05:44:53PM -0500 or thereabouts, Curtis Napier wrote: There is no technical reason why any of this is necessary and it doesn't provide any tangible benefits that I can see. If a user really wants to know someone's role within the project, they can go look it up on the web site. +1 -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] opinion on how to improve the website redesign
Ciaran McCreesh wrote: The infinity design makes us look like a bunch of ricers. Kill it! +1 -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] status of http://wwwredesign.gentoo.org
Curtis Napier wrote: This has been cross posted to gentoo-dev and www-redesign. make the purple bar with portage and the other feature disappear or at least 1/2 tall. Put the Community, Resource, Documentation either on the left in a pane or on the top. the sponsor pane should retain the violet background. Move back the solid logo instead of the infinity one. That's all lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Split ELF Debug (defult or not?)
Ned Ludd wrote: [snip] It's great! Make it a FEATURE default on for common profiles. lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] last rites for avifile, vcr, zphoto, drip, divx4linux, quicktime4linux
Luca Barbato wrote: [snip] avifile will be removed tomorrow since mlt and mlt++ (required by jahshaka as avifile replacement) will be released tomorrow. If you are maintaining or using one of the packages in the list keep in mind that it will be removed in 24h if aren't avifile free. lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eclass mozconfig-2 restrictions
Ned Ludd wrote: You should talk to ferringb about why it's evil to remove functions from an eclass ever. eclasses can't inherit from other eclasses? Just splitting functionality on another eclass and keep the former eclass providing everything by inheriting the new one doesn't work? lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for media-video/dvdrip
Mike Frysinger wrote: so the video herd policy is to remove packages until you're left with a small enough subset of packages you can handle ? -mike I'd rather say that we select packages that evolve and fit the needs and kill what isn't suitable anymore. There are still many way to shoot your foot using a nice front-end to your transcoding tool of choice =) lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for media-video/dvdrip
Chandler Carruth wrote: As a user currently, what steps could I take to help this package stay alive? I will take them as the alternative is to put an unofficial ebuild up on a webpage. On my to be killed list I have transcode <1 avifile transcode 1 is already there and seems in good shape, if you can help us making sure dvdrip works fine with it we won't make transcode-0.6 bring it to the grave =) lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] The deal with epkgmove
Kurt Lieber wrote: CVS may not be the new, shiny kid on the block, but it's been very stable, presented few problems and, in general, has served us well over the past 5+ years. Folks tend to point at the fancy bells and whistles that other VCS offer, but they don't always stop to consider the stability and scalability which are the most important characteristics by far. I'd suggest having a look at git or mercurial, they are tested on a quite big workload and they seems good enough for the task. svn so far was good but I don't know which big projects had it deployed. lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Developer: Sanchan
Mike Doty wrote: "I live in Italy on the river of the lake of Como in a small country of less than 200 inhabitants. the Italian conspiracy taking place? who knows ^^ Welcome =) Have a lot of fun and beware of the rabid developer =) lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (Critical news reporting) updates
Ciaran McCreesh wrote: * Anything involving XML. What about incidentally make the format yaml compatible? yaml.org /me runs lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Multiple Repo Support
Danny van Dyk wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alec Warner schrieb:
|>>The big controversy seems to be over whether repositories carry a
|>>unique identifier string (for example, in metadata/repository_id) or
|>>whether it's user-assigned. The former is clearly the more sensible
|>>option, since it lets you do things like (syntax made up):
|>>
|>>DEPEND=">=foo-bar/baz-2.1::ciaranmssekritrepo"
|>>
|
| Well lets return to normal syntax for a moment.
| DEPEND=">=foo-bar/baz-2.1"
| And lets assume this package is named "blar" because I enjoy that name.
|
| emerge blar --repo=ciaranmssekritrepo
|
| This accomplishes the same thing, except I get to name the repo whatever
| I wish, and you lose the ability to specify repositories in DEPEND.
No, it doesn't. How would you add repository-specific items to
/etc/portage/package.* ?
Futher, imagine this: The gentoo-x86 repo is split into, say, 4
repositories: gentoo-{system,base,desktop,games}. How would you
reference DEPENDs from one repo to the other in this case?
An optional namespace modifier for *DEPENDS is Good Thing(tm) in my
eyes, and I'd really appreciate it being added to portage rather sooner
than later.
Just one remark: What about making the syntax a bit more familiar to C++
users:
~ DEPENDS="gentoo-foo::foo-bar/baz-2.1"
Comments?
what about
DEPENDS="gentoo-foo/foo-bar/baz-2.1"
lu
--
Luca Barbato
Gentoo/linux Developer Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Stupid USE defaults that need cleaning
Doug Goldstein wrote: the USE defaults are a bit INSANE... We need to get rid of some of this crap... ./default-linux/x86/2005.0/make.defaults:USE="alsa apm arts avi berkdb bitmap-fo nts crypt cups eds emboss encode fortran foomaticdb gdbm gif gnome gpm gstreamer gtk gtk2 imlib ipv6 jpeg kde libg++ libwww mad mikmod motif mp3 mpeg ncurses nls ogg oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl spell ssl tcpd truetype truetype-fonts type1-fonts vorbis X xml2 xmms xv zlib" Examples include... WHY is "arts" turned on... There's absolutely no reason for it. AFAIK, you can even build KDE without it. Why are we turning "gnome" on... who says you want to pull in the damn desktop? "eds"... very very very specific Gnome app that most people don't want support for. If I remember correctly, this was added cause someone was too lazy to do the right work around in the ebuild. "gtk" and "gtk2", I thought we cleaned up this mess of just 1 USE flag. But seriously, why are these on? "kde", uh same reason and Gnome above... "ogg", "oggvorbis", "vorbis"... I thought we cleaned up this mess... I didn't bitch enough to remove oggvorbis. please update your ebuilds... lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's
Donnie Berkholz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I know some of you have done research on how gentoo-x86 converts over to other systems besides CVS such as SVN, arch, etc. But I can't find the info anywhere in my archives. Could whoever's got it, post it? I'm particularly interested in hearing about CVS, SVN, mercurial, bazaar, darcs. http://www.darcs.net/DarcsWiki/Tailor - fun and interesting if you want to export to git make sure you after pack the tree and then prune, otherway you get a huge overhead. I wonder if arch2 will fix all the tla shortcomings. btw, I played a bit with git recently and probably I'll give a try with mercurial soon and I couldn't find any annoying issues so far. To the people that are thinking that isn't necessary to go distributed, well, nothing is preventing us from using the same paradigm. lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's
Spider (DmD Lj) wrote: Git, seems useful, but a bit hard to track ( I really dislike having to fibble around with long random characterstrings just to check out a certain version. I can deal, but still) cogito solves the issue more or less lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] h264/x264 global useflag
I'm thinking about adding an h264 useflag in the global scope, it will be used by an handful of media project in a relatively short time. Please tell me if you like the idea or not. lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (news) Round Seven
Brian Harring wrote: +1 on this revision, although I demand a pony. +1, w/out pony. lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] GLEP 20 /srv - Services Home Directory Support
I'm thinking about adding the srvdir[1] global useflag. Scream if I miss some discussion preventing it. (fenice[2] will use it, that's why I'm adding it) lu [1] http://www.gentoo.org/proj/en/glep/glep-0020.html#implementation [2] http://packages.gentoo.org/search/?sstring=fenice -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 20 /srv - Services Home Directory Support
Kalin KOZHUHAROV wrote: Luca Barbato wrote: I'm thinking about adding the srvdir[1] global useflag. Scream if I miss some discussion preventing it. (fenice[2] will use it, that's why I'm adding it) lu [1] http://www.gentoo.org/proj/en/glep/glep-0020.html#implementation [2] http://packages.gentoo.org/search/?sstring=fenice Hi all, not a dev, but please bear with me :-) From [1] above: GLEP: 20 Title: /srv - Services Home Directory Support Version:1.2 Last-Modified: 2004/11/11 21:35:53 Author: Stuart Herbert , Rob Holland Status: Approved Type: Standards Track Content-Type: text/x-rst Created:09-Feb-2004 Post-History: 21-Feb-2004, 11-Nov-2004 It is 2006, any updates on this GELP? Just a quick look turned out a 404 error on the FHS2.3 link. ( http://www.pathname.com/fhs/ ?) I am not very read in LSB, but just saw there is a 3.x version... What about LSB 3.x? Is it the same recomendation? Although I run quite a bunch of services on a few boxes, I don't see this whole idea (/srv). I read the GLEP, I read [FHS#srv] but still. And it says: "The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done." So how does Gentoo implement it? [FHS#svg] http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM And as the GLEP talks about webapps, what will an upgrade of a webapp (say Bugzilla) to/from srv? I feel it breaking and user screaming. that's an useflag you may use it or not, webapps use webapp-config that already handles /srv w/out any problem, having the base webroot using srvdir would be nice so you spare a couple of mv but that's all... lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 20 /srv - Services Home Directory Support
Stuart Herbert wrote: Which packages do you want to add the srvdir global USE flag for? fenice has support for it in at configure level, gentoo-webroot-default could enjoy it as well as apache may provide an alternate default too. lu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: ca-certificates PDEPEND
Jakub Moc wrote: 9.1.2006, 17:12:31, Andrea Barisani wrote: On Mon, Jan 09, 2006 at 11:08:38AM -0500, solar wrote: Do you think the PDEPEND of the ca-certs should be tied to a USE= flag? If so should it be a 'no*certs' flag or a USE=cacerts ? USE=cacerts sounds the proper course of action to me. NOT until use-based deps are in place, plzktnxbye!!! Don't break the damned realplayer thing again. Just add it as DEPEND and everybody would be fine, isn't it? lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC - new category dev-tos
sanchan wrote: Hi all, I'm working on TinyOS related ebuilds (Bug #78908) and since actually there are 20 ebuilds in my overlay may be worth proposing a dev-tos category. It will take a few weeks in order to have all the ebuilds updated for the new release of tinyos, have them reviewed by peer an committed to the tree, but it's a lot easier to make a category early rather than moving stuff. Isn't it too specific? I'd rather spread them in the current categories. lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: 2006-01-15 PPC meeting summary
Lars Weiler wrote: == 2. Dev Activity (Who's alive?) == Devs seemed to have vanished and even the operational manager isn't around strategic, not operational, I'm still alive ^^! (which had happened more often in the past -- probably there is a bane on this position). lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] My Resignation
Lina Pezzella wrote: Many of you may have noticed that I have been rather inactive lately. I had been hoping to become active again after the completion of my thesis, but it seems that "real life" has made a bid for the time slot I used to devote to Gentoo. I have enjoyed working with all of you and regret having to resign. I hope to have you back once you'll get more free time ^^ Best wishes! lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] beep-media-player removal: 04/03/2006
George Prowse wrote: > No, BPMx and Audacious are two different things > bmpx is using large frameworks and have some deps that makes it in the league of amarok totem and friends, call them large players bmp is in the league of zinf xmms audacious xmms2 (to a degree) and so on, call them light players. Now, bmp is phased out, which is the gtk2 light player that could match it's deps and features best? lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Leader http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Alfredo Tupone (Tupone)
Diego 'Flameeyes' Pettenò wrote: > On Monday 06 March 2006 20:33, [EMAIL PROTECTED] wrote: >> Alfredo has joined the Gentoo team to help with the games herd. I'm sure >> he'll have a fun time "testing" all those games :) > Welcome! > > We're really going to form a conspiracy now :P > Update the devmap and start planning a meeting, given the season the best would be a bbq/grill in the country. Anybody has suggestions =) ? lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Staffer: Christel Dahlskjaer
Seemant Kulleen wrote: > Ms. Dahlskjaer (Natasha, when she's in Russia) hails from Norway, > somewhere near the arctic circle. She smarted up and moved to warmer > climes -- tropical England, where she lives these days. She enjoys > belly dancing, yoga, coffee, sleeping with the light on, falling > bookmarks, unbookmarked spots in a book, and playing the violin: > sometimes in that order. > ...oO(Doing them all at the same time would require too many arms...) Welcome Christel! lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] package naming
Diego 'Flameeyes' Pettenò wrote: > On Monday 20 March 2006 18:42, Roy Marples wrote: >> Now, if the commandline is the same, should the package name be the same? >> If so, what version number should I be using? It's currently just called >> resolvconf-0.1 > I would say gentoo-resolvconf as it's a rewrite/fork. > why not having it implemented as eselect module? ^^; lu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] overlay support current proposal?
Stuart Herbert wrote: > Thanks for the summary. I think that's a fair assessment of where we are at. > > The offered software will be trac, svn, and moinmoin. I'm going to > look at darcs, and with the help of the haskell team and infra > determine if we can support it or not. No-one has expressed a > preference for a different distributed VCS instead of darcs. > Please consider git and mercurial proxies, maybe nobody proposed it yet but is relatively easy to provide it and it would be great since gives you most of the goods from darks w/out the pain related of building it. lu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] overlay support current proposal?
Aron Griffis wrote: Luca Barbato wrote: [Sat Mar 25 2006, 05:16:57AM EST] Please consider git and mercurial proxies, maybe nobody proposed it yet but is relatively easy to provide it and it would be great since gives you most of the goods from darks w/out the pain related of building it. Could you point to some references? Aron sure: http://www.darcs.net/DarcsWiki/Tailor http://www.selenic.com/mercurial/wiki/index.cgi/ConvertingRepositories http://darcs.net/DarcsWiki/DarcsGit lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] overlay support current proposal?
Duncan Coutts wrote: On Fri, 2006-03-24 at 22:47 -0800, Ryan Phillips wrote: We need to pick one VCS and only one. Having multiple systems requires users to install multiple applications and learn each one. Not all of them are easy to pick up. Plus, it would be nice to be able to merge from the overlays to the Portage trunk. I'm not sure it is realistic at the moment to pick just one DVCS. Apart from getting one that works on all systems, it's likely to be hard to get everyone to agree. There's a slight danger that the discussion of which VCS could distract us from the important questions. If we're going with the idea that at least at first these overlay are going to be run by and for projects/teams/herds then perhaps the choice of VCS is not so important. So long as it's feasible with infra of course. Since we don't yet expect people to be using several of these overlays at once it's probably that each developer or outside contributer would not need to use more than one VCS (in addition to cvs for portage). As a plus side, this might give us some feedback on which (D)VCSs work well for overlay development and might help inform our future decisions on possible cvs replacements. BTW I hope that with all my recent emails on the issue of which arches/platforms can run darcs I've not been giving the impression that I'm pushing for darcs to be the "one true" choice. I am certainly interested in working with any arch team to get ghc and darcs ported but that's a separate issue. given that darcs can export and import git with ease and mercurial can do the same up to a degree, we could use those three. (since they are all documented people could implement them in other language if they wish) darcs : ghc mercurial : python git : c+bash (and optional perl/python for some merge scripts) lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ebuild Developer: Christian Hartmann (ian!)
Danny van Dyk wrote: Congratulations Christian! :-) Danny Another perl monk joining! Welcome and beware of the rabid vapier! lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Thomas Cort (tcort)
[EMAIL PROTECTED] wrote: Give Thomas a warm welcome if you haven't already done so :) Welcome Thomas! lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
Alexandre Buisse wrote: > > [1] http://mail.opensolaris.org/pipermail/tools-discuss/2006-April/000366.html > [2] http://www.opensolaris.org/os/community/tools/scm/bzr-eval/ > [3] > http://www.opensolaris.org/os/community/tools/scm/dcm_evaluation_mercurial/ > [4] http://www.opensolaris.org/os/community/tools/scm/git-eval.txt > Those figures are slightly old, some of the issues are probably addressed both on mercurial and git. I'd say that both are nice and are probably a good solution. if there is space and cpu I'd like to have someone playing with them and send benchmark results. Mercurial should use a bit less disk and git should be a little faster and with better merge/conflict resolution features. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [gentoo-core] Disenchantment
Daniel Goller wrote: > whole situation (more power to you userrel guys, please prove me wrong), > why would we want to be more open and inviting if being a badass who > passed some generic quiz is so much more fun. The "quiz" is just a dumb checklist, if you already know everything needed for writing and managing ebuilds you won't have any problem answering it. If you have doubt you may look up informations or ask your mentor for pointers. If you think that's too hard for you well... > If everyone would step > down from the pedestal for a while and looked around, then maybe, just > maybe we would realize that we no longer do things to be there for them > (the users) but for ourselves, anything is geared towards improving our I always did thing for myself and for partially compensating others that gave me that much, I'm not on a pedestal, I'm on the shoulder of a giant. I do like help others join in, but is up to them climb using the rope I'm providing. > leetness level, why do things have to be so complicated that people > think one can not work on ebuilds w/o some super hard special quiz or > two, it all gears towards "what you don't know how to use XYZ, you must > not be very smart/leet/cool." the quiz is dumb and is structured to point some common situations in which you may not solve properly at the first try. I'm quite sad we have such different ideas about the quiz and why it got in or why we are developing Gentoo. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [useflag] v4l2 : video4linux2 support
Currently we have already 5 applications supporting v4l2 (6 if I split the support in ffmpeg) what about having it global too? local use flags (searching: v4l2) [+ C ] v4l2 (dev-libs/DirectFB): Enables video4linux2 support [+ C ] v4l2 (dev-libs/pwlib): Enable video4linux2 support [+ C ] v4l2 (media-video/mpeg4ip): Enable video4linux2 support for mp4live [+ C ] v4l2 (media-video/mplayer): Enables video4linux2 support [+ C ] v4l2 (media-video/transcode): Enable video4linux2 support lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [useflag] v4l2 : video4linux2 support
Henrik Brix Andersen wrote: > On Tue, May 30, 2006 at 11:57:19PM +0200, Luca Barbato wrote: >> Currently we have already 5 applications supporting v4l2 (6 if I split >> the support in ffmpeg) > > Any reason why we can not use the existing 'v4l' use flag for version > 2 as well? Why repeat the gtk/gtk2 mistake? > Good point considering I already merged it in ffmpeg long ago. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Grant Goodyear wrote: > Stefan Schweizer wrote: [Wed Jun 07 2006, 07:42:03PM CDT] > My reasoning is that bugzilla provides a > place for community development of an ebuild (including commentary!), > which would not be true of just the overlay. If one were instead to add > a magical bugs whiteboard status or keyword that let a script know that > there's an ebuild to pull from bugzilla that should be added to the > there-be-dragons-here overlay, I'd think that would make life > much simpler for everybody. +1 -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] client+server packages - build which one?
Patrick McLean wrote: >> > finger, telnet and ssh are probably other candidates. (though not too > many people set up boxes without a ssh server these days). > > ++ to this, I have always found it a little absurd having dhcpd > installed on my laptop just for dhclient. dhcpcd could be a better temp solution =) lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] client/server policy for ebuilds
Mike Frysinger wrote: > rather than moving to some sort of policy that satisfies no one completely > and > we'll have to back out of later, why dont we wait until portage can give us > proper support for USE=client/server > -mike +1 -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Profiles Part 2
Stephen Bennett wrote: > Many things were discussed in the last round of this thread (Paludis > and Profiles, in case anyone missed it), and many useful points raised. > One of these, which seems to have been largely missed in amongst the > other noise, forms the basis of this proposal. It is in some ways more > and in some ways less intrusive than the previous proposal, > and is also completely package-manager-agnostic. > > In short, I would like to suggest replacing sys-apps/portage atoms in > the base and default-linux profiles with virtual/portage, and removing > the python dependencies from them. For most users this would have an > effective zero change, since the default provider for virtual/portage > is sys-apps/portage, and the python dependency will be pulled in by > Portage when calculating system deps. According to my understanding, > this should also produce no change when building release media, due to > both Portage and Python being in packages.build. > > The only change introduced by this is that it becomes possible to > bootstrap a system with a different package manager simply by > installing it before 'system'. There are a couple more changes needed > to allow this -- namely that a few system packages have old > dependencies on >=portage-2.0.49, but these can be resolved seperately. > Any problems caused by packages depending implicitly upon Python will > show up only on systems not using Portage, and can be easily fixed with > the cooperation of package maintainers. > > I would like to think that this proposal addresses most of the concerns > raised in the last thread -- it implies nothing about support for any > other package manager, and introduces nothing that could cause problems > for Portage users, while still allowing alternative package managers to > use the tree without needing Portage installed. > > I am also aware that this falls roughly under what the Council was > asked to discuss in its June meeting, but since that seems to have not > happened, I'm bringing it up anyway, since I would like to get > something done here. > > Comments? If you can spot those issues and fix them w/out rush on package mantainers, no problems at all. Just make sure nobody will ask to "fix" something working with portage in 0time because of paludis changes. lu PS: there is a formal spec about ebuilds now? -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Defining the Tree: a proto-GLEP.
Stephen Bennett wrote: > This would be, in essence, a formal definition of the layout of the > tree, and the format of and assumptions made by every file contained > within it. I'm all for it. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Defining the Tree: a proto-GLEP.
Alec Warner wrote: > > I prefer gentoo-x86, although others hate that x86-centric moniker ;) > ebuilds' tree could be ok (now after the transgender cow Larry we greet the transgenic fruits that grown on trees but have to be herded: the Ebuilds!) Ok, I should not post after midnight, local time... lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Sharing portage?
Molle Bestefich wrote: > Hi > > Follow-up question to the backup thingy. > > Is there an easy way to share Portage's database between multiple > virtual machines? > unionfs is your friend =) lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] strict-aliasing rules, don't break them
You may aware or not that there is a nice optimization (more effective if you have some registers to spare) based on how you access memory thought variables. Since it wasn't that effective and didn't break anything it is enabled since -O2. Problem: recent gcc are doing some quite smart tricks with aliasing and as result they will break in subtle way your code if you use strict-aliasing rules optimization on type puns. Quick solution: enforce -fno-strict-aliasing as global cflag. Side effect: you may lose a bit in performance, but better safe than sorry: the first package showing issues was openssl[1] mismatching hashes, guess how discovered that and how (hint: ssh was refusing logins...) Long term solution: 1- check your new package for aliasing compliance, and if you have time fix it in the code or in the makefile, if you haven't append -fno-strict-aliasing to the cflags and maybe send a notice about it upstream 2- append -fno-strict-aliasing to every source known to have such issue. I'll do 2 on all packages in the tree showing the issue if you think is ok, arches not yet affected will be in the future. lu [1]http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14725 -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] strict-aliasing rules, don't break them
Diego 'Flameeyes' Pettenò wrote: > On Saturday 17 June 2006 12:17, Luca Barbato wrote: >> Long term solution: > The best long term solution would have been to fix the code, but actually I > didn't ever found a quick explanation of how to fix this kind of code... > you can use unions or rewrite completely the line using it in another way, in certain case the type pun is the quickest solution so it's better to append -fno-strict-aliasing in the Makefile. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] strict-aliasing rules, don't break them
Harald van Dijk wrote: > That warning is given for valid code too. Please only add > -fno-strict-aliasing if you actually find a package misbehaves without > it, or if you have verified that there is indeed an aliasing violation > in the code. Or just bug upstream to either avoid ugly code or just use -fno-strict-aliasing when needed. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] net-libs/xulrunner-1.9 slotting or not?
Raúl Porcel wrote: Xulrunner-1.9 is a big change, and the apps using it won't work until they are fixed. So this needs to be decided, i've been working on slotting xulrunner, and i'm ready to put it in the tree. However i'd like to see what developers(since they will be the ones who will have to deal with this) and users prefer. Even if an app is compatible with xulrunner-1.9, it will have to be patched if we slot xulrunner. Since the pkgconfig files for xulrunner-1.9 are renamed to avoid collisions with current xulrunner-1.8. The other approach would be not slotting it, p.mask xulrunner-1.9 and wait until all the packages work against it and then unmask. Given the number of applications I'd rather have them fixed with the patches pushed to respective upstreams if we got there first. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Help offered - Portage tree
Robin H. Johnson wrote: - "What I am asking Gentoo Foundation is, let me fix them" Apply to be a developer, then you can fix them. I don't personally have any opinion (positive or negative) about Sabayon, but a former coworker of mine was a big fan. Addendum, the Foundation cannot do anything about that. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Help offered - Portage tree
Natanael Copa wrote: IIRC thread starter complained about too many wrong RDEPEND. No, the thread started with an attitude problem, still unsolved btw. Problem is not that devs are not willing to fix. Problem is that its to easy to inject wrong RDEPEND in the tree in the first place and only way to get it out from there is to wait for someone to report it. Since many/most devs dont use binpkgs its expected that errors in RDEPEND are there. That could/will be solved with tinderbox checking or other means of automated checks. We need your help since we don't have enough resources to do that by ourselves. Might be i have ideas how to fix but I need to gain some experience with repoman before I present those. Thank you for your offer, I'm looking forward to heard back from you =) lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Help offered - Portage tree
[EMAIL PROTECTED] wrote: Well I'm a newcomer to Gentoo and never heard of Sabayon (great project btw). Knowing no one here or there, nor any history: great never heard project... Smells troll or dumb fan. This conversation reminds me of Human Resources. They always have 'procedures' and 'career tracks.' Gentoo's chitchat about earning gold stars and brownie points is giving me HR sickness. You're asking Michael Jordan to prove himself on the high school team. Empty rhetoric. I've read Gentoo's new dev announcements about monkeys and paper weights. People with a couple of small open-source projects. The monkeys and paper weights get CVS rights. Then the chief architect of Sabayon is scotched over bugzilla output? Please. That smells like bad fish. No, any people is welcome to contribute to gentoo, as long rules are respected. IFF you want to be a dev, you MUST do the quizzes. It takes about one day (5 hours) to do them all if you want. When someone as expert as this offers help, take it and make him a fast lane. Nobody proved us he is an expert. You shouldn't assume. He is worth ten bugzillas. Are they in the same tune of internets? Like a scientist once told me - it would be inefficient for him to clean his office, they have janitors for that. Bad example and non consequential. (BTW: pigs do not count as scientists) Bugzillas are broken and most Linux people know it. Issue tracking is the _ONLY_ way to make sure at least you know what is going on. Ubuntu has hundreds of bugs sitting around for years and years. And? We aren't Ubuntu, yet knowing that you have long opened bugs is way better than being oblivious about them (and nothing is preventing others to propose fixes) Personally: I have stopped filing bugzillas at various places. Please quit as well exploiting our software. Projects organized around bugzillas are inefficient. Care to backing up this claim? Issue tracking is needed. Bugzillas are mostly good for non-devs to report bugs. I know zero developers who first think to themselves, "ok, I need a project bugzilla...then I can begin writing code." That isn't how development works. You aren't a developer, for LScube I FIRST set up git roundup(it's an issue tracker like bugzilla) and a completely new website, then I managed to get mailing lists and irc channel. "So you don't have time to file bugs but you would have time to fix them" is rhetoric. The issue is ROI. Why file bugzillas that some "dev" authority figure may or may not fix in two years, when you can fix the code yourself? You aren't following... IFF you want to be a dev you apply for it like any other guy interested. IFF you want a bug fixed you report it properly using the tools for that: bugzilla. If you want to call him a Gentoo developer, then do so ASAP, and give him CVS. He knows what he is doing and filing bugzillas is a waste of talent. If you let him fix his own bugzillas he might go for that. You aren't supposed to know anything since you: - are a gentoo newcomer (welcome btw) - you don't know anything about Sabayon Gentoo needs the manpower and blowing it off with HR excuses is really, really dumb. Informed judgments are better, isn't it. I can hardly believe what I'm reading. Me too. It makes me want to cry. Take a tissue. Maybe I should help Sabayon deploy on PowerPC instead of writing to you guys. You are free to do whatever you want. I don't really care who misunderstood whom, or who has an attitude problem. There needs to be a red carpet for people like this. NO, he managed to piss off MOST of the developers, he hadn't prove himself to us beside being a legend on #gentoo-releng, he exploited our work giving headaches back like people lying about their setup on bugzilla. I would not care if he had a 666 on his head. I'm not discussing his fashion tastes. You need to attract people like this and if bugzilla isn't working, think up something new. No, we don't need people rushing solutions that may or may not be: - half backed - clashing with the Gentoo way (the 3-4 things that make working with Gentoo different than working on say... Debian rebuilding apt packages) If you dislike his CVS mods you can always revert, take votes, etc. But I say +1 let him have at it. Doesn't work like that, our cvs must be stable, you have a relatively narrow window between syncs to the mirrors and if you make a mistake and don't fix it within that time, users will suffer. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [RFC] net-libs/xulrunner-1.9 slotting or not?
Duncan wrote: Unslotted xulrunner seems to be the consensus, so we aren't committing to "forever" maintain patches ourselves -- on a package-base that may well expand over time. The consensus is to have updated applications, the new xulrunner seems quite an improvement so make _quite_ sense move towards it. Some questions. What's the possibility of getting upstream to handle the renaming, thereby making slotting much easier while eliminating the "eternal" patch commitment? Has the issue even been brought up with mozilla-upstream? I know they aren't always the most receptive to community suggestions, but it's worth asking, anyway. Discussing with upstream this would be good as well, BUT you shouldn't rely on that. How many packages are we talking about? A list had been produced already and is relatively short and some are just nsplugins (and those shouldn't require a change) lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: New build types
Steve Long wrote: Something that's been discussed on IRC is the idea of a .pbuild file, written in Python. I can also think of .cbuild (C) .Cbuild (C++) .sbuild (Scheme) .hbuild (Haskell) and .jbuild (guess;) as being of immediate use, (although I accept I might be the only one interested in the first ;) I do not see any improvement per se. How do others feel about such an addition? I think it's pointless. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] PostgreSQL Status
Tiziano Müller wrote:
What do the new ebuilds offer:
a) A split into dev-db/postgresql-{base,server,docs}.
WRONG we aren't debian.
we have a nice use for documentation...
Now, I know that
splitting up packages isn't the Gentoo way. I know we could have done it
using USE flags but this approach gives more flexibility due to the current
way how binary packages are being generated and distributed.
It gives an annoyance please reconsider.
b) New virtuals: virtual/postgresql-{base,server} to be able to install
pgcluster as your postgresql-base in a next step.
see before.
c) Slotting: It is now possible to have more than one major version of
PostgreSQL installed and running on the same machine.
Great =)
d) A lot of other improvements, in detail, the following bugs will be fixed:
Wonderful =)
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] PostgreSQL Status
Enrico Weigelt wrote:
* Luca Barbato <[EMAIL PROTECTED]> schrieb:
Tiziano Müller wrote:
What do the new ebuilds offer:
a) A split into dev-db/postgresql-{base,server,docs}.
WRONG we aren't debian.
It's bad, just because Debian does it ?!
Sounds quite religions to me. I don't like religions interfering with
technical designs.
Other way round.
Gentoo has useflags to provide what binary distribution (debian pointed
as its one of the best in their field) do by butchering the packages.
The only good reason to split a package is if takes too much to build
and you have a clean way to do that (e.g qemu and kde) (then we provide
meta packages to give back what people expect from emerge foo)
If upstream package its stuff in a way it's better to work with them to
accomodate different needs, butchering leads to annoyance on our side
and their.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Linux 2.6.25 info
Daniel Drake wrote: 2.6.25 was released today, gentoo-sources-2.6.25 is now in portage. As usual this will break some packages in the portage tree (ones that include kernel code), the tracker for such issues is here: http://bugs.gentoo.org/show_bug.cgi?id=218127 Jakub normally does a wonderful job of herding all such bugs, but it looks like he isn't around at the moment. Please help out by adding your bugs there, assuming that your package is in the stable tree and the current stable one works on 2.6.24. As usual I hope to start thinking about 2.6.25 stabling in 3 weeks time (that'll be May 8th) but this is of course subject to the state of affairs when we get that far :) Daniel People using ati-drivers (and possibly other external drivers) as usual do not upgrade if you aren't ready to help fixing the drivers. ^^ lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: PostgreSQL Status
Tiziano Müller wrote: Luca Barbato wrote: It gives an annoyance please reconsider. Done that. Won't change. See my answer to dberkholz's message. As long you keep a meta package, as you told in the reply I read just now, seems a good plan in the end. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Removing .la files...
Wulf C. Krueger wrote: Hello! I think flameeyes should have sent this himself in the first place, but since he's clearly not going to do that and prefers to just force it on our users I'm mailing this... flameeyes talked about .la files in his blog recently: http://blog.flameeyes.eu/articles/2008/04/14/what-about-those-la-files Now he decided that simply removing them for several packages, resulting in http://bugs.gentoo.org/show_bug.cgi?id=218286 and its dupes. This is annoying for quite a few users as they will have to rebuild lots of stuff for KDE, Gnome and other packages and I'm not sure if this is really the way we want to fix --as-needed failures. That or just remove the other .la. Furthermore, such things should not be decided and pushed through unilaterally but be agreed upon here prior to doing this change. Agreed, even if it is relatively low profile IMHO. Especially since even though removing .la files might make sense (with exceptions, of course) we should think about either doing it distribution-wide or not at all. I'll put as item for the council meeting if we don't reach consensus before. In the other news I advise to start asking library upstreams to provide pkgconfig files (and/or push patches providing that). lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Removing .la files...
Alistair Bush wrote: ++. I actually have no problem with agreeing with it, currently my problem is the complete and utter lack of any _planned_ upgrade path. What do we think users are going to be saying at the end of the year when after every sync they have to revdep-rebuild. Maybe, if we proceed with this, we investigate what can have its la files removed and do it all in one go. therefore ppl won't have to rebuild kde/gnome ( or any other large and time consuming package) over and over and over and over and over and over ... again. Hell it would even be better to "batch" a few conversions so that each revdep-rebuild fixes multiple breakages in one. Call that an experiment, do not start screaming but just try to help a bit. I think we could have those change masked now and unmasked once we got something sorted better. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
Ciaran McCreesh wrote: Really, it seems to be an additional type of dependency that neither DEPEND or RDEPEND fully describe, and this DEPEND+RDEPEND idea isn't quite capturing it either. Yup, and for future EAPIs labels can fix this. But we have to have a sound solution for current EAPIs. Usually I rather see the specific problem before looking for solutions. If packages intertwine in strange ways _maybe_ we could work with upstream to fix the insanity at the source instead host it ourselves. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
Ciaran McCreesh wrote: cat/a-1: RDEPEND cat/b cat/b-1: RDEPEND cat/a This is solvable. If package managers can't solve this, they can't install Gnome off a stage 3... Which are the packages involved in such cycle? lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] config_eth0 deprecated - new name?
Roy Marples wrote:
On Thursday 24 April 2008 00:01:01 Robin H. Johnson wrote:
The problem in this is that you cannot set the properties for each
address or route. Please don't take us back to the stoneage of writing
the advanced networking configuration manually.
As an example of an ip address line with properties:
${ext}.30/32 broadcast - scope host
Correct as usual. However, the existing config_foo isn't going anyway anytime
soon, so your power user config still works.
However, it will be moving to the right place
ifconfig_eth0
ip_addr_eth0
Looks like some documentation could be useful.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] DevRel policy update
Wulf C. Krueger wrote: How to gain power the easy way and obsolete conflict resolution in just one commit: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/devrel/policy.xml?r1=1.18&r2=1.19 Those are quite strong words. As grobian said it doesn't change at all what has been the normal way to address certain situations. The council has the last word as usual and the council can ask infra to perform such tasks. We spend time on gentoo not because we seek power but because we like help improving something we consider valuable. Having an extrema ratio/last resort in order to protect it isn't that uncommon. Council was notified in advance of the written policy change and approved it. musikc never abused her position and I'm confident she won't in the future. On the other hand we got MANY complaints about your behavior lately. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: language bindings as separate packages
Enrico Weigelt wrote: My suggestion: make those language bindings being separate packages. So, other packages can depend on them directly, instead of the current, build-breaking hack. I'm not advocating gentoo should do this step alone, but instead join in the upstream and solve it there. The issue is upstream related, we can workaround it using a way to express that requirement (usedeps, checks in pkg_setup, whatever), obviously trying to cooperate with upstream in order to get the optional bindings build w/out the main program would make our life simpler and probably their as well. Partial builds are quite a problem since they are anything but reliable. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Automagic dependencies in gegl
Hanno Böck wrote: Now, gegl has 13 optional dependencies that could be use-flagged. The pity is, it has no configure-option for most of them, they are autodetected. (It's about gtk, ruby, lua, cairo, pango, libpng, openexr, rsvg, sdl, asciidoc, enscript, graphviz and ffmpeg) whoah! Quite a large number!. My experience with the gimp developers in the past was that they weren't very pleased by bugs about automagic deps and I assume if I post them without patches, they'll get closed immediately. Now I always avoided to dig too deep into autotools, so I don't feel skilled enough for this task. Ping me and we could work out something, probably the best way would be hack a PKG_CONFIG_CONDITIONAL that does whatever the canned pkgconfig does+ adding the --enable option. Is there some brave gentoo dev (or non-dev, doesn't really matter) volunteering to send patches to gegl-upstream? We could teamwork having some autostuff monkey doing part of the work, you helping us trying out the result and whoever has better contact with upstream could try to get the thing there. Beside, I'm asking myself how to handle this situation. Hard-enable them all as long as there are no patches? Let the automagic go in the tree? Opinions welcome. Where is the ebuild, put it as is hardmasked with a note about this, then we could work together on it. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Automagic dependencies in gegl
Enrico Weigelt wrote: * Luca Barbato <[EMAIL PROTECTED]> schrieb: Hi, Now, gegl has 13 optional dependencies that could be use-flagged. The pity is, it has no configure-option for most of them, they are autodetected. A good example for miserable design ;-P That's why I everything should be entirely built in sysroot. My experience with the gimp developers in the past was that they weren't very pleased by bugs about automagic deps and I assume if I post them without patches, they'll get closed immediately. Now I always avoided to dig too deep into autotools, so I don't feel skilled enough for this task. Ping me and we could work out something, probably the best way would be hack a PKG_CONFIG_CONDITIONAL that does whatever the canned pkgconfig does+ adding the --enable option. I strongly advise against this. The clean way is to fix the package. (it's build scripts). I'm doing so in the OSS-QM project, eg. for Mozilla ... That is the plan, you produce a simple m4 macro that does for you once and then apply it every time you have a bare pkg check. I'd like to invite you to the OSS-QM project - let's do all the cleanups there and provide overlay by patch, so all distros now just have to pick their right configure args. http://oss-qm.metux.de/ I'll have a look soon. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: qemu -> add gcc-3.x dependency
Enrico Weigelt wrote: Hi folks, I'm just installing qemu, which requires gcc-3.x for building. The current breaks are very ugly, IMHO. So I'm proposing to add the old gcc-3.x as depedency to qemu, at least as long as it doesn't build w/ newer gcc. What do you think about this ? that qemu is a sore exception, you should help upstream porting to gcc-4 if you have time, every people concerned should. Nowadays most of the work left to be done is _pretty_ boring and _pretty_ simple so everybody could help patching ^^ lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: lzma tarball usage
Mart Raudsepp wrote: Hello, Over the course of this year, a lzma-utils buildtime dependency has been added to a few system packages, to handle .tar.lzma tarballs. This has huge implications on the requirement of the system toolchain, which is highly disturbing from a minimal (lets say embedded) systems concern - lzma-utils depends on the C++ compiler and the libstdc++ beast, while a minimal system would like to avoid this at all cost. I'd rewrite the C++ code in plain C if isn't that complex... lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] am I ready to step into Gentoo?
Santiago M. Mola wrote: On Tue, May 20, 2008 at 7:20 PM, Federico Ferri <[EMAIL PROTECTED]> wrote: my computer-related hobbies (or I should say time-killers!) are Tcl (scripting language) and Pure-Data (multimedia dataflow environment). I regularly use Pd to create audio/video apps, and Tcl for everything else that doesn't fit Pd, I've also developed a Tcl-Pd loader, that allows to code externals for Pd in Tcl. see my Pd page at [3]. perhaps that's the category I should belong to...(?) I keep occasional contact with Tcl developers, so I could bring some love to the Tcl/Tk Gentoo herd (yes, I am a Tcl/Tk fan, as you can see on my wikipage at [4]) I've also set up an overlay (pd-overlay, [5]) and used to develop together with ColdWind (actually a Gentoo dev) ebuilds for EVERY pd external! [...] so what's going to be my next step into Gentoo? perhaps finding a mentor? ColdWind would you...? any one else? I'm in contact with Federico, we agreed that the recruitment process will start when the exams are over, but he's going to start slowly working on it before. I could help if you need. I think he can do good work on tcltk, and who knows if he'll work on bringing PureData to Gentoo too! Additional points if he makes coccinella work on non x86: - requires getting tile and treectl in portage - requires hacking a bit the coccinella sources lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] FRC: debtools herd creation
Peter Volkov wrote: В Птн, 16/05/2008 в 11:19 -0500, Yuri Vasilevski пишет: I'll be adding things like debhelper, lintian and a little bit later things like apt, aptitude, cdebootstrap, debian-live and some more. If you ever will need lockdev ebuild, don't waste your time. Take it here: http://overlays.gentoo.org/dev/pva/browser/dev-libs/lockdev/ I needed it as I wanted to try schroot but after some attempts (without much luck) and I've went with writing my own script to manage chroots. did you publish it? If works better than schroot maybe others could enjoy it ^^ lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
David Leverton wrote: On Friday 30 May 2008 17:29:49 Diego 'Flameeyes' Pettenò wrote: This really is backward, solution-wise: you expect the "core application" to know enough of the plugins to link them together, but not enough to call their init functions... Why should it call their init functions, when a static object with a constructor can do the job just fine? Talk to the upstream about this, probably getting a satisfying solution isn't that difficult. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?
Ciaran McCreesh wrote: --as-needed is fundamentally broken by design and causes legitimate code to break. Basically C++ quasi-standard corner cases nobody uses, that happen to work on ELF only and that should be removed in the next revision of 0x ? Implicit plugin loading isn't exactly a sane thing. lu - less excuses to laziness please. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
Ciaran McCreesh wrote: On Sat, 31 May 2008 00:47:44 +0300 Mart Raudsepp <[EMAIL PROTECTED]> wrote: Paludis is fine with as-needed. But hey, don't let reality get in the way of your pathetic attempts at turning everything into Paludis bashing. It happens to be the only package that I know of that couldn't be fixed to work with --as-needed (fix for others being to actually state linking with a library whose symbols are directly used). I have not heard of anything else. Except that Paludis is fine with --as-needed. Ok, then everything in the tree is covered and we can move to having --as-needed as default. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
Ciaran McCreesh wrote: On Fri, 30 May 2008 15:07:43 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: On 22:53 Fri 30 May , Ciaran McCreesh wrote: On Sat, 31 May 2008 00:47:44 +0300 Mart Raudsepp <[EMAIL PROTECTED]> wrote: The story that matters here is, that a C++ corner case that does not work on 0.01% of packages with --as-needed and breaks on non-ELF platforms, should not cause good things for our users to be shot down. You could say the same thing for -ffast-math... When there's a feature that only breaks one package that we know of, wouldn't it make more sense to enable it globally and add an exception than to do it the other way around? Both -ffast-math and --as-needed make the compiler / linker violate various standards in ways that can't be used safely unless a package has been explicitly designed to work with it. I know exactly which standard -ffast-math violates (IEEE/ISO floating point spec) and how (the man page is quite complete about this), --as-needed doesn't have any warning about this, there isn't any standard that it violates since it's the default behavior at least for 2 platform (one from those who wrote most of the ELF spec...). Point the spec, and the paragraph violated. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
Ciaran McCreesh wrote: I'd bet you could get a pretty long way by shoving -ffast-math into CFLAGS by default before anyone would notice... Non sequitur. We are talking about --as-needed, not -ffast-math. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
Ciaran McCreesh wrote: On Sat, 31 May 2008 01:13:58 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: I know exactly which standard -ffast-math violates (IEEE/ISO floating point spec) and how (the man page is quite complete about this), --as-needed doesn't have any warning about this, there isn't any standard that it violates since it's the default behavior at least for 2 platform (one from those who wrote most of the ELF spec...). Point the spec, and the paragraph violated. ISO/IEC 14882:1998 section 3.7.1 paragraph 2. "If an object of static storage duration has initialization or a destructor with side effects, it shall not be eliminated even if it appears to be unused, except that a class object or its copy may be eliminated as specified in 12.8." Unchanged in the 2003 revision. Is that related to linking? I don't think so. Still, PE and ELF are older than the first C++ spec so, IFF your reading of this chapter is correct, C++ is broken by design. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
Ciaran McCreesh wrote: Linking with as-needed is the stage in which the elimination occurs, and as-needed is the cause of the elimination. So yes, it is related. The linker just does bookkeeping, if there aren't symbols used, the library won't be in the list. Still, PE and ELF are older than the first C++ spec so, IFF your reading of this chapter is correct, C++ is broken by design. Not at all. Read "The Design and Evolution of C++", and you shall see that requiring changes to the linker where necessary for sensible behaviour was considered acceptable, and with good reason. As in "we have a square wheels, let's make routes for them"... Anyway is the book a standard? Is it available as pdf so you can point me the exact paragraph? lu - changing the world so non euclidean aberrations fit isn't sensible -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
Ciaran McCreesh wrote: Which is where the design flaw is -- as-needed incorrectly assumes that the only type of dependency between shared objects is a name dependency. This isn't true with C++ static initialisers. I don't see why should be different than abusing .init in any other language that let you do (ok, C, C++, asm mostly). Unfortunately, the ricers shoving as-needed upon everyone aren't smart Asking people to not do stuff that is unportable (Solaris and PE based systems) seems sensible and not ricing. enough to fix libtool, which is the real problem here, so they go for the thing they think they understand instead, without thinking the implications through -- as-needed, like fast-math, is for programs explicitly designed for it, not for universal use. Differently -ffast-math is setting up a slightly different behavior than the usual standard, --as-needed enforce what is the default standard in determined architectures, thus the exception and the universality are quite reverted. We already started to think how to fix libtool, or at least make it less annoying, removing .la files when they are not necessary. Similarly we started proposing upstream to use pkg-config if they aren't already. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
Ciaran McCreesh wrote: Fact: the underlying issue is a libtool bug. Wrong, it isn't just that, --as-needed and libtool are unrelated. Fact: as-needed does not fix this bug. It attempts to work around it. Wrong, --as-needed does exactly what is supposed to do, precise bookkeeping. Fact: as-needed breaks standard-compliant code. Wrong, --as-needed breaks disputable code that happens to be standard-compliant by a specific read of the standard. The fact the specific code is something wrong from the security/style/maintainability point makes it a bonus. Fact: fixing the libtool bug would give all the benefits purportedly given by using as-needed, without the drawbacks. Wrong, fixing libtool gives other benefits, so it's worth trying to fix it as well. The new autotools and proper usage of them makes life easier so it's worth improving on this side. It's quite simple, Probably but is an empty sentence w/out supporting code. and if there're any of the above that you didn't already know then why are you wasting everyone else's time discussing things in this thread without doing some basic research first? Basically most people is discussing with you since thinks, wrongly, that could be possible take something good from this discussion. The patch you pointed doesn't look complete nor acceptable to upstream as is, yet could help. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)
Peter Volkov wrote: В Птн, 30/05/2008 в 20:28 -0700, Brian Harring пишет: Either way, basically it's coming down to if gentoo wants to follow the definition of 'academic' right, or 'pragmatic' right. Exempting ciaran, vote seems to be pragmatic. Well, although I've asked about problems with having --as-needed by default, I'd better go with academic. C++ is quite common language to ignore its design problems and in the end it's not hard to define LDFLAGS in make.conf. To clarify: - static initializers (as in __attribute__((constructor), so no, it isn't a C++ only feature) have nothing wrong with --as-needed. - ugly code that refers to undefined symbols that are resolved to ones from the main binary and written in the constructor is broken already in systems not allowing undefined refs. - you don't have guarantees about the order in witch the .init sections are parsed and constructor function are called, they can be called in parallel and you have no means to have a predictable behavior, all you know is that everything will be called right before main() or as the first thing in dlopen(). - doing such stuff is uncommon since it isn't the simplest thing to do, doesn't work in every place, you have to be particular perverse and convoluted even to think about this. - making such thing go away is good for security, maintainability and sanity. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for June
Santiago M. Mola wrote: I think we have not enough feedback from users about this. Either Bugzilla is not the right tool, or we don't encourage users enough to ask for keywords when they need them. Currently, some people assume that "if a user from $arch needed this package, he'd have requested keywords", but that's wrong. Good point and probably a good start to find a decent solution about getting the stuff needed by user keyworded but not overwork arch teams. Probably having 2-4 lines about this in the next newsletter could foster awareness. Having a smarter repoman and bugzilla integration to handle stabilization and keyword bugs automagically would be great but I think would require time (since such bugs could spare the dev some trips around bugzie) lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
Josh Saddler wrote: Łukasz Damentko wrote: Hi guys, Nominations for the Gentoo Council 2008/2009 are open now and will be open for the next two weeks (until 23:59 UTC, 18/06/2008). Now that nominations are officially open, I nominate the current council members (again): lu_zero Thank you, I accept. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
Roy Bamford wrote: On 2008.06.05 01:00, Aukasz Damentko wrote: Hi guys, Nominations for the Gentoo Council 2008/2009 are open now and will be open for the next two weeks (until 23:59 UTC, 18/06/2008). Team, I don't want to nominate anyone who hasn't been nominated already. I would like to address all the candidates who have or will accept council nominations. 1. Please tell us how/if you plan to fix GLEP 39. (You may not consider it broken) Alone you cannot do anything. Still I found that there are some parts unspecified like how many meetings and how a meeting has to be announced to be considered official that should be clarified. 2. As one of the first priorities will be setting policy for pending appeals what policy do you propose ? No changes are required in my opinion. 4. How do you think the council and trustees can work together to make Gentoo better? Trustees manage a local entity located in the USA, the council should manage Gentoo as whole. Can they work together to improve Gentoo? Well EVERY developer and to a minor degree every member of the Gentoo community should work together to improve Gentoo, usually do what's within their role. The foundation has to make sure our intellectual property won't get abused in the USA, has to defend our trademark and cope with the bureaucracy related. The Council has to forster activities within Gentoo, to solve deadlocks in discussions by having the last say. My old manifesto is still valid =) lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Piotr Jaroszyński wrote: 1. GLEP54 2. GLEP55 None of them got discussion back in -dev, the glep hadn't been changed as requested during the unnecessary long discussion in the meeting. Looks like the overall consensus is that those aren't useful as they are and thus either you fix them, discussing the changes with the people in -dev (NOT THE COUNCIL) or you may retract them. 3. Most wanted changes in future EAPIs Somebody is thinking the PMS and the EAPI definition as it is are wrong and should be replaced since they aren't useful for their purpose. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Ciaran McCreesh wrote: Anyone thinking that has a very limited understanding of how things work. Usually in this category you put everybody that disagrees with you, no matter the topic. Let's face it, there hasn't been any correct criticism, and any complaints have been from people who don't understand what's going on anyway and who seek to blame EAPI for Portage's lack of progress, rather than blaming Portage's lack of progress for lack of new EAPIs as they should. I'm afraid you are mixing up emails from this thread. I got complaints about how wrongly the PMS is written, e.g. academic paper markup vs plain text, natural language used to specify syntax while a grammar notation like EBNF would be better suited, when I asked people why so few were contributing about this document. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Ciaran McCreesh wrote: I'm afraid you are mixing up emails from this thread. I got complaints about how wrongly the PMS is written, e.g. academic paper markup vs plain text, natural language used to specify syntax while a grammar notation like EBNF would be better suited, when I asked people why so few were contributing about this document. Mmm, and how many people claiming that have suggested specific improvements or pointed out specific complaints? You got some right here. Feel free to address them. So how, specifically, is PMS "wrongly written", and why hasn't anyone who thinks so bothered to provide details? - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml. - use EBNF when describing a syntax. - split it and version each functional part. - define EAPI as an aggregate of those versions in a separate part. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Ciaran McCreesh wrote: On Mon, 09 Jun 2008 10:50:11 +0200 Luca Barbato <[EMAIL PROTECTED]> wrote: So how, specifically, is PMS "wrongly written", and why hasn't anyone who thinks so bothered to provide details? - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml. What technical reason is there to use a markup that's more work for those of us doing the writing? Writing XML is a huge pain in the ass compared to latex. More people can understand those markups, they are consistent with the gentoo documentation, they look better on screen than on paper, tex is a great typesetting markup to write academic books. Right tool for the right task. It address the problem "PMS is anything but accessible" - use EBNF when describing a syntax. Is there any indication that this is any clearer? EBNF gets messy when it comes to describing the whitespace rules, for example. It is less ambiguous than natural language. That solves the issue "The syntax is underspecified" lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Ciaran McCreesh wrote: On Mon, 09 Jun 2008 03:28:03 -0700 Josh Saddler <[EMAIL PROTECTED]> wrote: Global variables must only contain invariant values (see link="#metadata-invariance">link). If a global variable's value is invariant, it may have the value that would be generated at any given point in the build sequence. First, your link is incorrect. metadata-invariance is in a different file. Pointless nit. Second, the link's text should be the section name or chapter number. Rendered as "(see link)" is horribly ugly. your opinion, just yours. Third, you should have a non-breaking space between 'see' and the reference. Pointless nit. How does "bunch o'neat code" deal with our code file containing things that XML considers to be reserved characters? That code probably has ampersands and angle brackets in it. As usual for xml markups. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
Thomas Anderson wrote: As Fabian said it really isn't a matter of "We like XML better than LaTeX!" It's not those people's prerogative. Problems like having homogeneous documentation aren't that small. The people who wrote PMS should be able to make the decision for themselves(as they will be maintaining it) as to what language to use. The main point being using latex prevents people from modify it. If they use LaTeX, more power to them, it's what enables them to do their job in the easiest way. Depends on what the job is. You don't *have* to read PMS in LaTeX, which by the way makes my eyes bleed somewhat, you can read it in a very well done PDF. The pdf renders poorly on xpdf due the fonts latex has, usually I'd rather have plain text anyway. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
Tiziano Müller wrote: Another ugly solution: Having the EAPI on a per-package (like $portagedir/cat/package-1) or per-tree basis ($portagedir/profiles/eapi) I like the per tree basis and I already asked about that (since makes things clearer and older portage can be tricked by rsync. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
Ciaran McCreesh wrote: Kills the upgrade path completely. No good. Not really, you change the rsync paths and older portage will pick a repo that just has the necessary to upgrade to the next portage. This kind of things would work better using an scm supporting branches and tags a bit better. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
Tiziano Müller wrote:
Joe Peterson wrote:
Ciaran McCreesh wrote:
And a file extension is far less obscurely complex than enforcing
arbitrary syntax restrictions upon ebuilds.
I disagree. One is exposed to devs only as ebuild syntax; the other is
exposed in an inappropriate location to everyone looking at the portage
tree.
No it can't. EAPI has to be known before the source can start. Bash
doesn't provide traps for executing code upon changed variables.
Doing it out-of-band solve this.
No, it's only needed once per non-trivial change. So we might as well
just change it for every EAPI.
Huh? If the "new" portage knows how to determine the EAPI definitively
(and that would be defined), it can deal with the differences.
And then how do we deal with EAPI 3, where the syntax changes again?
Portage (or whatever PM) reads the EAPI, determines it is 3, and goes
from there. If you change the way you declare EAPI each time, yeah,
that's a problem, but I'm not sure why that would ne necessary.
No, that is not the problem.
Example:
In EAPI 42 we define that the package manager must provide a global function
extract_depend_from_setup_py() such that it is callable at a global level
in an ebuild like this
*snip start*
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
EAPI=42
DESCRIPTION="A library aiming to support agile and test-driven python
development on various levels."
SRC_URI="http://codespeak.net/download/${PN}/${P}.tar.gz";
HOMEPAGE="http://codespeak.net/py/";
KEYWORDS="~amd64 ~x86"
SLOT="0"
LICENSE="MIT"
IUSE=""
extract_depend_from_setup_py
*snip end*
Now, a package manager (or a tool) not knowing EAPI 42 will fail when it
tries to source the above ebuild to determine the EAPI version (as it is
being currently done as far as I understood it) because
extract_depend_from_setup_py is undefined.
So it won't even be able to read out the EAPI.
With the EAPI in the filename tools now knowing EAPI-42 will either ignore
the above foo-1.0.ebuild-42 or mask it because they may identify the
EAPI-version without sourcing the ebuild.
Check if exists a line EAPI=*$, if does and the rest of the string
matches an understood eapi, go on sourcing, otherwise ignore/mask it...
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 55
Tiziano Müller wrote: ... and package managers which don't do that already still fail. To put everything in perspective all this discussion is done in order to workaround the issue of an old and outdated package manager that cannot be upgraded once it syncs from a too new repository. The simplest way is to change the syncpoint in the new package manager and leave the previous uri with a compatibility repo for the older ones. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 55
Piotr Jaroszyński wrote: The simplest way is to change the syncpoint in the new package manager and leave the previous uri with a compatibility repo for the older ones. So we add a new repo each time a new EAPI comes out? Sounds like a big mess. It isn't you just keep 2 repos, one with the minimal eapi and the minimal set of ebuilds needed to upgrade, one with the latest and greatest. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 55
Ciaran McCreesh wrote: So you're volunteering to convert the entire tree to the new EAPI all in one go every two months? I don't see the need and I won't see the problem given right now what is interesting is the set of improvements that aren't forward incompatible. Being that the case you'd just need 2 trees, managed as overlay and a marker for each tree on which eapi to use, but I dislike empty theories or hardly searched corner cases that could be avoided with half of the effort necessary to get there. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
