Re: [gentoo-dev] SSL-Certificates and CAcert
Andrew Gaffney wrote: Hanno Böck wrote: I think compared to self-signed, having cacert-certificates would be a big improvement. Many other free software projects (and more and more other pages) use cacert, so it becomes more and more likely that people will already have the cacert-root-cert installed. How does a CAcert certificate help? Their own certificate for https://www.cacert.org/ can't be verified by Firefox 2.0.0.7, which tells me that their CA isn't trusted by default. Yes, however a lot of people have their cert imported into their browser and they provide a method for importing the their CA into your browser. Where's the Gentoo CA for me to import into my browser? -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Bugzilla improvements
Robin H. Johnson wrote: I went and processed a bunch of pending Bugzilla bugs, and thought folk might be interested in the changes. - Bug Reporting Guide is now linked from the front page as well as the Choose Product page (during bug creation). [Bug #188687] - The Log In link in the footer should take you back to the same page that you were on (please file a bug for bugzilla@ if it messes up). [Bug #188690] - SH, m68k, BSD in the 'Add Arches' Box. [Bug #178698, #178855] - Favicon fixups. [Bug #184565] - After changing a bug, the default behavior is now showing the updated bug, not jumping to the next bug in your last list. If you don't like this, you should change your own prefs. [Bug #171988]. - Do not reply note at the top of bugmail, and a related Reply-To header. [Bug #181172] - 'emerge info' = 'emerge --info' [Bug #173059] - During guided bug submit, users are asked to include the full package atom in the summary line. [Bug #165976] - Fix javascript bug with content-type selection during attachment of a file and using the drop-down box. [Bug #172513]. - Do not display the banner for text-mode browsers. [Bug #78670] - Dupe box height in strict browsers fixed. [Bug #173158] - Use site-specific link color instead of browser-provided, for visibility when browser default is too light. [Bug #185760] - All internal links should stay on the HTTPS if you go there, and not take you off the HTTPS site. [No Bug#]. Three cheers for robbat2! Only comment is that this really should have been sent to gentoo-dev-announce and then kicked over to gentoo-dev to discuss. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] controlling src_test
Ravi Pinjala wrote:
Ryan Hill wrote:
There are several packages in portage (and even in base-system) that
fail
in src_test when userpriv/usersandbox is enabled or disabled. That
is, some
testsuites fail when run as root and some fail if not run as root.
I'd like a simple consistent way to mark or handle these packages
without
disabling tests altogether (RESTRICT=test). As mentioned recently,
checking
${FEATURES} in an ebuild is frowned upon, and it doesn't seem right
to handle
this on a per-ebuild basis. How would something like this best be
implemented?
A split up RESTRICT (test_userpriv/test_nouserpriv)? test.eclass?
Something
else? Looking at the bigger picture, are there any other situations
where
finer-grained control over the test system would be helpful?
While I'm on the subject, I also thought it would be cool to have
the option to
not die on a src_test failure, but instead to dump the log file and
continue
on to the install phase. I know this can be done per-ebuild, but
it'd be
a useful global option.
I, for one, would like to be able to control whether or not to run tests
that take a huge amount of time to run. Some test suites are
ridiculously comprehensive, and if we could have an option to disable
only those, or even run a reduced test suite, that'd be pretty neat.
--Ravi
Who and what determines if a test is overly comprehensive and takes too
long to run?
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-fs/evms: ChangeLog evms-2.5.5-r8.ebuild
Donnie Berkholz wrote:
On 22:01 Mon 08 Oct , Doug Goldstein (cardoe) wrote:
1.1 sys-fs/evms/evms-2.5.5-r8.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-fs/evms/evms-2.5.5-r8.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-fs/evms/evms-2.5.5-r8.ebuild?rev=1.1content-type=text/plain
epatch ${FILESDIR}/${PV}/md_super_fix.patch
epatch ${FILESDIR}/${PV}/ntfs_unmkfs.patch
epatch ${FILESDIR}/${PV}/raid5_degrade_fix_v2.patch
epatch ${FILESDIR}/${PV}/raid5_remove_spare_fix.patch
epatch ${FILESDIR}/${PV}/raid5_remove_spare_fix_2.patch
epatch ${FILESDIR}/${PV}/raid5_algorithm.patch
epatch ${FILESDIR}/${PV}/cli_reload_options.patch
epatch ${FILESDIR}/${PV}/cli_query_segfault.patch
epatch ${FILESDIR}/${PV}/get_geometry.patch
epatch ${FILESDIR}/${PV}/BaseName.patch
epatch ${FILESDIR}/${PV}/disk_cache.patch
epatch ${FILESDIR}/${P}-as-needed.patch
epatch ${FILESDIR}/${P}-glib_dep.patch
epatch ${FILESDIR}/${P}-ocfs2.patch
epatch ${FILESDIR}/${P}-use_disk_group.patch
epatch ${FILESDIR}/${P}-pagesize.patch
This would be another good candidate for using epatch's bulk patching,
particularly if you moved the last group of patches into the PV
directory.
dev-zero?
I merely fixed baselayout-2 issues and didn't change any functionality
of the ebuild since I don't have an evms setup to test.
mv -f ${D}/$(get_libdir)/*.a ${D}/usr/$(get_libdir)
mv -f ${D}/sbin/evmsgui ${D}/usr/sbin
Quoting
Thanks,
Donnie
Your a bit late. I fixed the quoting issues in the ebuild around 8pm EDT
along with a few other issues. See the -r9 ebuild.
--
Doug Goldstein [EMAIL PROTECTED]
http://dev.gentoo.org/~cardoe/
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New projects
Alec Warner wrote: On 10/11/07, Torsten Veller [EMAIL PROTECTED] wrote: Last council decided: | Design phase for new projects: New projects need to post an RFC | containing information about their goals, the plan on how to | implement their goals and the necessary resources to -dev prior to | creating the project. | | This proposal was accepted with 6 members voting yes and one member | abstained from voting http://www.gentoo.org/proj/en/council/meeting-logs/20061019-summary.txt GLEP 39 was not updated and still says: | Any dev may create a new project just by creating a new page (or, more | realistically, directory and page) in gentoo/xml/htdocs/proj/en. http://www.gentoo.org/proj/en/glep/glep-0039.html This week two new subdirs were added to proj/en. (One was just added for an existing project.) Can the glepeditors update GLEP 39 to reflect the coucil decision? Maybe a new project should also be announced in -dev-announce (and GWN if they want to). I'll get to that now. -Alec Shouldn't it really be a new GLEP that replaced the old GLEP 39? Since the way the GLEP system works, i.e. obsoleted by GLEP ## and we typically don't edit them once their out of draft status. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New projects
Alec Warner wrote: Glep 54 now replaces (and depends on) glep 39. Like the commit message says, the spirit of the glep was approved long ago, if you have issues with wording please to be taking it up with me so we can make it pretty (particularly the backwards compatibility section) -Love antarus you mention using Outlook in another thread and then you top post. What e-mail infraction will you commit next? Writing e-mails in all caps? Sending e-mails with blank subject lines? -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Possible USE=gnome abusing in ebuilds.
Samuli Suominen wrote: Hi, Recently, I've edited or bumped some ebuilds which had USE gnome in them but it was actually doing something entirely different in them, like latest edition of media-libs/raptor had USE gnome pulling in glib which it was using for unicode purposes (so USE unicode was natural choice but only gnome users had it until now) I'm not pointing or blaming anyone but next time you edit an ebuild which is using USE gnome please check what it is actually doing and note that GLIB and GTK+ is NOT gnome Thanks, drac Kinda like the GNOME herd does themselves? I've pointed this one out a few times just cause it annoys me... gnome-mount has USE=gnome... well... DUH! it's a gnome-volume-manager specific and GNOME Desktop specific wrapper for HAL based mounting. Obviously it's used by GNOME and only does and can function within a GNOME Destkop environment. But what does this USE flag mean? Oh, it simply means you want to build the Nautilus extension! Do we already have a USE=nautilus? Yes, yes we do. It's a local USE flag used in 3 packages, 2 of those 3 are GNOME herd packages. Either way, the Gentopia copies of gnome-mount continue to use a nautilus USE flag. Maybe someday, the light will shine. Since body language and tone do 90% of speaking and words only do 10%, I would like to just point out that the sarcasm of this e-mail is intentional but not meant to be insulting. It's merely a point highlighting the fact that a non-GNOME herd member made a request that the GNOME herd should make and the herd should stick to. -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild
Donnie Berkholz wrote:
On 18:55 Fri 12 Oct , Doug Goldstein (cardoe) wrote:
1.1 media-tv/mythtv/mythtv-0.20.2_p14668.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-tv/mythtv/mythtv-0.20.2_p14668.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-tv/mythtv/mythtv-0.20.2_p14668.ebuild?rev=1.1content-type=text/plain
use alsa || myconf=${myconf} --disable-audio-alsa
use jack || myconf=${myconf} --disable-audio-jack
use dts || myconf=${myconf} --disable-dts
use freebox || myconf=${myconf} --disable-freebox
use dbox2 || myconf=${myconf} --disable-dbox2
use hdhomerun || myconf=${myconf} --disable-hdhomerun
use crciprec || myconf=${myconf} --disable-crciprec
use altivec || myconf=${myconf} --disable-altivec
use xvmc myconf=${myconf} --enable-xvmc
use xvmc use video_cards_via myconf=${myconf} --enable-xvmc-pro
use perl myconf=${myconf} --with-bindings=perl
myconf=${myconf}
--disable-audio-arts
$(use_enable lirc)
$(use_enable joystick joystick-menu)
$(use_enable dvb)
--dvb-path=/usr/include
$(use_enable opengl opengl-vsync)
$(use_enable ieee1394 firewire)
--enable-xrandr
--enable-xv
--disable-directfb
--enable-x11
--enable-proc-opt
How come some of these don't use use_enable()?
Because if you pass the inverse the script blows up. It's ffmpeg's
configure script that's a hand written script and modified by the MythTV
developers.
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild
Donnie Berkholz wrote: On 00:12 Sun 14 Oct , Doug Goldstein wrote: Because if you pass the inverse the script blows up. It's ffmpeg's configure script that's a hand written script and modified by the MythTV developers. Sigh. Any chance of getting things to move to autotools? Thanks, Donnie Donnie, In my 4 years of experience with this package and maintaining it and contributing patches upstream. You don't think I've suggested it? You don't think I've tweaked this ebuild to work as best as possible for our users? I know the other thing I didn't answer was the fact that some variables aren't quoted. It doesn't matter at all considering their configure script can't handle spaces in the path names anyway. We've been though that already. Additionally, qmake can't handle spaces in there even if you do quote so it really doesn't matter much. Some of these review changes truly feel like working at a company where you know the ins and outs of your tool. You can rattle off its capabilities to a millimeter. A new boss/manager comes in and has no idea what the tool is or the mission but by god he knows how to do your job better and you will follow his procedures. It makes no difference if his steps have no effect on the tool and waste more of your time. You additionally have to start giving him progress reports on how you're doing using his procedures, which instantly means you get less work done. That's what this commits review list feels like. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild
Jonathan Adamczewski wrote: Doug Goldstein wrote: That's what this commits review list feels like. Nearly every suggestion (from Donnie and others) has been over some issue that relates directly to either correctness or maintainability. It doesn't matter if you can rattle off capabilities to a millimeter - if they're not documented somewhere (like, say, in the comments of the ebuild) then the maintainer that comes after you gets to go and break it all over again. jonathan. Correctness? Fine. Go ahead. Stick $(use_enable xvmc) into the ebuild. Do it. I dare you. Then try to compile. Guess what? When it blows up... that's called INcorrect. The opposite of the right thing. The maintainer who comes after me would be someone with a experience with the package. Some bumkin isn't going to come to maintain package XYZ unless they know or use the package, and guess what? That means experience. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild
Alec Warner wrote: On 10/15/07, Doug Goldstein [EMAIL PROTECTED] wrote: Jonathan Adamczewski wrote: Doug Goldstein wrote: That's what this commits review list feels like. Nearly every suggestion (from Donnie and others) has been over some issue that relates directly to either correctness or maintainability. It doesn't matter if you can rattle off capabilities to a millimeter - if they're not documented somewhere (like, say, in the comments of the ebuild) then the maintainer that comes after you gets to go and break it all over again. jonathan. Correctness? Fine. Go ahead. Stick $(use_enable xvmc) into the ebuild. Do it. I dare you. Then try to compile. Guess what? When it blows up... that's called INcorrect. The opposite of the right thing. The maintainer who comes after me would be someone with a experience with the package. Some bumkin isn't going to come to maintain package XYZ unless they know or use the package, and guess what? That means experience. I think this assumption is false. People maintain packages they don't know the intricate details of all the time. You are of course, free to ignore any and all suggestions offered; but you are not allowed to silence them. -Alec I must have not received my silence/moderate remote control for the Gentoo mailing lists. Since I haven't received it, I clearly can't silence anyone on the mailing lists. I still stand by my original feeling that we'd better the community NOT only the developers doing the commits by updating the devmanual, which is accessible to all developers and all users in the Gentoo community. In addition to updating and cleaning up repoman checks, which is a tool that everyone in the community can use. This is versus individual examples in random ebuilds in random e-mails that all have almost an identical subject on the mailing list. The commits review is flawed because if we're not documenting this stuff in one central place, then when new developers join. The same lessons have to be learned over and over again. Then again, this depends on the QA guys actually doing something about the outstanding bugs. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild
Christian Faulhammer wrote: Doug Goldstein [EMAIL PROTECTED]: Jonathan Adamczewski wrote: Doug Goldstein wrote: That's what this commits review list feels like. Nearly every suggestion (from Donnie and others) has been over some issue that relates directly to either correctness or maintainability. It doesn't matter if you can rattle off capabilities to a millimeter - if they're not documented somewhere (like, say, in the comments of the ebuild) then the maintainer that comes after you gets to go and break it all over again. Correctness? Fine. Go ahead. Stick $(use_enable xvmc) into the ebuild. Do it. I dare you. Then try to compile. Guess what? When it blows up... that's called INcorrect. The opposite of the right thing. You were kindly asked if is not possible to use, so why do you feel attacked? Do a comment on it and everybody would be fine, even the people that would have to maintain it some time in the future. If you don't like the review process, just ignore it. Reviews are not a way to show what kind of idiot the committer is, but to improve the overall quality of the tree. Nothing more, nothing less. No. You clearly don't understand where I'm coming from. I think the commits review is pointless and a waste of resources that could be better used doing other things. Since commits review is a cyclic process you will never achieve a perfect state that all developers commit perfect ebuilds to the tree since new devs come and go. And since we don't document any of this stuff properly in the devmanual, incoming devs have to constantly relearn the same lessons that previous incoming devs learned through the review process. Effective workers work in 4 stages, we're effectively with this approach remaining in stage 1 and never progressing and admitting we will never progress. The maintainer who comes after me would be someone with a experience with the package. Some bumkin isn't going to come to maintain package XYZ unless they know or use the package, and guess what? That means experience. Yes, and the same goes for GNU Emacs, I needed some time to figure out what all those things did and I broke it several times because I tried to be clever. Now we documented it and I think everyone coming after us will have a less hard time to understand it. Better document it, you never know what happens. V-Li Read the ChangeLog. It's there for a reason. It provides valuable knowledge and information about the package. I would expect any developer worth their salt to at least brush up on the ChangeLog for any package they are taking over. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/sandbox: ChangeLog sandbox-1.2.18.1-r1.ebuild
Donnie Berkholz wrote:
On 15:55 Wed 17 Oct , Daniel Drake (dsd) wrote:
1.1 sys-apps/sandbox/sandbox-1.2.18.1-r1.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/sandbox/sandbox-1.2.18.1-r1.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/sandbox/sandbox-1.2.18.1-r1.ebuild?rev=1.1content-type=text/plain
keepdir /var/log/sandbox
fowners root:portage /var/log/sandbox
fperms 0770 /var/log/sandbox
cd ${S}
dodoc AUTHORS ChangeLog NEWS README
}
pkg_preinst() {
chown root:portage ${D}/var/log/sandbox
chmod 0770 ${D}/var/log/sandbox
}
How come you need to repeat the permissions like this?
Also, quoting. =)
Thanks,
Donnie
Also, pkg_preinst() is not binary package safe. So unless the portage
group is always the same gid on EVERY Gentoo box. This will break binary
packages.
--
Doug Goldstein [EMAIL PROTECTED]
http://dev.gentoo.org/~cardoe/
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Resolving HAL vs. pciutils/usbutils
Daniel Drake wrote: Robin H. Johnson wrote: Heya, So now this is not a flamewar. Jakub was originally going to complain at me for the upstream usbutils adding support for gzipped usb.ids files, but a group of us (myself, dsd, jakub, leio, steev) had a discussion about it, and came up with a solution that both ends the breakage for direct users (HAL and others), and provides forward momentum. So firstly, what's the real problem? The original complaint came up because HAL expected the uncompressed file to exist as pci.ids, and wasn't ready to look at pci.ids.gz. While this caused breakage, it was only a warning sign that there was a deeper problem. I don't feel strongly enough to make an objection to your commit, but I think pciutils is doing the right thing, and despite me and Mike putting a hours into getting a decent HAL patch together the response I got was that as upstream they are simply not interested (no technical or logical objections provided), so I don't feel you should be putting workarounds in pciutils just to make HAL happy. Daniel Daniel, That's a LOAD of garbage and you know it. You're just straight away making up stuff, essentially lying. You know damn well what the reasons were since they were explained to you on numerous occasions. When HAL evaluated the usage of libpci the following issues were identified: 1) increased memory usage, to the point that HAL was not usable on the OLPC project 2) ABI breakage between patch revisions (i.e. x.y.z and x.y.z+1 were not ABI compatible) 3) no shared library 4) the library calls exit() when it encounters an error in parsing it's own pci.ids file which would kill the whole app using it. There might have been more. I don't remember. Refer to ML discussions and refer to IRC logs with me. Now Mike (vapier) rectified #4 several pciutils releases ago by providing a callback function that we could define which would override the default exit() behavior. I still think it's sub-par to have an utility library call exit() by default but whatever. You were told by me and the HAL ML that once #2 and #3 are rectified and if you could provide some basic memory usage information along with your patch (i.e. show #1 isn't true anymore) that we would happily accept your patch. Now #2 and #3 are still not true in the latest release. There is no guarantee by the pciutils maintainers that they will maintain ABI compatibility while keeping the same .so version number. And there is still no shared library built. You addressed #1 on the mailing list with a simple statement, which I will paraphrase. It doesn't use more memory on my machine. To which Danny K asked if you could provide some basic data behind that and you never did. As a result, 3 out of 4 concerns with your patch and pciutils were never addressed and the issue was dropped on the HAL ML pending more feedback. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New USE flags documentation
Jose Luis Rivero wrote: Hi all: I've read on the planet the recently included support to document USE flags in metadata. Seems like it was an idea from flameeyes and cardoe, discussed on the planet [1][2] and performed by -infra (bug #199788). While planet is a good medium to share ideas and get contributors, seems to me like we need a more official way to discuss this kind of 'global' ideas before make them real. Or at least drop a note on -dev-announce explaining the new feature and telling devs and users this is now officially supported. Thank you for taking the time to announce it to gentoo-dev since I haven't had the time with my family being here for the holidays to do such. I'll take care of the e-mail to gentoo-dev-announce though. I'm not asking for an extra overhead of 'bureaucracy' (write specs, mailling @dev, send to the council, etc.) but a bit more of communication would be appreciated: All the above is completely unnecessary and I would be happy to discuss details with you off list. Is the feature ready to be used? Is there any kind of documentation (aside of DTD)? It will replace use.desc? Well the first question you answered yourself. You linked to a post I wrote describing live commits I made to the tree using this feature. As far as documentation, you will find that in your Gentoo Developer's Handbook [3], but most likely you'll say But Doug, I don't see anything on these new changes. That's because the new changes have not been updated yet, again with the holiday's about it takes a little bit to get things done. Once the documentation is updated I had planned on sending an e-mail to gentoo-dev and gentoo-dev-announce. As far as replacing use.desc, that is doubtful but a possibility of replacing use.local.desc is within consideration. However this would be in the distant future and we would have to see how the new features are used and evolve. Thanks. [1] http://farragut.flameeyes.is-a-geek.org/articles/2007/11/24/proposing-more-use-flag-documentation [2] http://blog.cardoe.com/archives/2007/11/23/metadataxml-updates-examples/ [3] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=4 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] eselect
Christian Faulhammer wrote: Hi, is anyone working on eselect? V-Li peper told me he'd wrap up a few bugs and make a release this week after I was about to go touching eselect all over when we know my C/C++ is better then my bash. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
Thomas Anderson wrote: On Wednesday 05 March 2008 14:41:32 Petteri Räty wrote: Thomas Anderson kirjoitti: Please elaborate on how a full.fledged developer would differ from a package maintainer technically. What requirements and/or priviledges do you think could be reduced? Marius Perhaps there could be some honor code system at least, where the package maintainer would be restricted to their area of maintainership. This is the current situation. Regards, Petteri Exactly, only the package maintainers wouldn't have everything that a full dev would have... What exactly wouldn't they get? What would differ them from Arch Testers? -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
Thomas Anderson wrote: On Wednesday 05 March 2008 14:59:55 Doug Goldstein wrote: Thomas Anderson wrote: On Wednesday 05 March 2008 14:41:32 Petteri Räty wrote: Thomas Anderson kirjoitti: Please elaborate on how a full.fledged developer would differ from a package maintainer technically. What requirements and/or priviledges do you think could be reduced? Marius Perhaps there could be some honor code system at least, where the package maintainer would be restricted to their area of maintainership. This is the current situation. Regards, Petteri Exactly, only the package maintainers wouldn't have everything that a full dev would have... What exactly wouldn't they get? What would differ them from Arch Testers? Arch Testers don't have tree access. This proposal gives the package maintainer the ability to commit their changes. So what you're looking for is committer ACLs. Gentoo's CVS currently does not use any form of ACLs to restrict access. This proposal would have to be discussed with the infra team to consider the feasibility to add ACLs to the tree. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [Fwd: Re: [gentoo-core] Keywords policy]
Bo Ørsted Andresen wrote: On Tuesday 11 March 2008 16:55:11 Ferris McCormick wrote: Now that I've said I'm tired of this thread, let me add to it. I'd like to add one more point, namely: * Please explain in the ChangeLog what you are doing and why. In this case, if I look at kdelibs for example, what I see is Version bump to KDE 4.0.1 which looks pretty harmless. A couple lines explaining that it is package.masked because it doesn't actually work might have been helpful. Do you really think that should go into the ChangeLog of all 208 packages? Personally I would have thought the package.mask message would be sufficient... considering you can do the following: $ echangelog Version bump to KDE 4.0.1. This is a major version change, please review package.mask for details. and for the other 207 packages you do $ !echan it sounds more like laziness on the part of the KDE team. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] OpenRC baselayout-2 meets Gentoo
All, This is a formal notice to everyone that OpenRC will be hitting the Gentoo tree sooner rather then later. I would like to see *ALL* arch teams give the current code a whirl on their systems, which is available via the layman module openrc. I would also like to give the docs team a chance to weigh in here and work with me on a migration guide as well as any necessary updates. That being said, I will be the primary point of contact on the transition to OpenRC appearing in ~arch (along with it's associated baselayout-2.0.0 ebuild). Any and all grievances, concerns, suggestions and comments can and should be routed to me via the associated Bugzilla entries or e-mail. I do not want OpenRC to come as a surprise to anyone and break their system. I expect we will leave no stone unturned and go for a very smooth transition. That being said, the bug for the addition of OpenRC is #212696 [1]. The bug for the documentation is #213988 [2]. Lastly, I will be out of town March 21st through March 23rd. I will not have IRC access but I will have e-mail and Bugzilla access. https://bugs.gentoo.org/show_bug.cgi?id=212696 https://bugs.gentoo.org/show_bug.cgi?id=213988 -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo
Roy Marples wrote: On Thursday 20 March 2008 06:59:24 Josh Saddler wrote: I'll be working on the migration guide with Cardoe (and possibly Roy, if we can tag-team him into submission). As much of a pain as migration will be, we'll definitely need a howto. Fun, fun. I already provide documentation with commands in example config files and man pages that cover nearly every aspect on OpenRC and all it's commands. The nice thing about not being a Gentoo dev means I don't feel the urge to write a migration how to. However, here's a really good primer. 1) Install OpenRC 2) Review all updated files in /etc/conf.d/ and /etc/rc.conf [1] [2] 3) If using a volume such as LVM, you'll find an appropriate init script in /etc/init.d that you need to add to the boot runlevel. 4) Carry on as normal [3] Thanks Roy [1] The case of variable names has been changed from UPPER to lower. This is for a few reasons (removes confusion vs environment vars, looks nicer). However, *existing* UPPER case vars should still work. [2] Paludis users will need to ensure that the init scripts checkfs and checkroot are removed. I don't care whose bug this is, but neither side wants to fix it. [3] A reboot is currently needed as for some reason state data isn't migrated from baselayout-1. This is probably due to OpenRC being split from baselayout and the code is pretty much the same here. Maybe some plucky Gentoo ebuild dev can step up and fix it. You missed the whole /etc/modules.autoload.d/* - /etc/conf.d/modules but I already discussed that with Josh for the guide. ;) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo
Josh Saddler wrote: Doug Goldstein wrote: It appears my migration plan was not good enough for Mike Frysinger [EMAIL PROTECTED] and he went ahead and wrote his own version of the OpenRC ebuild, differing from the one in the OpenRC layman repo, and committed it to the tree this weekend. Since my offer to work on the migration was not good enough for him, I'm backing out and allowing him to handle the whole migration himself since I haven't heard from him at all despite Roy (author of OpenRC) and my attempts to contact him for 2 weeks regarding a migration plan for OpenRC. All issues and comments can be directed to him. I guess working together and documenting everything before having it hit the tree was a bad plan and it had to be one-upped. Well, *somebody* had better get their act together and talk with me about the migration document. I don't care about the ebuild so much as I do about making sure there's a howto for the migration process. If baselayout-2 OpenRC are the future of Gentoo, then gosh darnit, we need to work together. That means people in the know need to communicate with me on the draft (that I've already sent to cardoe), regardless of any who's-ebuild-are-we-using-epenis-fights. :) I was trying to work together with the docs guys, the GMN peoples, the release engineering people, and our arch teams. However, Mike The Decider Frysinger does not want to work with everyone and has chosen to do his own thing. It just sucked the fun right out of the project for me and made it disinteresting in a heart beat. I had the fun of trying his ebuild out on one of my machines this morning and it happily broke my stable amd64 install. I would give you information if I was in possession of any Mike has still yet to reply to anyone's attempts to contact him. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo
Mike Frysinger wrote: On Monday 24 March 2008, Doug Goldstein wrote: Doug Goldstein wrote: All, This is a formal notice to everyone that OpenRC will be hitting the Gentoo tree sooner rather then later. I would like to see *ALL* arch teams give the current code a whirl on their systems, which is available via the layman module openrc. I would also like to give the docs team a chance to weigh in here and work with me on a migration guide as well as any necessary updates. That being said, I will be the primary point of contact on the transition to OpenRC appearing in ~arch (along with it's associated baselayout-2.0.0 ebuild). Any and all grievances, concerns, suggestions and comments can and should be routed to me via the associated Bugzilla entries or e-mail. I do not want OpenRC to come as a surprise to anyone and break their system. I expect we will leave no stone unturned and go for a very smooth transition. That being said, the bug for the addition of OpenRC is #212696 [1]. The bug for the documentation is #213988 [2]. Lastly, I will be out of town March 21st through March 23rd. I will not have IRC access but I will have e-mail and Bugzilla access. https://bugs.gentoo.org/show_bug.cgi?id=212696 https://bugs.gentoo.org/show_bug.cgi?id=213988 It appears my migration plan was not good enough for Mike Frysinger [EMAIL PROTECTED] and he went ahead and wrote his own version of the OpenRC ebuild, differing from the one in the OpenRC layman repo, and committed it to the tree this weekend. Since my offer to work on the migration was not good enough for him, I'm backing out and allowing him to handle the whole migration himself since I haven't heard from him at all despite Roy (author of OpenRC) and my attempts to contact him for 2 weeks regarding a migration plan for OpenRC. All issues and comments can be directed to him. I guess working together and documenting everything before having it hit the tree was a bad plan and it had to be one-upped. not sure why you're getting pissy. but let's put some things straight shall we. - the ebuild in question was from the layman repo. i changed things of course because it didnt cover all upgrade pieces, had obvious style problems, and did some things wrongly. You mean it wasn't bash style and instead was functional POSIX shell style. And by all upgrade paths would that include adding the bad conversion of /etc/modules.autoload.d/ and removing important ewarn msgs to users? - i'd been poking openrc on my system long before this weekend. Great. And have you been working with the docs people or the arch teams and with the Gentoo/FreeBSD guys? Because some of your changes might work on your system, but not on other systems - only pinging people on irc does not constitute real effort. we have e-mail addresses too last i checked. Refresh your mail client because I did send you e-mail. And as far as I know, Roy did too. - the package is still p.masked and de-keyworded. nothing precludes you from working on it. or writing docs. or doing anything else you're talking about doing. - and no, i dont have a problem sticking masked/de-keyworded things in the tree. people test things then. -mike It's called teamwork, Mike. It also looks awful suspicious when we don't hear a peep out of you about OpenRC until 1 day before I was going to add it to the tree. What would have been so hard about sending a follow up e-mail to the thread I started about getting OpenRC in the tree saying Hey everyone, going to stick openrc- in the tree now with some changes I feel should be made. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo
Mike Frysinger wrote: On Monday 24 March 2008, Doug Goldstein wrote: Mike Frysinger wrote: On Monday 24 March 2008, Doug Goldstein wrote: Doug Goldstein wrote: All, This is a formal notice to everyone that OpenRC will be hitting the Gentoo tree sooner rather then later. I would like to see *ALL* arch teams give the current code a whirl on their systems, which is available via the layman module openrc. I would also like to give the docs team a chance to weigh in here and work with me on a migration guide as well as any necessary updates. That being said, I will be the primary point of contact on the transition to OpenRC appearing in ~arch (along with it's associated baselayout-2.0.0 ebuild). Any and all grievances, concerns, suggestions and comments can and should be routed to me via the associated Bugzilla entries or e-mail. I do not want OpenRC to come as a surprise to anyone and break their system. I expect we will leave no stone unturned and go for a very smooth transition. That being said, the bug for the addition of OpenRC is #212696 [1]. The bug for the documentation is #213988 [2]. Lastly, I will be out of town March 21st through March 23rd. I will not have IRC access but I will have e-mail and Bugzilla access. https://bugs.gentoo.org/show_bug.cgi?id=212696 https://bugs.gentoo.org/show_bug.cgi?id=213988 It appears my migration plan was not good enough for Mike Frysinger [EMAIL PROTECTED] and he went ahead and wrote his own version of the OpenRC ebuild, differing from the one in the OpenRC layman repo, and committed it to the tree this weekend. Since my offer to work on the migration was not good enough for him, I'm backing out and allowing him to handle the whole migration himself since I haven't heard from him at all despite Roy (author of OpenRC) and my attempts to contact him for 2 weeks regarding a migration plan for OpenRC. All issues and comments can be directed to him. I guess working together and documenting everything before having it hit the tree was a bad plan and it had to be one-upped. not sure why you're getting pissy. but let's put some things straight shall we. - the ebuild in question was from the layman repo. i changed things of course because it didnt cover all upgrade pieces, had obvious style problems, and did some things wrongly. You mean it wasn't bash style and instead was functional POSIX shell style. that wasnt what i was referring to, but converting to the tree standard only makes sense for something going into the tree. And by all upgrade paths would that include adding the bad conversion of /etc/modules.autoload.d/ looks/tested correct to me breaks for anything with a module parameter -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo
Mike Frysinger wrote: On Monday 24 March 2008, Doug Goldstein wrote: Mike Frysinger wrote: On Monday 24 March 2008, Doug Goldstein wrote: And by all upgrade paths would that include adding the bad conversion of /etc/modules.autoload.d/ looks/tested correct to me breaks for anything with a module parameter last i looked module parameters were not allowed. but it's a good thing it's p.masked so we can fix it easily. -mike /etc/modules.autoload.d has always allowed module parameters to appear after the module name. /etc/conf.d/modules has allowed a completely different syntax requiring variables based on the module name to be set with the module parameters. This is where Roy and I have been stuck as far as an automatic conversion process. The stuff you included in the openrc- ebuild was something I had sent to Roy months ago before I realized module parameters would be an issue. Looking at a swath of various /etc/modules.autoload.d/ files, I haven't come up with shell code that does the right thing everytime with all the files, which is why I've left it up to being a manual process for the user and simply documenting it. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo
Mike Frysinger wrote: On Monday 24 March 2008, Doug Goldstein wrote: /etc/modules.autoload.d has always allowed module parameters to appear after the module name. /etc/conf.d/modules has allowed a completely different syntax requiring variables based on the module name to be set with the module parameters. This is where Roy and I have been stuck as far as an automatic conversion process. The stuff you included in the openrc- ebuild was something I had sent to Roy months ago before I realized module parameters would be an issue. Looking at a swath of various /etc/modules.autoload.d/ files, I haven't come up with shell code that does the right thing everytime with all the files, which is why I've left it up to being a manual process for the user and simply documenting it. expecting users to read and do it themselves is certainly a path to destruction for many. while i could have written it in shell, i just did it in awk. i hope you're just overstating things when you say months, because FIXED:INCVS. we're going to need to extend the syntax anyways to allow for per-version-per-module arguments. unless openrc does that now ... Roy ? -mike Currently OpenRC does not support per-version-per-module arguments. What is your proposed syntax? -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo
Doug Goldstein wrote: All, This is a formal notice to everyone that OpenRC will be hitting the Gentoo tree sooner rather then later. I would like to see *ALL* arch teams give the current code a whirl on their systems, which is available via the layman module openrc. I would also like to give the docs team a chance to weigh in here and work with me on a migration guide as well as any necessary updates. That being said, I will be the primary point of contact on the transition to OpenRC appearing in ~arch (along with it's associated baselayout-2.0.0 ebuild). Any and all grievances, concerns, suggestions and comments can and should be routed to me via the associated Bugzilla entries or e-mail. I do not want OpenRC to come as a surprise to anyone and break their system. I expect we will leave no stone unturned and go for a very smooth transition. That being said, the bug for the addition of OpenRC is #212696 [1]. The bug for the documentation is #213988 [2]. Lastly, I will be out of town March 21st through March 23rd. I will not have IRC access but I will have e-mail and Bugzilla access. https://bugs.gentoo.org/show_bug.cgi?id=212696 https://bugs.gentoo.org/show_bug.cgi?id=213988 As a follow up for everyone. Mike and I have completed openrc-0.2 and baselayout-2.0.0 ebuilds. They're in the tree and ready for consumption. They are currently masked while we wait for all arches to match ~arch of current baselayout. Tracker bug for this is #214957 [1]. [1] https://bugs.gentoo.org/show_bug.cgi?id=214957 -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 27
Robin H. Johnson wrote: My specific interest in it is for having a sane UID/GIDs that are identical between a set of machines, regardless of the order packages are emerged in. Same here. Which is why I'm hoping to revitalize GLEP 27. -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] adding OpenRC to emerge --info output
All, I'll be adding sys-apps/openrc to info_pkgs in the profiles. That's all. -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Last rites: profiles/hppa/2006.1
All, As per discussions with Guy Martin (gmsoft), the hppa/2006.1 profile has been marked as deprecated and will be removed in 30 days time. -- Doug Goldstein Gentoo Linux -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
Ciaran McCreesh wrote:
On Sat, 19 Apr 2008 18:38:06 +0200
Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote:
Every package dependency in DEPEND is installed and usable before
src_unpack starts, right? So is the question here whether or not they
can be uninstalled right before pkg_{pre,post}inst starts?
If we're using binaries, DEPEND is usually ignored.
But if we're using binaries then src_unpack isn't called so this is a
moot statement and the O.P.'s statement is correct.
I don't know what the general use of pkg_preinst is, but in
pkg_postinst the package itself should be runnable, so its RDEPENDS
should be installed and usable at this point. So perhaps we should
define that usable means each of its RDEPENDs is installed and has
had its pkg_postinst function run. The recursion of that definition
then comes from the requirement that RDEPENDs should be usable before
pkg_postinst starts running.
No good. That prevents RDEPEND - RDEPEND cycles from being solved,
and the package manager has to be able to solve that.
Can you give a concrete example? Not a foo and bar or a and b example.
But a real package example. Because there are a few packages in the tree
which call themselves in pkg_postinst
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
Ciaran McCreesh wrote: On Fri, 18 Apr 2008 21:45:13 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: I'd go with RDEPEND only. Any other interpretation results in installing build-time-only packages along with a binpkg, which doesn't seem to make sense. That's definitely not what we want. Only a package's DEPENDs have to be installed and usable when that package is built. Its RDEPENDs don't have to be installed until that package is treated as usable. For why this matters: 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... I think Donnie (and I) are both looking for concrete examples here. You're claiming GNOME can't be installed so please give us an example with in-tree packages where this breaks. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: lzma tarball usage
Richard Freeman wrote: Enrico Weigelt wrote: I think, as long as there is no really minimal lzmadec available yet (as standalone package), we should more standard compressors like gzip or bzip2. Adding that whole bunch of deps just to save a few bytes IMHO isn't worth it. Keep in mind that this might mean doing our own repackaging of upstream if they don't have a supported option. I think the only other option would be to create an lzmalite package or something like that which simply contains the decompressor in ordinary C. You could really turn that into a separate package like gentoolkit or whatever - I wouldn't actually embed the code into portage since that isn't the unix way and it just forced other package managers (and other distros) to do the same thing. An lzmalite package could have a life of its own and as a result benefit from fewer bugs/etc. But, I'm not going to be the one writing the thing, so feel free to not listen to any of this... :) All upstreams in question still use gzip, they have only dropped bzip2 support in favor of lzma. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: lzma tarball usage
Ryan Hill wrote: On Wed, 07 May 2008 16:23:12 +0300 Mart Raudsepp [EMAIL PROTECTED] 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. The new lzma-utils codebase uses liblzma, written in C. It's at the alpha stage but supposedly supports encoding/decoding the current lzma format well enough (;P). It probably has some fun bugs to find and squish. http://sf.net/mailarchive/forum.php?thread_name=200804251652.58484.lasse.collin%40tukaani.orgforum_name=lzmautils-announce According to the mailing list this change was done to fix security holes in the format and also resulted in a slightly different format that's incompatible with the previous verion. So lzma 5.x and higher will be a different on disk format. It's troubling to me that projects are using lzma when it's on disk format isn't even final and the project has security issues. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: lzma tarball usage
Ciaran McCreesh wrote: On Thu, 08 May 2008 09:17:08 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: It's troubling to me that projects are using lzma when it's on disk format isn't even final and the project has security issues. You mean projects like 'GNU tar'? As far as I know Ciaran, all GNU projects have switched or are in the process of switching to lzma over bzip2. I believe the issue in question which prompted this original e-mail was due to coreutils. But I could be wrong. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: lzma tarball usage
Ciaran McCreesh wrote: On Thu, 08 May 2008 09:32:34 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Thu, 08 May 2008 09:17:08 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: It's troubling to me that projects are using lzma when it's on disk format isn't even final and the project has security issues. You mean projects like 'GNU tar'? As far as I know Ciaran, all GNU projects have switched or are in the process of switching to lzma over bzip2. I believe the issue in question which prompted this original e-mail was due to coreutils. But I could be wrong. You miss my point. GNU tar sometimes changes its on disk format (and will be doing so again at some point for xattrs), and it's had security issues. Fair enough. However, newer GNU tar's are able to untar the older formats. If you read the lzma changelogs, it appears to imply that newer ones won't be able to read older formats. The changelog specifically states if a user they are handling the issue gracefully by telling the user to upgrade or downgrade their lzma. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: lzma tarball usage
Doug Goldstein wrote: Ciaran McCreesh wrote: On Thu, 08 May 2008 09:17:08 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: It's troubling to me that projects are using lzma when it's on disk format isn't even final and the project has security issues. You mean projects like 'GNU tar'? As far as I know Ciaran, all GNU projects have switched or are in the process of switching to lzma over bzip2. I believe the issue in question which prompted this original e-mail was due to coreutils. But I could be wrong. Additionally to follow myself up, I believe one of the security issues was execution of arbitrary data either when untarred or just decompressed (assuming a specially crafted lzma file). Some of the other fun bits are lzma requires autotools but autotools are going to be compressed with lzma. So if we ever need to autoreconf, we have a chicken/egg issue. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Bug wrangling
Donnie Berkholz wrote: On 08:03 Tue 13 May , Rémi Cardona wrote: We all know which devs/herds bugs should be assigned to, we all know most bugs aren't complete if emerge --info is not provided, that sort of things. But Real Bug Masters (tm) know all the dupes, know all the current problems in our various trees and arches, and act as bug-spam filters for the herds. Would it be possible to add the tree categories as products and the packages as components thereof? That would significantly increase the odds of correct assignment, because we could save the per-package assignees in the database. Thanks, Donnie I've wondered about this myself countless times over the years. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] gcc-4.2 / gcc-4.3 plans
Mike Frysinger wrote: On Thursday 10 April 2008, Mike Frysinger wrote: gcc-4.3 seems to be standing up well. since the major gcc-ebuild-specific issues seem to be resolved now, i'll probably do a sweep of bugs to see if there's any patches i'm missing (if you guys know of a bug that should be addressed specifically in the gcc-4.3.0 ebuild, speak up now). then move on to the gcc 4.3 tracker bug (#198121). once this gets below a certain critical mass (i wont know what the critical mass is until it's been de-attained), then we'll be ~arching things. people are recommended to do a quick sweep of the lower hangers (many bugs have simple patches). i'll drop in ~ppc ~amd64 ~x86 as i use those every day. if any other arch is happy now with things, add your ~arch to the commented out list in cvs so i know to include it. the x86 cld revert is in now as well as some more upstream pr fixes. i'll probably let things settle for this week and pending any craziness, move gcc-4.3.0-r1 into ~arch in a week. i'll prob commit some obvious gcc-4.3 bugs at the same time. last chance to speak up peeps. -mike Poke. Gimme some gcc 4.3 goodness (besides the fact that I'm using it). But let's slap ~arch with it. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
Ciaran McCreesh wrote: On Thu, 05 Jun 2008 20:54:23 +0200 [EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) wrote: 6. Tell us one outstanding (in your own mind) contribution you made to Gentoo in the last year. Last year? Being a council member already, I'd say. What did you achieve as a council member? Please take this off list. This is by no means technical or has any application to the nomination process. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] [GLEP56] USE flag descriptions in metadata
All, Here's a GLEP for the addition of USE flag descriptions to package metadata. It does not address any future ideas that others may have had or suggested. It merely gives developers the necessary tools to document their USE flag usage it better detail on a per package basis. An clearly motivation explanation that I didn't add, which I'm going to add once I send this is the fact that as per the QA Project, use.local.desc can not contain a USE flag that already appears globally in use.desc. This would allow a description for that USE flag to be contained in the metadata. http://www.gentoo.org/proj/en/glep/glep-0056.html I encourage any and all _technical_ feedback. Thanks. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2008/2009
Ciaran McCreesh wrote: On Thu, 05 Jun 2008 02:35:16 -0700 Josh Saddler [EMAIL PROTECTED] wrote: Now that nominations are officially open, I nominate the current council members (again): amne betelgeuse dberkholz flameeyes jokey lu_zero vapier As per GLEP 39, I'd like all of the above to justify their slackerness. Once the above people accept their nominations and present the platforms they are running on, you can bring these points up. But until that point, this is a simple nomination process and as such this is unrelated so please take it off list. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [GLEP56] USE flag descriptions in metadata
Marius Mauch wrote: On Thu, 05 Jun 2008 15:42:24 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: All, Here's a GLEP for the addition of USE flag descriptions to package metadata. It does not address any future ideas that others may have had or suggested. It merely gives developers the necessary tools to document their USE flag usage it better detail on a per package basis. An clearly motivation explanation that I didn't add, which I'm going to add once I send this is the fact that as per the QA Project, use.local.desc can not contain a USE flag that already appears globally in use.desc. This would allow a description for that USE flag to be contained in the metadata. http://www.gentoo.org/proj/en/glep/glep-0056.html I encourage any and all _technical_ feedback. Doesn't include any statement about compability with existing tools or how it's related to use.local.desc (replacement, extension, ...) Marius It purposefully does not. XML is an extensible language that allows for this type of expandability. Current tools should be able to validate that adding these tags are valid if they appear in the DTD. However, if those tools do not handle those tags they should not do anything with them, hence the nature of XML. The replacement of use.local.desc would necessitate a change to any and all tools which use that file and require them to support the new XML data. This of course introduces a chicken/egg issue. I have mentioned to infra the possibility of having a pre-rsync process that condensed all metadata.xml's into a use.local.desc that would be part of rsync data but not part of CVS. This could be written as a CVS hook to see when a metadata.xml was touched and run the utility appropriately. But again, this is outside the scope of this GLEP, whose purpose merely is to provide a way to document this. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [GLEP56] USE flag descriptions in metadata
Marius Mauch wrote: On Thu, 05 Jun 2008 17:01:00 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Marius Mauch wrote: On Thu, 05 Jun 2008 15:42:24 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: All, Here's a GLEP for the addition of USE flag descriptions to package metadata. It does not address any future ideas that others may have had or suggested. It merely gives developers the necessary tools to document their USE flag usage it better detail on a per package basis. An clearly motivation explanation that I didn't add, which I'm going to add once I send this is the fact that as per the QA Project, use.local.desc can not contain a USE flag that already appears globally in use.desc. This would allow a description for that USE flag to be contained in the metadata. http://www.gentoo.org/proj/en/glep/glep-0056.html I encourage any and all _technical_ feedback. Doesn't include any statement about compability with existing tools or how it's related to use.local.desc (replacement, extension, ...) Marius It purposefully does not. XML is an extensible language that allows for this type of expandability. Current tools should be able to validate that adding these tags are valid if they appear in the DTD. However, if those tools do not handle those tags they should not do anything with them, hence the nature of XML. I was more talking about tools that process use flag information (equery, euse, ufed, ...). The replacement of use.local.desc would necessitate a change to any and all tools which use that file and require them to support the new XML data. This of course introduces a chicken/egg issue. I have mentioned to infra the possibility of having a pre-rsync process that condensed all metadata.xml's into a use.local.desc that would be part of rsync data but not part of CVS. This could be written as a CVS hook to see when a metadata.xml was touched and run the utility appropriately. But again, this is outside the scope of this GLEP, whose purpose merely is to provide a way to document this. I disagree. At the very least state that the GLEP does not replace use.local.desc if that's the intention, and which location is supposed to take priority if a flag is defined in both. Otherwise different tools will use different rules and generating inconsistent results. And there are many tools affected by this ... Marius PS: I like the general idea, but as long as compability issues are completely ignored by the GLEP I have to oppose it. Considering Portage and repoman currently require any and all USE flags appearing in IUSE to be present in use.local.desc, there should be no ambiguity to the compatibility issues currently. I 100% expect different tools to provide different results. Writing a GLEP stating that one file is preferred over another will not cause those tools to magically choose. The tools and their maintainers should be pushed by the community to use the best data available. If use.local.desc provides this data, then so be it. The initial goal of this GLEP is really to allow per-package descriptions of global USE flags [*]. There by different tools will provide more detailed information about USE flags and some will simply not. That will result in a community push to make these tools use newer data available and as such will result in one day use.local.desc becoming deprecated. But, we're speaking about something which may never happen. Or may happen in another GLEP in the future. [*] As decided by the Gentoo QA Team, any USE flag that appears in use.desc CAN NOT appear in use.local.desc. There by, there is no way for a descriptive variation of a global USE flag to officially appear in any medium. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Nominations for council
William L. Thomson Jr. wrote: On Tue, 2008-06-03 at 18:17 +0100, Ciaran McCreesh wrote: On Tue, 3 Jun 2008 19:11:44 +0200 Jeroen Roovers [EMAIL PROTECTED] wrote: Also, I would have thought there was a requirement to have been a developer for at least a year, just like we require mentors to have been a developer for six months. Thoughts? You're confusing Foundation and Council rules. For the Council, there aren't any restrictions on who can nominate or who can run -- GLEP 39 doesn't even include the restriction on only nominating developers. IMHO the Council should be written into the Foundation Bylaws. Replacing and deprecating GLEP 39. Which one of the first things wrt to the Council that would be mentioned in the Bylaws is the Council has full authority and veto power over the project. That means the board nor officers can dictate to the Council. Council remains on top of it all. Just legally declared, and with other rules, regulations, etc, stipulated in detail. Unlike GLEP 39 Put in a legal document, giving the Council legal power. Not just power per some GLEP or other unofficial doc, being used for a purpose other than it's intention. Much less make it easier to see and understand the structure of Gentoo to an outsider. The Gentoo Foundation and the Gentoo Council are two different entities. For further reference please refer to the FreeBSD Foundation and the FreeBSD Project. What you're implying is that the Gentoo Foundation is over/owns the Gentoo Council. Which is completely and categorically wrong. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] GLEP 55 - The Long Thread
Since there's so many places to comment and I have no intention of hitting all these areas, I'll just create a new thread. There's a lot to be said about being stuck in the grand design mindset. I know many Gentoo, Portage, Exherbo, and Paludis developers are clearly coming to that point in their programming careers based on the comments on this thread and other threads. I would just like to caution everyone that they really need to get past this plateau in their programming careers and get on to the real mindset that matters in the future. The use case mindset. I urge you all to sit down and hammer out real use case situations instead of the idealistic foo/bar/baz concepts. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] EAPI-2 - Let's get it started
Let's try to aim to do an EAPI=2 sometime soonish since Portage now has USE flag depends in version 2.2 which is looming on the horizon. It'd be nice to hit the ground running with supporting these. I know it'll be trivial for the Paludis and pkgcore guys to make this work since they already support USE flag depends. So... let's get the party started. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Nirbheek Chauhan wrote: On Tue, Jun 10, 2008 at 10:00 PM, Patrick Lauer [EMAIL PROTECTED] wrote: So EAPI 2 is not everything shiny, but a small iterative improvement to EAPI 1. Suggest features then and let's discuss! For reference of existing ideas -- https://bugs.gentoo.org/174380 -- a tracker for EAPI feature requests. I personally like https://bugs.gentoo.org/197859 the most -- split out src_configure from src_compile which will allow sane resuming of compiles :) At this point, we should really only discuss features that all 3 package managers have implemented. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55 - The Long Thread
Ciaran McCreesh wrote: On Tue, 10 Jun 2008 10:51:39 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: I urge you all to sit down and hammer out real use case situations instead of the idealistic foo/bar/baz concepts. The use cases are stated rather clearly in the GLEP, which you clearly didn't bother to read... Concrete use cases instead of idealistic ones... -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] EAPI-2 - Let's get it started
Fernando J. Pereda wrote: On 10 Jun 2008, at 18:39, Doug Goldstein wrote: Nirbheek Chauhan wrote: On Tue, Jun 10, 2008 at 10:00 PM, Patrick Lauer [EMAIL PROTECTED] wrote: So EAPI 2 is not everything shiny, but a small iterative improvement to EAPI 1. Suggest features then and let's discuss! For reference of existing ideas -- https://bugs.gentoo.org/174380 -- a tracker for EAPI feature requests. I personally like https://bugs.gentoo.org/197859 the most -- split out src_configure from src_compile which will allow sane resuming of compiles :) At this point, we should really only discuss features that all 3 package managers have implemented. I'm not sure this intersection isn't empty :/ We might, however, only discuss features that all 3 package managers can implement easily. - ferdy That's more of what I meant. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Nominations open for the Gentoo Council 2008/2009
Diego 'Flameeyes' Pettenò wrote: Łukasz Damentko [EMAIL PROTECTED] writes: 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). I wish to nominate Halcy0n, Cardoe and leio. I'll accept my nomination. I'll happily answer all the inquiries on the ML in one post to follow. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] One-Day Gentoo Council Reminder for June
Brian Harring wrote: On Wed, Jun 11, 2008 at 03:06:17AM +, Mike Frysinger wrote: This is your one-day friendly reminder ! The monthly Gentoo Council meeting is tomorrow in #gentoo-council on irc.freenode.net. See the channel topic for the exact time (but it's probably 2000 UTC). If you're supposed to show up, please show up. If you're not supposed to show up, then show up anyways and watch your Council monkeys dance for you. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ Reiterating the early request, I'd like the council to please discuss the current status of PMS, if the running of it satisfys the councils requirements of a *neutral* standard, if the proposed spec actually meets said standards, and if said spec is actually going to be approved sometimes this side of '09. Effectively, we've watched it essentially progress into a standard that effectively only the paludis folk are adherent to (if in doubt, ask portage folk, my sending this mail is indicative of the pkgcore standpoint)- it's about time the council comment upon it in light of the general view. Yes, ciaran shall comment. My request still stands. Thanks, ~harring I'd honestly like to see an official PMS project page i.e. http://www.gentoo.org/proj/en/pms/ On this page it'd be nice if there was an official link to the current PMS instead of having to rely on grabbing it from random locations i.e. d.g.o/~coldwind/ or d.g.o/~spb/ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] One-Day Gentoo Council Reminder for June
Ciaran McCreesh wrote: On Thu, 12 Jun 2008 15:34:56 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: I'd honestly like to see an official PMS project page i.e. http://www.gentoo.org/proj/en/pms/ There's http://www.gentoo.org/proj/en/qa/pms.xml . Unfortunately, rane decided to go and vandalise it for some reason and no-one working on PMS appears to have commit access to it... I saw that page but I think you'd agree it'd a bit lacking in information. Additionally, the fact that rane removed spb from the page due to his retirement does not mean that you need to fling your BS on the ML and accuse people of vandalizing anything. Comments like that are unnecessary to the discussion and poisonous. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] One-Day Gentoo Council Reminder for June
Doug Goldstein wrote: Brian Harring wrote: On Wed, Jun 11, 2008 at 03:06:17AM +, Mike Frysinger wrote: This is your one-day friendly reminder ! The monthly Gentoo Council meeting is tomorrow in #gentoo-council on irc.freenode.net. See the channel topic for the exact time (but it's probably 2000 UTC). If you're supposed to show up, please show up. If you're not supposed to show up, then show up anyways and watch your Council monkeys dance for you. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ Reiterating the early request, I'd like the council to please discuss the current status of PMS, if the running of it satisfys the councils requirements of a *neutral* standard, if the proposed spec actually meets said standards, and if said spec is actually going to be approved sometimes this side of '09. Effectively, we've watched it essentially progress into a standard that effectively only the paludis folk are adherent to (if in doubt, ask portage folk, my sending this mail is indicative of the pkgcore standpoint)- it's about time the council comment upon it in light of the general view. Yes, ciaran shall comment. My request still stands. Thanks, ~harring I'd honestly like to see an official PMS project page i.e. http://www.gentoo.org/proj/en/pms/ On this page it'd be nice if there was an official link to the current PMS instead of having to rely on grabbing it from random locations i.e. d.g.o/~coldwind/ or d.g.o/~spb/ Allow me to clarify a bit more. I'd like to see a collaborative website that developers for all actively maintained package managers can contribute to and update providing details about compatibility and implementation of the PMS and future additions or revisions of the PMS that will be put forth before the Gentoo Council. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Suggested default LDFLAGS+=-Wl,-O1,--hash-style=gnu,--sort-common
Luca Barbato wrote: Fabian Groffen wrote: On 30-06-2008 17:35:08 +0200, Arfrever Frehtes Taifersar Arahesis wrote: How can you easily revert it in a profile? You can set LDFLAGS= in a subprofiles's make.defaults. How elegant... but I guess I'll have no choice. Shouldn't possible have a subprofile with compiler/linker specifics and move there non sharable stuff and keep base leaner? lu I'm just going to commit this to default/linux in about 20 minutes -Wl,-O1 -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for July
Donnie Berkholz wrote: On 13:07 Wed 09 Jul , Arfrever Frehtes Taifersar Arahesis wrote: You forgot about voting on adding some flags to default LDFLAGS. http://thread.gmane.org/gmane.linux.gentoo.devel/57163/focus=57193 http://thread.gmane.org/gmane.linux.gentoo.devel/57092/focus=57169 There was no real debate about that (the only question was where), and Cardoe said this morning that he was just going to commit it. If people had any problems, they would've posted them to the thread. Yep. I actually gave everyone a little bit longer to protest. It seemed like everyone was in favor of this move but no one made the commit. It now exists in profiles/default/linux/make.defaults. I created a tracker for any issues that crop up. [1] [1] http://bugs.gentoo.org/show_bug.cgi?id=231310 -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for July
Donnie Berkholz wrote: On 01:40 Wed 09 Jul , Donnie Berkholz wrote: On 05:30 Tue 01 Jul , Mike Frysinger wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. Here's the proposed agenda. Please respond if I forgot something, it's unclear, or you have another suggestion. As before, since we have an agenda in advance we won't be holding an open floor. Here are the items that will actually come up during the meeting instead of the overall list of ongoing things including list discussions. Council members: Remember to post to the GLEP threads if you have anything new to say. [GLEP56] I've committed the changes that I made as a result of the feedback received. You can see the diff [1] or view the full source [2] or see the pretty HTML [3]. Quick highlight of changes: - All PMS references are gone - restrict purely refers to the Gentoo Developer Handbook - CP/CPV refers to the Gentoo Developer Manual - Added backwards compatibility section to detail how we're going to maintain compatible. - No reference to default language, leaving that to the Gentoo Developer Handbook [1] http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0056.txt?r1=1.1r2=1.2 [2] http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0056.txt?rev=1.2view=markup [3] http://www.gentoo.org/proj/en/glep/glep-0056.html -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 10 July 2008
Donnie Berkholz wrote: Hi all, Here is the summary from Thursday's council meeting. The complete log will show up at http://www.gentoo.org/proj/en/council/ shortly. With regard to GLEP 56. I've posted the necessary DTD changes, some documentation changes (the old documentation patches need to be updated to whats currently in CVS because some commits occurred between when they were created and now), and the repoman patches to the bug [1]. My patches to repoman have already been committed to Portage trunk so they'll appear in 2.2_rc2. pkgcore is being updated this weekend for pcheck to support the new syntax according to ferringb. No one has gotten back to me on paludis so I'm not sure about that status. With regard to the DTD, it's a small change to allow the cat tag, the rest are there already. As far as the docs team knows, neysx is the only one that can commit to them. He's gone until September. So we might need someone from infra to give another doc's team member the access to make that commit. Betelgeuse is committing the documentation patches as I update them for the Gentoo Development Handbook. Halcy0n made a few requested updates to the Gentoo Developer Manual. So that front is moving forward well. I'll be working with robbat2 when he gets some free time this week on getting the infra script I hacked up in place. All and all I'd say we're moving forward on marking this GLEP as Final pretty soon. Biggest project left for me is to copy the current use.local.desc bits into the respective metadata.xml's of each package. If maintainers want to help, that'd be awesome. [1] http://bugs.gentoo.org/show_bug.cgi?id=199788 -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] system set no longer in part of world set
With the new split in Portage where system set packages are not considered in an emerge -auDNv world unless something in world RDEPENDs on it brings about a few issues. i.e. Portage implicitly has a run time dependency on app-arch/tar, app-arch/bzip2, app-arch/gzip, app-arch/lzma due to the fact that Portage will use these utilities when unpack is called inside of an ebuild. As such these are run time depends of Portage and need to be in RDEPEND (the same would technically be true for pkgcore and paludis, unless they use tar's support for those formats and then its up to tar to depend properly). This brings out the fun of circular depends. I don't really know how to address this but a lot of packages are going to have to be updated to contain proper depends. i.e. C based apps will need RDEPEND=virtual/libc. C++ packages will need a stdc++ depend. If you're running Portage 2.2_rc1 on a system you can see if any packages have begun to slack behind on your system in the system set. emerge -puv @system You might notice packages in here that are used on a daily basis but are now no longer being updated. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
Marius Mauch wrote: As a result of Cardoes earlier mail we talked a bit about possible solutions in #gento-portage, and I suggested to let portage automatically inject the deps based on SRC_URI pattern matching. A mapping of extensions and their unpack deps would be kept in the tree (e.g. mapping '.tar.bz2' to '( app-arch/tar app-arch/bzip2 )' Benefits: - simplified depstrings for most packages (I assume 90% of the tree) - easier maintenance if dependencies are changing, or additional implementations become supported (this could also be achieved with virtuals though) - potentially more accurate dependencies, as some common errors would be eliminated (e.g. proper treatment of use-conditionals, not adding unpack deps to RDEPEND) - long-term adds the possibility to remove bzip2, gzip and tar from @system Potential problems: - might cause trouble for some packages that use custom code for unpacking, or due to circular deps, this could simply be solved with a new RESTRICT value though. - automagic deps could be confusing to devs/users - not available for existing EAPIs (due to the mentioned problems) - slightly slower dep calculations due to the extra processing - possible match errors So, is this something ebuild maintainers would like in general, or does such a feature cause you nightmares? Marius I'm in favor of this. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
Ciaran McCreesh wrote: On Tue, 15 Jul 2008 04:14:18 +0200 Marius Mauch [EMAIL PROTECTED] wrote: As a result of Cardoes earlier mail we talked a bit about possible solutions in #gento-portage, and I suggested to let portage automatically inject the deps based on SRC_URI pattern matching. A mapping of extensions and their unpack deps would be kept in the tree (e.g. mapping '.tar.bz2' to '( app-arch/tar app-arch/bzip2 )' Could do it just as an eclass... inherit work-out-my-unpack-deps-for-me In principle, there's nothing that can't be done on the ebuild side here. For the future EAPI side, you could require package managers to define super-magic/package-manager-unpack-bzip2 etc for whatever they use to do the unpacking, and to make it work with existing EAPIs, use || deps with what existing package managers happen to use as the second item. For current EAPIs it's no worse than the existing situation, where ebuilds have to guess that package managers use 'app-arch/unzip' to unpack zip files. This is pretty close to what I had brought up in #gentoo-portage yesterday as well and seems like the best step forward. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Council meeting summary for 10 July 2008
Tiziano Müller wrote: Donnie Berkholz wrote: Hi all, Here is the summary from Thursday's council meeting. The complete log will show up at http://www.gentoo.org/proj/en/council/ shortly. wrt GLEP 56: i) I don't see a specification when use.local.desc is finally going to be dropped ii) Why not switch to XML for use.desc as well? (just to be consequent) We could then use XInclude in a package's metadata.xml to include a global use.desc.xml in use.../use (The requirements could then be changed to: the USE flags description has to be written in the packages metadata.xml) Incremental steps are better then one huge sweeping change. It'll allow us to evaluate the needs and goals of the project as we move forward. The big concern with dropping use.desc is that multiple USE flags that do the same thing will start to pop up across the whole tree because developers won't know that a USE flag already exists for feature X. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] LDFLAGS=-Wl,--hash-style=gnu
all, I'm at the point that -Wl,-O1 appears to be successful. It's time to toss on -Wl,--hash-style=gnu. The issue is that we need glibc 2.5 or higher and not mips. So one solution is to put the following: default/linux: LDFLAGS=-Wl,-O1,--hash-style=gnu default/linux/mips: LDFLAGS=-Wl,-O1 However, this means we'll have to put a has_version check in profile.bashrc of default/linux, which seems a bit cludgy.. Any suggestions? Comments? -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: LDFLAGS=-Wl,--hash-style=gnu
Ryan Hill wrote: On Tue, 15 Jul 2008 21:39:00 +0200 Fabian Groffen [EMAIL PROTECTED] wrote: On 15-07-2008 15:32:32 -0400, Doug Goldstein wrote: all, I'm at the point that -Wl,-O1 appears to be successful. It's time to toss on -Wl,--hash-style=gnu. The issue is that we need glibc 2.5 or higher and not mips. So one solution is to put the following: default/linux: LDFLAGS=-Wl,-O1,--hash-style=gnu default/linux/mips: LDFLAGS=-Wl,-O1 However, this means we'll have to put a has_version check in profile.bashrc of default/linux, which seems a bit cludgy.. Any suggestions? Comments? Also sys-devel/binutils-2.17. I'm just wondering... unless it has changed since last time I installed Gentoo Linux, but isn't the installation manual on purpose conservative with CFLAGS? make.conf.example also does not much more than -march -O2 -pipe. -O1 to the linker feels conservative to me. Still, do we really need to go any further? Why not make additional pointers to possible values for LDFLAGS like we do for C(XX)FLAGS in the installation manual? +1. The default is already to generate a GNU style hash when available. I really don't know why we need to screw with it further. It's actually not. In Gentoo we patch this to use 'both' as the default. -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] LDFLAGS=-Wl,--hash-style=gnu
Doug Goldstein wrote: all, I'm at the point that -Wl,-O1 appears to be successful. It's time to toss on -Wl,--hash-style=gnu. The issue is that we need glibc 2.5 or higher and not mips. So one solution is to put the following: default/linux: LDFLAGS=-Wl,-O1,--hash-style=gnu default/linux/mips: LDFLAGS=-Wl,-O1 However, this means we'll have to put a has_version check in profile.bashrc of default/linux, which seems a bit cludgy.. Any suggestions? Comments? Given the benefits vs the annoyances of not all platforms supporting it and requiring 2 has_version checks in profile.bashrc. I'd be in favor of skipping this flag from the defaults. Possibly adding a documentation notice about it but that's it. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Council meeting summary for 10 July 2008
Tiziano Müller wrote: Doug Goldstein wrote: Tiziano Müller wrote: Donnie Berkholz wrote: Hi all, Here is the summary from Thursday's council meeting. The complete log will show up at http://www.gentoo.org/proj/en/council/ shortly. wrt GLEP 56: i) I don't see a specification when use.local.desc is finally going to be dropped ii) Why not switch to XML for use.desc as well? (just to be consequent) We could then use XInclude in a package's metadata.xml to include a global use.desc.xml in use.../use (The requirements could then be changed to: the USE flags description has to be written in the packages metadata.xml) Incremental steps are better then one huge sweeping change. It'll allow us to evaluate the needs and goals of the project as we move forward. I agree. The big concern with dropping use.desc is that multiple USE flags that do the same thing will start to pop up across the whole tree because developers won't know that a USE flag already exists for feature X. I'd not drop use.desc, I'd substitute it with an XML-based file using a similar (or the same) syntax as metadata.xml. But instead of having the package manager (or other tools operating with USE flags/USE flag descriptions) to lookup in either a package's metadata.xml _or_ a global use.desc.xml, I'd use XInclude in metadata.xml (which then includes the global use.desc.xml) such that the package manager (or other tools) just have to consider a package's metadata.xml. This approach would make it possible to have more than one use.desc.xml. For example for kde or gnome related global USE-flags: kde.use.desc.xml or gnome.use.desc.xml. If you write the code That's the biggest issue with features and ideas people propose. No one is willing to sit down and write the code necessary. Look at how many GLEPs set unimplemented because of lack of code. This also involves increasing the XML support in every package manager, which is not going to be a small undertaking. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] IBM article of interest ?
Philip Webb wrote: I'm not sure whether anyone among Gentoo officials cares about this, but IBM has an article http://www.ibm.com/developerworks/linux/library/l-awk1.html whose byline is very misleading may infringe on Gentoo's IP. I have submitted a comment to IBM via their form at the bottom of the page. HTH What exactly is wrong? Daniel lives in New Mexico. Daniel was the President of Gentoo Technologies, Inc and Gentoo Games, Inc. until their corporate dissolution by the state of New Mexico in 2004 and 2005 respectively. He did create Gentoo Linux, which many Gentoo users and developers will argue is an advanced Linux. I'll give you the point that it's not just for the PC but for assorted hardware. He was involved as a contributor to the books referenced. I can't speak for Daniel's childhood or his hobbies. As far as I know, infra does have a forward setup for him from [EMAIL PROTECTED] or it's possible that forward has expired already. Only infra knows. You might be confusing the Gentoo Foundation, Inc. with Gentoo Technologies, Inc. But no where does that site talk about the Gentoo Foundation. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] ICC Profile
Robert Bridge wrote: On Fri, 18 Jul 2008 11:34:11 +0900 Luca Barbato [EMAIL PROTECTED] wrote: Adam Stylinski wrote: The intel C Compiler (icc) icc, xlc, llvm, sunstudio could be interesting fields of discovery. Which are the pitfalls of using icc? lu If I recall correctly, needing some packages compiled with ICC flags set one way, and needing others compiled with the same flag set the oter way. Can it compile a kernel yet? Rob. No. It doesn't implement all of GCCs extensions and all GNUisms that the kernel relies on. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] system set no longer in part of world set
Olivier Crête wrote: On Mon, 2008-07-14 at 18:01 -0400, Doug Goldstein wrote: This brings out the fun of circular depends. I don't really know how to address this but a lot of packages are going to have to be updated to contain proper depends. i.e. C based apps will need RDEPEND=virtual/libc. C++ packages will need a stdc++ depend. Adding a dep to libc almost everywhere seems extremely wrong to me. I though we had decided many times that it was a bad idea. Yes. Adding libc everywhere is wrong. However, if you don't have one of the packages listed here [1], your libc won't ever update. [1] http://tinderbox.dev.gentoo.org/misc/rindex/virtual/libc -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] system set no longer in part of world set
Marius Mauch wrote: On Fri, 18 Jul 2008 10:01:28 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Olivier Crête wrote: On Mon, 2008-07-14 at 18:01 -0400, Doug Goldstein wrote: This brings out the fun of circular depends. I don't really know how to address this but a lot of packages are going to have to be updated to contain proper depends. i.e. C based apps will need RDEPEND=virtual/libc. C++ packages will need a stdc++ depend. Adding a dep to libc almost everywhere seems extremely wrong to me. I though we had decided many times that it was a bad idea. Yes. Adding libc everywhere is wrong. However, if you don't have one of the packages listed here [1], your libc won't ever update. Now that's a big exaggeration. It _might_ be missing from world updates (there are still many cases where it will be included), but that's not the only available operation in portage. Marius We discussed this in #gentoo-portage the other day where I had a machine that was on gcc 4.3.1 (not -r1) and glibc 2.7 and didn't want to upgrade either of those packages to the latest ~arch.
Re: [gentoo-dev] system set no longer in part of world set
Marius Mauch wrote: On Mon, 21 Jul 2008 11:02:57 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Marius Mauch wrote: Now that's a big exaggeration. It _might_ be missing from world updates (there are still many cases where it will be included), but that's not the only available operation in portage. Marius We discussed this in #gentoo-portage the other day where I had a machine that was on gcc 4.3.1 (not -r1) and glibc 2.7 and didn't want to upgrade either of those packages to the latest ~arch. I know, but just because it did (not) happen in your case doesn't mean it will be the same for everyone else. Marius Given the same package set and world file that I have, it will happen every time. Also specific variations of my package set and world file will result in the issue. Which means that it will occur for other people but no one ever said everyone.
[gentoo-dev] metadata.xml USE flag descriptions
Please make sure you commit any changes to use.local.desc to metadata.xml otherwise you risk the chance of having your changes lost. I'm currently in the process of converting use.local.desc to metadata.xml. After a category is converted, it will be auto-generated EXCLUSIVELY from metadata.xml. This means it will be YOU QA error if you only commit to use.local.desc from here on out. This means use.local.desc will be in a state of constant flux as a result of this. If people wish to take specific categories, please let this thread know. Ford_Prefect is taking gnome-base
[gentoo-dev] Re: [gentoo-dev-announce] metadata.xml USE flag descriptions
Ulrich Mueller wrote: On Mon, 28 Jul 2008, Doug Goldstein wrote: After a category is converted, it will be auto-generated EXCLUSIVELY from metadata.xml. A minor issue: use.local.desc is not sorted properly anymore. It should be sorted by category/package first, then by the USE flag. For example (they are all in reverse order now): app-editors/emacs app-editors/emacs-cvs dev-db/postgresql dev-db/postgresql-base dev-java/ant dev-java/ant-tasks x11-libs/qt x11-libs/qt-core I think something like sort -t -k1,1 should do the job. Ulrich I have yet to touch use.local.desc... so any out of order issues are developer's making. Still debating how I'm going to do it for the time being Attached is a generated file from an hour or two ago. It basically needs to be combined with the current use.local.desc, with the duplicates in use.local.desc removed.. use.local.gen Description: GENbank data
Re: [gentoo-dev] metadata.xml USE flag descriptions
Marius Mauch wrote: On Mon, 28 Jul 2008 12:50:01 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Please make sure you commit any changes to use.local.desc to metadata.xml otherwise you risk the chance of having your changes lost. I'm currently in the process of converting use.local.desc to metadata.xml. After a category is converted, it will be auto-generated EXCLUSIVELY from metadata.xml. This means it will be YOU QA error if you only commit to use.local.desc from here on out. Hmm, maybe we should then disallow commits to use.local.desc on the cvs server completely ... Marius We've actually been considering this. The ban will definitely go into effect once all categories are fully converted and it's auto-generating.
Re: [gentoo-dev] Re: [gentoo-dev-announce] metadata.xml USE flag descriptions
Arun Raghavan wrote: Doug Goldstein wrote: Please make sure you commit any changes to use.local.desc to metadata.xml otherwise you risk the chance of having your changes lost. I'm currently in the process of converting use.local.desc to metadata.xml. After a category is converted, it will be auto-generated EXCLUSIVELY from metadata.xml. This means it will be YOU QA error if you only commit to use.local.desc from here on out. Quick howto from IRC logs for those who want to get started: Copy the stuff to metadata.xml, fix the typos and grammatical issues, and any package or category references need to be wrapped in pkg or cat Cheers, Arun Just to give an example of the above... app-cdr/brasero:libburn - Enable libburn backend. becomes... flag name='libburn'Enable pkgdev-libs/libburn/pkg backend/flag
[gentoo-dev] Re: [gentoo-dev-announce] metadata.xml USE flag descriptions
Josh Glover wrote: 2008/7/29 Doug Goldstein [EMAIL PROTECTED]: This means it will be YOU QA error if you only commit to use.local.desc from here on out. Is it possible to update repoman to complain about this? Otherwise, people are likely to do the wrong thing just out of force of habit. It does... but that would require developers to use the latest repoman... which isn't always the case.
Re: [gentoo-dev] Re: [gentoo-dev-announce] metadata.xml USE flag descriptions
Alec Warner wrote: On Mon, Jul 28, 2008 at 10:51 AM, Ulrich Mueller [EMAIL PROTECTED] wrote: On Mon, 28 Jul 2008, Doug Goldstein wrote: After a category is converted, it will be auto-generated EXCLUSIVELY from metadata.xml. A minor issue: use.local.desc is not sorted properly anymore. It should be sorted by category/package first, then by the USE flag. I wrote the script that generates the new files. It reads categories from $REPO_DIR/profiles/catogories Then per category it runs down each package in os.listdir() order. The use flags are output on a first-come-first-serve basis. The script could possibly sort entries (sort categories; sort listdir output, keep per-package use flags in memory and sort them). File a bug to me if you want this. -Alec For everyone else... http://sources.gentoo.org/viewcvs.py/gentoo/users/antarus/projects/infra/ I'm currently generating my own categories file from the completed categories list in use.local.desc $ cat /usr/portage/profiles/use.local.desc | sed '1,/# The following categories/d;/# End of metadata categories/,$d' | wc -l 34 $ cat /usr/portage/profiles/use.local.desc | grep -v '^#' | cut -d '/' -f 1 | sort -u | wc -l 132 Which means we've got just over 25% of the tree converted.. good job all. Here are the following steps that I'm doing to generate use.local.desc currently.. $ cat use.local.desc | sed '1,/# The following categories/d;/# End of metadata categories/,$d;s/^../^/' tmp.categories $ grep -v -f tmp.categories use.local.desc | grep -v '^#' tmp.use.local.desc $ cat tmp.categories | cut -d '^' -f 2 tmp.categories $ use_desc_gen --repo_path ~/work/gentoo-x86/ --category_path tmp.categories tmp.use.local.desc $ grep '^#' use.local.desc use.local.desc $ cat tmp.use.local.desc | sort -t ' ' -k1,1 use.local.desc $ cvs commit -m generated use.local.desc use.local.desc Currently step 4 is hindered by bugs #233208 #233212 https://bugs.gentoo.org/show_bug.cgi?id=233208 https://bugs.gentoo.org/show_bug.cgi?id=233212 If anyone has any suggestions for an improved workflow while we work to convert the other 75% of the tree, feel free to speak up.
Re: [gentoo-dev] metadata.xml USE flag descriptions
As a follow up to everyone. If you complete a category, please let it be known in the correct place in use.local.desc. We're at 37 of 131 categories complete, which pegs us at just over 28%
[gentoo-dev] [GLEP 56] metadata.xml status
Hey all, We're currently at 52 out of 131 categories converted which puts us at just shy of 40%. Only these 52 categories are currently being auto-generated since the script works on a per category basis. I'd still like thank everyone that's been updating individual packages to use GLEP 56 since you're making entire category conversions quicker. I'm attaching the current wrapper script I use to generate use.local.desc. I'll run this at least once a day during the week. I'm rarely at my commit machine on the weekends so if someone else wants to run it on the weekends, that'll be good. Before anyone asks, yes I've asked infra to run this and as per infra.. they're waiting until 100% of the conversion is done and they don't have to run a wrapper script. use_desc_gen.sh Description: application/shellscript
Re: [gentoo-dev] Unmasking of qt 4.4?
Ben de Groot wrote: Hanno Böck wrote: So question, what are the showstoppers for qt 4.4? And more general comment, especially on important packages that many people rely on, please provide more informative comments in package mask, e.g. bug numbers. Bug numbers should indeed have been provided. The tracker bugs are: #217528 - [Tracker] x11-libs/qt-4.4.0 unmasking #217161 - [Tracker] split Qt 4.4 Mostly it's a question of packages not having split qt-4 deps yet. Other than that, the ebuilds have seen enough testing, as they are needed for kde-4.1 for example, so that is not an issue anymore. For the dependencies, I think this isn't a showstopper either, as if you don't have split dependencies on qt, it'll just take the metapackage and everything is like before. Except that as per bug 217161 nothing should depend on the metapackage. At the moment I'm going through all the remaining open bugs. If things are easy to fix for me I am fixing the deps, otherwise I'm leaving a comment that the package needs fixing ASAP, because I don't want to wait with unmasking qt-4.4 any longer. I hope to be able to do that by tomorrow. (Although I'm still waiting on the remainder of the qt team to officially become a member.) Regards, Ben That being said, anyone wanna give me a hand with MythTV 0.22 depends? I'd appreciate it.
[gentoo-dev] [GLEP 56] metadata.xml USE flag descriptions [Clarifications]
Howdy all, Further questions regarding use.desc have come up with regard to this GLEP. My proposed solution would be a potential amendment to the GLEP to state that flag name='png' / Would be allowed. This syntax is not actually disallowed or allowed by the current GLEP, but mentioning it would allow a metadata.xml contain all the USE flags that appear in IUSE, even the global ones. By using the above syntax, it would simply state that there is no additional descriptions or details but to just use the use.desc description. Further more, it would allow us in the future to make that mandatory and repoman would only have to check metadata.xml for your USE flag. Comments, Suggestions, Input are all welcome. -- Doug Goldstein Gentoo Developer
Re: [gentoo-dev] [GLEP 56] metadata.xml USE flag descriptions [Clarifications]
Santiago M. Mola wrote: On Wed, Aug 13, 2008 at 7:11 PM, Doug Goldstein [EMAIL PROTECTED] wrote: Howdy all, Further questions regarding use.desc have come up with regard to this GLEP. My proposed solution would be a potential amendment to the GLEP to state that flag name='png' / Would be allowed. This syntax is not actually disallowed or allowed by the current GLEP, but mentioning it would allow a metadata.xml contain all the USE flags that appear in IUSE, even the global ones. By using the above syntax, it would simply state that there is no additional descriptions or details but to just use the use.desc description. Further more, it would allow us in the future to make that mandatory and repoman would only have to check metadata.xml for your USE flag. Comments, Suggestions, Input are all welcome. What is the benefit? Regards, There is none really. Allow all use flags to exist in metadata.xml. It's really more of a clarification to the GLEP if this is allowed.
Re: [gentoo-dev] [GLEP 56] metadata.xml USE flag descriptions [Clarifications]
Jeroen Roovers wrote: On Wed, 13 Aug 2008 16:13:26 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: What is the benefit? There is none really. Allow all use flags to exist in metadata.xml. It's really more of a clarification to the GLEP if this is allowed. snip [1] Come to think of it, in the recent metadata.xml / no-herd debate, wasn't having an empty herd tag ever suggested? herd / I've been championing that for what feels like 3 years now. The problem is it breaks backwards compat with all tools out there..
Re: [gentoo-dev] [GLEP 56] metadata.xml status
Doug Goldstein wrote: Hey all, snip Hey all (again), After my long commit fest tonight I am proud to announce we're down to only 10% of the tree (not package wise but category wise). The following categories are the remaining ones left to convert. If anyone's feeling ambitious and wants to pound one or two out. Go for it. Just make sure you check use.local.desc first to make sure no one else did it already. For those wondering (or too lazy to count), the tree has 150 categories currently with 131 containing local USE flags (after cleaning up all the stale USE flags). So below are the remaining 15 categories. dev-java dev-lang dev-util kde-base mail-filter media-libs media-tv net-libs net-mail net-p2p net-wireless sys-apps www-apache www-apps www-client -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/
Re: [gentoo-dev] [GLEP 56] metadata.xml status
Doug Goldstein wrote: Doug Goldstein wrote: Hey all, snip Hey all (again), snip Hey all (again... again), It seems Mr_Bones and I got a bit crazy and finished off the rest of the tree, along with some help from jer. Thanks to everyone that converted a package, and a double thanks to anyone that converted a category. GLEP 56 is now done. -- Doug Goldstein [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/
Re: [gentoo-dev] global USE flag overrides in metadata.xml (bug 235708)
Peter Volkov wrote: Hello. Is it allowed (good idea) to override global USE flags in metadata.xml? Yes. That was the whole point of this. That's why I started it because Halc0yn said we could not override global USE flags (use.desc) in local USE flag (use.local.desc). The devmanual has not been updated to reflect the acceptance of GLEP 56 by the council nor it's subsequent implementation.
Re: [gentoo-dev] EAPI-2
Jorge Manuel B. S. Vicetto wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi again. Quoting Zac earlier in #gentoo-portage: 21:46 zmedico jmbsvicetto: I think we essentially have a spec already that people can agree on. just take my draft and subtract the eapi* functions and the gitweb unpack extension. So we're talking about adding the following to EAPI-2: ~ * The 'doman' helper function recognizes language codes in man page ~ source files, and uses them to generate an appropriate ~ installation path. ~ * The meaning of the !atom blocker syntax now implies that ~ temporary simultaneous installation of conflicting packages is ~ allowed [3]. ~ * A new !!atom blocker syntax is now supported, for use in special ~ cases in which temporary simultaneous installation of conflicting ~ packages should not be allowed. ~ * Dependency atoms can be constrained to match specific USE flag ~ states, including USE conditional expressions embedded within ~ the atoms themselves. ~ * SRC_URI supports a syntax extension which allows customization ~ of output file names by using a - operator. ~ * A new src_prepare phase function is called after src_unpack. ~ * The old src_compile phase function is split into separate ~ src_configure and src_compile fuctions. ~ * Default phase function implementations for the current EAPI are ~ accessible via a function having a name that begins with default_ ~ and ends with the respective phase function name. ~ * The default phase function implementation for the currently ~ executing phase is accessible as a function named 'default'. Given the earlier discussion about EAPI-2 in http://archives.gentoo.org/gentoo-dev/msg_3e9d42191c3537c4f699c12cadd0ad99.xml and cardoe's earlier request to the council ml, can the council members discuss this proposal and consider voting it? Does anyone have any objections to this proposal? - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjFtoQACgkQcAWygvVEyALQigCePXcGlT5m6JGB2OlB5swY6f4F /yIAnRte3mm5PULg73j5KDrnKHSFB5h6 =lW1u -END PGP SIGNATURE- That removes the only two sections that appeared to have any chatter on them. Anyone involved in PMS or other package managers have any input on this? No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.6.19/1660 - Release Date: 9/8/2008 6:39 PM
Re: [gentoo-dev] EAPI-2
Tobias Scherbaum wrote: Luca Barbato wrote: Jorge Manuel B. S. Vicetto wrote: Hi again. Quoting Zac earlier in #gentoo-portage: 21:46 zmedico jmbsvicetto: I think we essentially have a spec already that people can agree on. just take my draft and subtract the eapi* functions and the gitweb unpack extension. I don't see any problems with it. +1 Tobias +1
Re: [gentoo-dev] EAPI-2
Jan Kundrát wrote: Michael Hammer wrote: But for me it's still questionable why we don't have a gentoo project for this important task? You mean something like http://www.gentoo.org/proj/en/qa/pms.xml ? Cheers, -jkt This page is incomplete and needs some more details added to it. The Gentoo Council took this up at the last meeting on Sept 11th. and plan to some details posted to gentoo-dev in the coming weeks. However, I've been spearheading this a bit and I'm getting married this weekend and then I have my honeymoon so, except things to be almost at a stand still from me until October.
[gentoo-dev] Baselayout-2 / OpenRC Stabilization
As some people may have already noticed, I have recently added OpenRC 0.3.0 to the tree. This will be the stabilization candidate in approximately 30 days. I encourage everyone to kick the tires on this one. Current Bugs: *http://tinyurl.com/4housz*
Re: [gentoo-dev] Baselayout-2 / OpenRC Stabilization
Doug Goldstein wrote: As some people may have already noticed, I have recently added OpenRC 0.3.0 to the tree. This will be the stabilization candidate in approximately 30 days. I encourage everyone to kick the tires on this one. Current Bugs: *http://tinyurl.com/4housz* I've created a branch for tracking any patches that we use that deviate from the release tarball http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=shortlog;h=refs/heads/gentoo-0.3.x
Re: [gentoo-dev] Baselayout-2 / OpenRC Stabilization
Petteri Räty wrote: Doug Goldstein kirjoitti: As some people may have already noticed, I have recently added OpenRC 0.3.0 to the tree. This will be the stabilization candidate in approximately 30 days. I encourage everyone to kick the tires on this one. Current Bugs: *http://tinyurl.com/4housz* That list doesn't take into consideration if init scripts don't work properly with openrc. Regards, Petteri I've been taking the time to mark legit OpenRC bugs with [OpenRC] in the subject and init script isssues with [init.d]
Re: [gentoo-dev] EAPI 2 is brokened :(
Ciaran McCreesh wrote: Unfortunately Portage and Pkgcore have broken EAPI 2 implementations. snip Ciaran, I would think at this point you know this since you've seen this brought up hundreds of times on this list. The mailing list is not an appropriate place to file bug reports. The proper place would be in http://bugs.gentoo.org for Portage and http://www.pkgcore.org for pkgcore.
[gentoo-dev] virtualx eclass
While the rule of thumb has been if an eclass needs something it should provide it's own depends. However the virtualx eclass needs to be different simply because in some cases it's only uses for tests (this is it's most common usage in the whole) tree. When it's used for tests pulling in the xorg-server the most ideal situation would be if xorg-server was only pulled in on USE=test because currently for anyone emerging an app that uses GTK+ they have a weird situation in the fact that all of GTK+'s depends that have USE=X use it to mean libX11 (as do most usages of the X USE flag), however GTK+ itself due to it's usage of the virtualx eclass pulls in xorg-server when USE=X, which is only used for tests. This results in a confusing experience for users looking to built a headless machine. It'd be a lot more consistent if ebuilds provided a USE flag or directly depended on the xorg-server and then used the functions in the eclass. So in summary, those are the changes I plan on making very shortly. If someone's got some input, please speak up. -- Doug Goldstein
Re: [gentoo-dev] virtualx eclass
Doug Goldstein wrote: While the rule of thumb has been if an eclass needs something it should provide it's own depends. However the virtualx eclass needs to be different simply because in some cases it's only uses for tests (this is it's most common usage in the whole) tree. When it's used for tests pulling in the xorg-server the most ideal situation would be if xorg-server was only pulled in on USE=test because currently for anyone emerging an app that uses GTK+ they have a weird situation in the fact that all of GTK+'s depends that have USE=X use it to mean libX11 (as do most usages of the X USE flag), however GTK+ itself due to it's usage of the virtualx eclass pulls in xorg-server when USE=X, which is only used for tests. This results in a confusing experience for users looking to built a headless machine. It'd be a lot more consistent if ebuilds provided a USE flag or directly depended on the xorg-server and then used the functions in the eclass. So in summary, those are the changes I plan on making very shortly. If someone's got some input, please speak up. Dave Leverton brings up a better suggestion. Providing VIRTUALX_DEPS and having the ebuild just toss that into it's depends as needed.
Re: [gentoo-dev] Re: virtualx eclass
Diego 'Flameeyes' Pettenò wrote: Doug Goldstein [EMAIL PROTECTED] writes: It'd be a lot more consistent if ebuilds provided a USE flag or directly depended on the xorg-server and then used the functions in the eclass. So in summary, those are the changes I plan on making very shortly. If someone's got some input, please speak up. Kinda like good ol' kde.eclass: VIRTUALX_ONLY_TEST=yes inherit virtualx and instead of using IUSE=X for that, IUSE=test. That leaves a conditional that must be evaluated in the global scope every time the depends are looked at. And if that isn't set then making xorg-server always required in DEPEND? What about packages that rely on virtualx to depend on xorg-server for them (i.e. a RDEPEND)?
Re: [gentoo-dev] Re: virtualx eclass
Doug Goldstein wrote: Diego 'Flameeyes' Pettenò wrote: Doug Goldstein [EMAIL PROTECTED] writes: It'd be a lot more consistent if ebuilds provided a USE flag or directly depended on the xorg-server and then used the functions in the eclass. So in summary, those are the changes I plan on making very shortly. If someone's got some input, please speak up. Kinda like good ol' kde.eclass: VIRTUALX_ONLY_TEST=yes inherit virtualx and instead of using IUSE=X for that, IUSE=test. That leaves a conditional that must be evaluated in the global scope every time the depends are looked at. And if that isn't set then making xorg-server always required in DEPEND? What about packages that rely on virtualx to depend on xorg-server for them (i.e. a RDEPEND)? For the third line item, those packages are broken in general and need to be fixed so that's out of the scope of this.
Re: [gentoo-dev] virtualx eclass
Doug Goldstein wrote: While the rule of thumb has been if an eclass needs something it should provide it's own depends. However the virtualx eclass needs to be different simply because in some cases it's only uses for tests (this is it's most common usage in the whole) tree. When it's used for tests pulling in the xorg-server the most ideal situation would be if xorg-server was only pulled in on USE=test because currently for anyone emerging an app that uses GTK+ they have a weird situation in the fact that all of GTK+'s depends that have USE=X use it to mean libX11 (as do most usages of the X USE flag), however GTK+ itself due to it's usage of the virtualx eclass pulls in xorg-server when USE=X, which is only used for tests. This results in a confusing experience for users looking to built a headless machine. It'd be a lot more consistent if ebuilds provided a USE flag or directly depended on the xorg-server and then used the functions in the eclass. So in summary, those are the changes I plan on making very shortly. If someone's got some input, please speak up. Alright... after talking to Diego, Dave, and Remi the final result that I've come up with is the following: VIRTUALX_CONDITIONAL_USE=test inherit virtualx That'll result in virtualx adding the following: DEPEND=test? ( x11-base/xorg-server x11-apps/xhost ) if VIRTUALX_CONDITIONAL_USE is unset (as it will be for all ebuilds initially) the default will be X. Which means the default is the same as what we've got today. If it's set to an empty string, it'll always be required. Otherwise, it will use the supplied USE flag. -- Doug Goldstein
Re: [gentoo-dev] virtualx eclass
Doug Goldstein wrote: Doug Goldstein wrote: While the rule of thumb has been if an eclass needs something it should provide it's own depends. However the virtualx eclass needs to be different simply because in some cases it's only uses for tests (this is it's most common usage in the whole) tree. When it's used for tests pulling in the xorg-server the most ideal situation would be if xorg-server was only pulled in on USE=test because currently for anyone emerging an app that uses GTK+ they have a weird situation in the fact that all of GTK+'s depends that have USE=X use it to mean libX11 (as do most usages of the X USE flag), however GTK+ itself due to it's usage of the virtualx eclass pulls in xorg-server when USE=X, which is only used for tests. This results in a confusing experience for users looking to built a headless machine. It'd be a lot more consistent if ebuilds provided a USE flag or directly depended on the xorg-server and then used the functions in the eclass. So in summary, those are the changes I plan on making very shortly. If someone's got some input, please speak up. Alright... after talking to Diego, Dave, and Remi the final result that I've come up with is the following: VIRTUALX_CONDITIONAL_USE=test inherit virtualx That'll result in virtualx adding the following: DEPEND=test? ( x11-base/xorg-server x11-apps/xhost ) if VIRTUALX_CONDITIONAL_USE is unset (as it will be for all ebuilds initially) the default will be X. Which means the default is the same as what we've got today. If it's set to an empty string, it'll always be required. Otherwise, it will use the supplied USE flag. Turns out this situation breaks down when multiple USE flags are required/used. One suggestion is to allow for that via: VIRTUALX_CONDITIONAL_USE=test X but needs someone to write some elegant shell to make that expansion happen. Also, it'll happen in the global scope when the data is cached so a little ugh on that part. The last fall back of course is to go to just defining VIRTUALX_DEPS and letting each ebuild USE it how it needs to use it. Feedback, comments, etc are appreciated. -- Doug Goldstein
Re: [gentoo-dev] Gentoo Council Reminder for October 23
Donnie Berkholz wrote: This is your friendly reminder ! Same bat time (typically the 2nd 4th Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know! Simply reply to this e-mail for the whole Gentoo dev list to see. Keep in mind that every GLEP *re*submission to the council for review must first be sent to the gentoo-dev mailing list 7 days (minimum) before being submitted as an agenda item which itself occurs 7 days before the meeting. Simply put, the gentoo-dev mailing list must be notified at least 14 days before the meeting itself. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ I'd like us to sit down and discuss the 10 opened bugs assigned to the council and what we can do to resolve them. -- Doug Goldstein
