Re: [gentoo-dev] perforce client proper license
On Sun, Mar 22, 2009 at 2:58 AM, Alec Warner anta...@gentoo.org wrote: I think you will encounter namespace collisions, thats why I CC'd zac as he maintains mirror-dist ;p Why the hell didn't we think of this before!? :o The mirror-dist script *cannot* rename the upstream files for storage, since emerge will be looking for the *original* filename on the gentoo mirror. And if we keep them the same, we'll have collisions on the mirror, which is more probable (and severe) than a collision on a user's local DISTDIR. The easiest solution I can think of is for emerge to give special consideration to the mirrors in GENTOO_MIRRORS, and look for the renamed file there instead of the original ones. -- ~Nirbheek Chauhan who is extremely bewildered by this oversight
Re: [gentoo-dev] Make the policykit USE flag global
On Wed, Mar 18, 2009 at 6:42 PM, Olivier Crête tes...@gentoo.org wrote: Feel the trend? gnome-base/gnome-panel will follow soon. Lets make this global. Unless we decide that PolicyKit is the future and make it compulsory). If no one complains, I will make the changes in a couple days. So, what's the final decision on this/status of this? I don't see it in-tree as a global USE flag yet. PS: It should probably be globally use.masked till we can make it work properly as well -- ~Nirbheek Chauhan
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Saturday 21 March 2009 19:03:45 AllenJB wrote: Patrick Lauer wrote: Hi all, with the discussion about EAPI3 we have now 4 (or 7, depending on how you count them ;) ) EAPIs available or almost available. This is getting quite confusing. To make our lives easier I would suggest deprecating EAPI0 and migrating existing ebuilds over some time to EAPI1 or higher until EAPI0 can be obsoleted at some point in the future. I would set the start of deprecation warnings about 3 months from now and the obsoletion quite a time later, maybe 12 months from now, when a sufficient amount of ebuilds has been migrated. Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have to think about, but since it has some changes like adding src_prepare migration would not be as trivial. So I'd prefer keeping it around a bit longer. Comments? Patrick While there definitely arguments for deprecating EAPIs, I would suggest caution. A low number of active EAPIs can make life easier for developers, but it can also make life harder for some users. There are still users coming to the forums upgrading systems which only understand EAPI 0. I accept that Gentoo is certainly a relatively fast moving distro, but I think that developers also do need to consider users who have systems that are currently just working and may not upgrade often (once a year or even less) As such, I would suggest that forcing a move to the most recent stable EAPI is possibly unwise. snip AllenJB Note, this just my opinion. It may not be entirely practical or cover all the issues regarding backwards compatibility. I intend it to provoke questions and thought as to what a reasonable policy for backwards compatibility might cover. Waiting a year or longer to upgrade a gentoo system carries a good risk of having something explode into a near unrecoverable mess. I definitely do think that some major focus needs to be placed on how far behind a gentoo system could be and should still be expected to catch up. An oversimplified example. Assume that I can find all required patches and source code to do the initial builds, and that all normal configuration file checks/updates are done after the current tree is installed. I create three different virtual machines from cvs snapshots of the portage tree. The first is dated 6 months ago. The second is dated 12 months ago. The third is dated 18 months ago. Which of these should be reasonably updateable to the current portage tree? My suggestion is that policy should allow machine 1 to be updated through regular update procedures to the current tree, unless major changes dictate otherwise. Major changes being incompatible ebuild formats, toolchains, and other here is the line sorry kind of changes. A careful operator should probably be able get machine 2 updated to the current tree, again unless major changes dictate otherwise. We should not make go out of our way to make upgrading from this point out hard for the operator, but, new growth should be favored over the ease of upgrading. Machine 3 is just out of luck. Here is the new install cd and handbook, have fun. Regular update procedures would be: emerge --sync; emerge -uND world -f; emerge -uND world; revdep-rebuild; emerge --depclean; The careful operator might update the toolchain first and emerge -e world or something similar.
Re: [gentoo-dev] RFC: Deprecating EAPI0
Peter Alfredsen loki_...@gentoo.org wrote: I think we should start deprecating EAPI=0 usage *now* with a repoman warning whenever a new ebuild is committed that does not use EAPI=1 or EAPI=2. This warning should encourage use of the newest EAPI, EAPI=2. A general question, that just popped into my head when i was reading this: if i touch a ebuild which has EAPI=0, should i bump it to EAPI=2? Since the introduction of EAPI i have been bumping EAPI of my ebuilds based on need. So if i needed slot-deps, i've made the ebuild EAPI=1, not EAPI=2 by choice. If i needed use-deps, then well, i went for EAPI=2. How are other ebuild developers doing this? What's the package manager ppls take on this? -- Regards, Matti Bickel Signed/Encrypted email preferred (key 4849EC6C) pgpr5TMoF3mbY.pgp Description: PGP signature
EAPI roadmap (was: Re: [gentoo-dev] RFC: Deprecating EAPI0)
Peter Alfredsen loki_...@gentoo.org said: On Sun, 22 Mar 2009 09:41:58 +0100 Matti Bickel m...@gentoo.org wrote: A general question, that just popped into my head when i was reading this: if i touch a ebuild which has EAPI=0, should i bump it to EAPI=2? Only if you take the time to read through it and test that your revised ebuild will have the same functionality as the old one. That's why I wrote when a new ebuild This should not be an automated thing, but rather a part of the basic bump-adjust-test maintenance cycle. while i agree with what you say here, it is also important to take the general EAPI roadmap into account. as we currently dont have one AFAIK, we should make efforts to agree on one soon. i doesnt make sense to introduce EAPI=2 into ebuilds, if we dont expect to have en EAPI=2 capable package manager stable within a reasonable timeframe. as it really doesnt matter what i think, when portage-2.2 should go stable i will not bore you with that, however, given that only portage 2.2 supports EAPI=2 it is relevant for the discussion of an EAPI roadmap. in light of the current EAPI usage statistics, i would propose to deprecate EAPI 1 (and 2) much earlier than EAPI 0. regards Thilo /loki_val
[gentoo-dev] Re: EAPI roadmap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thilo Bangert yazmış: i doesnt make sense to introduce EAPI=2 into ebuilds, if we dont expect to have en EAPI=2 capable package manager stable within a reasonable timeframe. 2.1.6 is stable and supports EAPI2 - -- Sincerely, Serkan KABA Gentoo Developer -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknGHSsACgkQRh6X64ivZaKlRwCfRqdpdvroDZN0OQOycCo1N6Qi rjcAnRzNxfxQ6SK2pmFRzWbiLYR1rGwW =LZcB -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: Deprecating EAPI0
On Saturday 21 of March 2009 21:53:16 Patrick Lauer wrote: On Saturday 21 March 2009 21:21:47 Ciaran McCreesh wrote: On Sat, 21 Mar 2009 18:37:12 +0100 Patrick Lauer patr...@gentoo.org wrote: To make our lives easier I would suggest deprecating EAPI0 and migrating existing ebuilds over some time to EAPI1 or higher until EAPI0 can be obsoleted at some point in the future. Uh. Why? Because, as you have noticed before, developers get confused which eapi has which features available. And eapi1 is a superset of eapi0, so we don't have to rewrite tons of things. Spend more time to teach them. It's easier to developers make sure they do things ok than users spending their time to figure out what's wrong. Personally i don't like the idea of deprecating EAPI0 since it may break many servers. Eg. our border router at work isn't upgraded regulary. I spent much time lately to upgrade it with problems like portage vs. bash and so. So the last thing i'd like to see now in portage is implementing your proposal. Introducing a policy encouraging moving things that definitely aren't in the least bit likely to be a system dep on a bump, sure. Making 1 or 2 the default for new packages, sure. But rewriting existing things? That's just an accident waiting to happen. What kind of accident do you expect to happen? Patrick
Re: [gentoo-dev] perforce client proper license
On Sunday 22 March 2009, Nirbheek Chauhan wrote: On Sun, Mar 22, 2009 at 2:58 AM, Alec Warner anta...@gentoo.org wrote: I think you will encounter namespace collisions, thats why I CC'd zac as he maintains mirror-dist ;p Why the hell didn't we think of this before!? :o The mirror-dist script *cannot* rename the upstream files for storage, since emerge will be looking for the *original* filename on the gentoo mirror. And if we keep them the same, we'll have collisions on the mirror, which is more probable (and severe) than a collision on a user's local DISTDIR. The easiest solution I can think of is for emerge to give special consideration to the mirrors in GENTOO_MIRRORS, and look for the renamed file there instead of the original ones. No reason to panic. :-) This is what Portage already does and what is specified in EAPI=2. Refer to the paragraph quoted by Ciaran earlier in this thread. Do we have a reason to believe our mirror scripts do not already handle this correctly? Because to me it seems they do. $ ebuild bashburn-3.0.ebuild unpack Downloading 'http://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/distfiles/BashBurn-3.0.tar.gz' --2009-03-22 15:48:57-- http://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/distfiles/BashBurn-3.0.tar.gz Resolving ftp.spline.inf.fu-berlin.de... 130.133.110.66 Connecting to ftp.spline.inf.fu-berlin.de|130.133.110.66|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 84435 (82K) [application/octet-stream] Saving to: `/usr/portage/distfiles/BashBurn-3.0.tar.gz' ... $ G ENTOO_MIRRORS= ebuild bashburn-3.0.ebuild unpack Downloading 'http://bashburn.dose.se/index.php?s=file_downloadid=3' --2009-03-22 15:49:12-- http://bashburn.dose.se/index.php?s=file_downloadid=3 Resolving bashburn.dose.se... 90.227.105.216 Connecting to bashburn.dose.se|90.227.105.216|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [application/octet-stream] Saving to: `/usr/portage/distfiles/BashBurn-3.0.tar.gz' Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] perforce client proper license
On Sun, 22 Mar 2009 11:44:48 +0530
Nirbheek Chauhan nirbh...@gentoo.org wrote:
On Sun, Mar 22, 2009 at 2:58 AM, Alec Warner anta...@gentoo.org
wrote:
I think you will encounter namespace collisions, thats why I CC'd
zac as he maintains mirror-dist ;p
Why the hell didn't we think of this before!? :o
Uhm. We did. PMS is worded very carefully to ensure that this all
works. The only question is whether Portage's mirroring scripts are
broken. Alec seems to think they are; I'm sceptical, because a) I
pestered Zac about the issue really early on, and b) I strongly suspect
we'd've seen the breakage by now if they were.
The easiest solution I can think of is for emerge to give special
consideration to the mirrors in GENTOO_MIRRORS, and look for the
renamed file there instead of the original ones.
I quote:
In EAPIs supporting arrows, if an arrow is used, the filename used when
saving to \t{DISTDIR} shall instead be the name on the right of the
arrow. When consulting mirrors (except for those explicitly listed on
the left of the arrow, if \t{mirror://} is used), the filename to the
right of the arrow shall be requested instead of the filename in the
URI.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
[gentoo-dev] please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
Please do not apply patches that have ${P} prefix in other ebuild
versions than ${PV}.
Is that hard to create a new patch with a proper name?
Cheers,
Alin
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On Sun, 22 Mar 2009, mrness wrote:
Please do not apply patches that have ${P} prefix in other ebuild
versions than ${PV}.
Is that hard to create a new patch with a proper name?
And multiply number and total size of files in ${FILESDIR}?
Ulrich
Re: [gentoo-dev] please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On Sun, Mar 22, 2009 at 1:18 PM, Ulrich Mueller u...@gentoo.org wrote:
On Sun, 22 Mar 2009, mrness wrote:
Please do not apply patches that have ${P} prefix in other ebuild
versions than ${PV}.
Is that hard to create a new patch with a proper name?
And multiply number and total size of files in ${FILESDIR}?
Ulrich
Or just rename it ${PN}-bar.patch instead of ${P}-bar.patch if it is a
patch for more than one ebuild version.
But older ebuild has to be changed to make it works.
Mounir
Re: [gentoo-dev] please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On Sunday 22 of March 2009 18:18:15 Ulrich Mueller wrote:
On Sun, 22 Mar 2009, mrness wrote:
Please do not apply patches that have ${P} prefix in other ebuild
versions than ${PV}.
Is that hard to create a new patch with a proper name?
And multiply number and total size of files in ${FILESDIR}?
I guess it may be possible to drop P (or replace with PN) from patch file
names, to make it more obvious which patches should apply with which package
version.
Also, I'd like Tomáš Chvátal (scarabeus) to finally propose his GLEP or just
post it for discussion here as it's related to patch files management and
provides naming scheme - it would address this issue as well as separate
upstream patches from Gentoo specific ones in FILESDIR (and good thing is it's
backward compatible and it doesn't need any EAPI revbump that would inevitably
cause pointless discussion).
--
regards
MM
--
10% zysku na lokacie bankowej z gwarancja BFG. Sprawdz!
http://clk.tradedoubler.com/click?p=74281a=1586724g=17879004
Re: [gentoo-dev] perforce client proper license
On Sun, Mar 22, 2009 at 8:32 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
I quote:
In EAPIs supporting arrows, if an arrow is used, the filename used when
saving to \t{DISTDIR} shall instead be the name on the right of the
arrow. When consulting mirrors (except for those explicitly listed on
the left of the arrow, if \t{mirror://} is used), the filename to the
right of the arrow shall be requested instead of the filename in the
URI.
Right, thanks for clearing that up :)
/me heaves a sigh of relief
--
~Nirbheek Chauhan
Re: [gentoo-dev] please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On Sun, Mar 22, 2009 at 10:54 PM, Mounir Lamouri
mounir.lamo...@gmail.com wrote:
Or just rename it ${PN}-bar.patch instead of ${P}-bar.patch if it is a
patch for more than one ebuild version.
But older ebuild has to be changed to make it works.
The ${PV} in the patch name is a quick indication of the age of a
patch, the gnome herd especially *encourages* this behavior.
--
~Nirbheek Chauhan
[gentoo-dev] Gentoo Council Reminder for March 26
Sorry about the delay on this -- I wrote it on a computer that somehow fails at sending email and forgot it was in drafts. 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/ -- Thanks, Donnie Donnie Berkholz Developer, Gentoo Linux Blog: http://dberkholz.wordpress.com pgplvT61wh9V4.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council Reminder for March 26
On Sun, 22 Mar 2009 21:18:52 +0100 Donnie Berkholz dberkh...@gentoo.org 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. Continuing the whole EAPI 3 thing... http://github.com/ciaranm/pms/tree/eapi-3 is a draft based upon ongoing discussion. There's more or less one commit per new feature. For each feature, I'd like to know: * whether there are any objections to that feature as a candidate for EAPI 3 * what the plan is for Portage implementation of that feature, and the likelihood of it making it * whether that feature is considered critical for EAPI 3, or whether it can be dropped if necessary if Portage can't get it implemented within a certain time Also, I'd like to know of any potential omissions. I'd imagine this'd go easier of Council members went through before the meeting and provided individual opinions on each item, and then just discussed any disagreements during the meeting, but whatever's best for you... This list might help for those who're scared of git: 1) EAPI 3 has pkg_pretend. 2) EAPI 3 supports slot operator dependencies 3) EAPI 3 has use dependency defaults 4) PROPERTIES, DEFINED_PHASES mandatory in EAPI 3 5) EAPI 3 has a default src_install 6) EAPI 3 has controllable compression and docompress 7) EAPI 3 has dodoc -r 8) EAPI 3 requires doins support for symlinks 9) EAPI 3 bans || ( use? ( ... ) ) 10) dohard and dosed banned in EAPI 3 11) doinclude, newinclude for EAPI 3 12) EAPI 3 supports .xz, .tar.xz 13) EAPI 3 has more econf arguments 14) EAPI 3 supports pkg_info on installed packages 15) USE is stricter in EAPI 3 16) AA, KV gone in EAPI 3 17) S to WORKDIR fallback conditional for EAPI 3 18) EAPI 3 has unpack --if-compressed, new src_unpack 19) RDEPEND=DEPEND gone in EAPI 3 20) EAPI 3 has doexample. 21) REPLACING_VERSIONS and REPLACED_BY_VERSION in EAPI 3 22) EAPI 3 has nonfatal, utilities die -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On Sun, 22 Mar 2009 13:24:26 -0400
Mounir Lamouri mounir.lamo...@gmail.com wrote:
On Sun, Mar 22, 2009 at 1:18 PM, Ulrich Mueller u...@gentoo.org
wrote:
On Sun, 22 Mar 2009, mrness wrote:
Please do not apply patches that have ${P} prefix in other ebuild
versions than ${PV}.
Is that hard to create a new patch with a proper name?
And multiply number and total size of files in ${FILESDIR}?
Or just rename it ${PN}-bar.patch instead of ${P}-bar.patch if it is a
patch for more than one ebuild version.
And when the patch has to be changed? ${PN}-foo-2.patch?
The PV in the patch name indicates what version the patch was made
for. This can be useful info, if just for judging how bad you are at
sending patches upstream. ;)
--
gcc-porting, by design, by neglect
treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
Ryan Hill wrote:
Please do not apply patches that have ${P} prefix in other ebuild
versions than ${PV}.
Is that hard to create a new patch with a proper name?
Um, why?
I'm not having six identical patches with different version numbers in
FILESDIR.
Good point.
Sebastian
[gentoo-dev] headless herds
These herds have no members: afterstep: net-mail/asmail x11-plugins/asapm x11-plugins/asclock x11-plugins/ascpu x11-plugins/asmem x11-plugins/asmon x11-plugins/astime x11-wm/afterstep Upstream is willing to maintain, just needs a contact. https://bugs.gentoo.org/180765 -- secure-tunneling: net-analyzer/mping net-misc/corkscrew net-misc/ghamachi net-misc/hamachi net-misc/openssh net-misc/openswan net-misc/strongswan net-misc/tinc There isn't even an alias for this team. Should probably be removed and packages moved to maintainer-needed unless there is another appropriate herd they can join. -- pda: app-pda/* (63 packages) dev-libs/libmal dev-libs/libmimedir dev-util/pilrc [1731] @ dirtyepic | peper: are you still taking care of pda@ stuff? [1732] peper | dirtyepic: i never really was, i got added to the herd and then all of the folks left.. -- middle-east: no packages remove? -- live-cd: app-admin/pwgen app-arch/pbzip2 app-misc/livecd-tools dev-python/pyparted dev-util/catalyst media-gfx/splash-themes-livecd sys-apps/ddcxinfo-knoppix sys-apps/gli sys-apps/hwdata-gentoo sys-apps/hwsetup sys-apps/parted sys-fs/squashfs-tools sys-libs/libkudzu x11-misc/mkxf86config x11-themes/gdm-themes-livecd x11-themes/gentoo-artwork-livecd -- utf8: no packages. remove? -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
Le 22/03/2009 19:22, Nirbheek Chauhan a écrit :
The ${PV} in the patch name is a quick indication of the age of a
patch, the gnome herd especially *encourages* this behavior.
What I used to do back when I was still bumping packages in the Gnome
Herd, I would version the patch, but I would use
${PN}-2.22-fix-foo.patch for patch names.
It feels like the best of both worlds to me :
- versionned patches (we know when we started shipping it)
- easy bumping (no need to edit the ebuild)
The only downside is that cleaning up takes a couple more seconds since
I have to check if patch 2.20 is used or not by packages 2.24...
But overall, it's bikeshedding. Git (or any other half decent SCM)
should be able to compress identical patches down to a single blob.
My 2¢
Rémi
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2009-03-22 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2009-03-22 23h59 UTC. Removals: net-mail/ezmlm 2009-03-16 19:54:26 tove net-mail/ezmlm-idx-mysql2009-03-16 19:54:27 tove net-mail/ezmlm-idx-pgsql2009-03-16 19:54:27 tove app-admin/sdsc-syslog 2009-03-21 22:17:49 darkside media-fonts/ec-fonts-mftraced 2009-03-21 22:20:05 darkside app-misc/gallery-remote 2009-03-21 22:26:21 darkside x11-wm/stumpwm-cvs 2009-03-21 22:31:29 darkside www-servers/tux 2009-03-21 22:33:53 darkside media-libs/osalp2009-03-21 22:36:11 darkside sci-astronomy/setiathome2009-03-21 22:38:09 darkside app-i18n/uim-svn2009-03-22 15:56:38 matsuu dev-lang/mlton-bin 2009-03-22 17:05:05 hkbst Additions: dev-perl/XML-XPathEngine2009-03-16 01:30:58 weaver dev-perl/XML-DOM-XPath 2009-03-16 01:32:31 weaver dev-perl/Ace2009-03-16 01:50:20 weaver sci-biology/bowtie 2009-03-16 04:36:47 weaver app-misc/cstream2009-03-16 09:24:33 bangert gnustep-apps/fisicalab 2009-03-16 11:50:31 voyageur dev-perl/Bio-ASN1-EntrezGene2009-03-16 23:11:58 weaver sci-biology/biosql 2009-03-16 23:21:40 weaver sci-biology/bioperl-db 2009-03-16 23:24:35 weaver sci-biology/bioperl-network 2009-03-16 23:26:44 weaver app-crypt/seahorse-plugins 2009-03-17 09:41:58 nirbheek games-misc/fortune-mod-discworld2009-03-17 14:32:07 s4t4n sys-auth/libnss-cache 2009-03-18 05:33:07 antarus net-nds/nsscache2009-03-18 06:04:18 antarus dev-python/fabric 2009-03-18 08:06:45 hollow media-plugins/vdr-channelblocker2009-03-19 08:33:18 zzam app-emulation/wine-doors2009-03-19 20:03:20 hanno app-shells/squirrelsh 2009-03-20 04:17:08 ken69267 app-xemacs/cedet-common 2009-03-20 06:50:06 graaff app-misc/beagle-xesam 2009-03-20 18:07:16 ford_prefect dev-util/xesam-tools2009-03-20 19:01:14 ford_prefect sci-visualization/ggobi 2009-03-20 19:40:05 bicatali dev-python/skype4py 2009-03-21 04:59:04 darkside net-im/skysentials 2009-03-21 05:04:57 darkside app-xemacs/cogre2009-03-21 08:19:39 graaff dev-ruby/rbtree 2009-03-21 16:04:36 drizzt dev-python/ctypesgen2009-03-22 00:36:28 arfrever net-dialup/sercd2009-03-22 12:44:53 mrness dev-db/couchdb 2009-03-22 21:27:43 caleb -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: net-mail/ezmlm,removed,tove,2009-03-16 19:54:26 net-mail/ezmlm-idx-mysql,removed,tove,2009-03-16 19:54:27 net-mail/ezmlm-idx-pgsql,removed,tove,2009-03-16 19:54:27 app-admin/sdsc-syslog,removed,darkside,2009-03-21 22:17:49 media-fonts/ec-fonts-mftraced,removed,darkside,2009-03-21 22:20:05 app-misc/gallery-remote,removed,darkside,2009-03-21 22:26:21 x11-wm/stumpwm-cvs,removed,darkside,2009-03-21 22:31:29 www-servers/tux,removed,darkside,2009-03-21 22:33:53 media-libs/osalp,removed,darkside,2009-03-21 22:36:11 sci-astronomy/setiathome,removed,darkside,2009-03-21 22:38:09 app-i18n/uim-svn,removed,matsuu,2009-03-22 15:56:38 dev-lang/mlton-bin,removed,hkbst,2009-03-22 17:05:05 Added Packages: dev-perl/XML-XPathEngine,added,weaver,2009-03-16 01:30:58 dev-perl/XML-DOM-XPath,added,weaver,2009-03-16 01:32:31 dev-perl/Ace,added,weaver,2009-03-16 01:50:20 sci-biology/bowtie,added,weaver,2009-03-16 04:36:47 app-misc/cstream,added,bangert,2009-03-16 09:24:33 gnustep-apps/fisicalab,added,voyageur,2009-03-16 11:50:31 dev-perl/Bio-ASN1-EntrezGene,added,weaver,2009-03-16 23:11:58 sci-biology/biosql,added,weaver,2009-03-16 23:21:40 sci-biology/bioperl-db,added,weaver,2009-03-16 23:24:35 sci-biology/bioperl-network,added,weaver,2009-03-16 23:26:44 app-crypt/seahorse-plugins,added,nirbheek,2009-03-17 09:41:58 games-misc/fortune-mod-discworld,added,s4t4n,2009-03-17 14:32:07 sys-auth/libnss-cache,added,antarus,2009-03-18 05:33:07 net-nds/nsscache,added,antarus,2009-03-18 06:04:18 dev-python/fabric,added,hollow,2009-03-18 08:06:45 media-plugins/vdr-channelblocker,added,zzam,2009-03-19 08:33:18 app-emulation/wine-doors,added,hanno,2009-03-19 20:03:20 app-shells/squirrelsh,added,ken69267,2009-03-20 04:17:08
Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On 3/22/09 11:47 PM, Ryan Hill wrote:
On Sun, 22 Mar 2009 17:50:26 +0100
Alin Năstac mrn...@gentoo.org wrote:
Please do not apply patches that have ${P} prefix in other ebuild
versions than ${PV}.
Is that hard to create a new patch with a proper name?
Um, why?
I'm not having six identical patches with different version numbers in
FILESDIR.
Fine, then remove $PV from patch name and use it in any ebuild version
you want. Or just decouple the patch version from the ebuild version
(foo-bar-r1.patch sounds OK to me).
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] perforce client proper license
On Saturday 21 March 2009 14:06:09 Markos Chandras wrote: Hello folks, Qt-creator[1] program can support perforce[2] software configuration manager. My concern is the perforce license. According to their site[3] there is a dual(?) license. There is the standard commercial license[4] and one for free software development[4]. Should I add both? Or am I missing something? Doing some research I found out that perforce-cli was in the portage back in 2006 but not anymore. Can somebody recall the reason why it is not there anymore? If it wasn't a license issue , I want to bring it back ( at least the client for now ). I am waiting your suggestions. Thank you [1] http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-util/qt-creator/ [2] http://www.perforce.com/perforce/ [3] http://www.perforce.com/perforce/price.html#license [4] http://www.perforce.com/perforce/price.html#opensource Responding to my self, i decided not to bring this package on tree and instead use an ewarn message to inform user that if he wants perforce support, he needs to download the binary by himself. Thats not a big deal since the binary doesnt even require installation or anything else. -- Markos Chandras (hwoarang) Gentoo Linux Developer Qt/KDE/Sunrise/Sound Web: http://hwoarang.silverarrow.gr signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
On Mon, 23 Mar 2009 01:19:26 +0100 Alin Năstac mrn...@gentoo.org wrote: Fine, then remove $PV from patch name and use it in any ebuild version you want. Or just decouple the patch version from the ebuild version (foo-bar-r1.patch sounds OK to me). No. It's done this way for a reason. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
Alin Năstac wrote: snip Fine, then remove $PV from patch name and use it in any ebuild version you want. Or just decouple the patch version from the ebuild version (foo-bar-r1.patch sounds OK to me). What exactly is your problem that you are trying to solve here? Posting to the community to stop doing something without providing reasons to stop is not going to go anywhere. I like having the PV in the patch name..so, you haven't convinced me. -Jeremy
Re: [gentoo-dev] perforce client proper license
On Sun, Mar 22, 2009 at 8:02 AM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Sun, 22 Mar 2009 11:44:48 +0530
Nirbheek Chauhan nirbh...@gentoo.org wrote:
On Sun, Mar 22, 2009 at 2:58 AM, Alec Warner anta...@gentoo.org
wrote:
I think you will encounter namespace collisions, thats why I CC'd
zac as he maintains mirror-dist ;p
Why the hell didn't we think of this before!? :o
Uhm. We did. PMS is worded very carefully to ensure that this all
works. The only question is whether Portage's mirroring scripts are
broken. Alec seems to think they are; I'm sceptical, because a) I
pestered Zac about the issue really early on, and b) I strongly suspect
we'd've seen the breakage by now if they were.
I said I doubted they were and to ask the maintainer:
00:45 antarus zmedico: do the mirroring scripts do src_uri arrows properly?
00:46 zmedico antarus: yes
00:46 antarus ok super ;)
Thread Over ;)
The easiest solution I can think of is for emerge to give special
consideration to the mirrors in GENTOO_MIRRORS, and look for the
renamed file there instead of the original ones.
I quote:
In EAPIs supporting arrows, if an arrow is used, the filename used when
saving to \t{DISTDIR} shall instead be the name on the right of the
arrow. When consulting mirrors (except for those explicitly listed on
the left of the arrow, if \t{mirror://} is used), the filename to the
right of the arrow shall be requested instead of the filename in the
URI.
--
Ciaran McCreesh
Re: [gentoo-dev] please stop using foo-${PV}-bar.patch in other ebuild versions than ${PV}
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alin Năstac wrote:
Please do not apply patches that have ${P} prefix in other ebuild
versions than ${PV}.
Is that hard to create a new patch with a proper name?
I opted to reply to your mail after reading all the other replies.
FWIW, I agree with you and have been doing that for desktop-effects and
KDE packages. Whenever we need to add a patch we do it as ${P}. If that
patch is not applied upstream and is needed for future versions, I
rename the patch to ${PN} to decouple it from a particular ${PV}.
Cheers,
Alin
- --
Regards,
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknG6MkACgkQcAWygvVEyAJQkQCfRaf8IsqB89+AoZUL77gPdynH
Y5QAoJEXoQoBELvvIbW1mEqzVl0R0Azx
=joA9
-END PGP SIGNATURE-
[gentoo-dev] updating baselayout PERMS_PROTECT
so from what I can see there doesn't appear to be any 'official' way of adding new directories, updating perms and the like in baselayout. my thought is someone who does an emerge -aveD world's system should for the most part be reset to 'factory' defaults. of course this leads to the problem... what if the 'admin' explicitly changed the permissions... Maybe we should have something like PERMS_PROTECT (similar to config_protect). where portage won't update the permissions if file/directory is protected. -- Caleb Cushing http://xenoterracide.blogspot.com
[gentoo-dev] Re: headless herds
On Sun, 22 Mar 2009 17:38:16 -0700 Robin H. Johnson robb...@gentoo.org wrote: On Sun, Mar 22, 2009 at 05:55:38PM -0600, Ryan Hill wrote: secure-tunneling: net-analyzer/mping net-misc/corkscrew net-misc/ghamachi net-misc/hamachi net-misc/openssh net-misc/openswan net-misc/strongswan net-misc/tinc There isn't even an alias for this team. Should probably be removed and packages moved to maintainer-needed unless there is another appropriate herd they can join. Umm, I don't know why you listed several of these packages as belonging to secure-tunneling, because they definitely do NOT. sorry, bad grep. $ find . -name metadata.xml -print0 | xargs -0 grep 'secure-tunneling' | cut -d/ -f2,3 | sort | uniq net-misc/openswan net-misc/strongswan net-misc/tinc openswan - has mrness as the maintainer as well tinc - has dragonheart as the maintainer as well. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] headless herds
On Sun, 22 Mar 2009 17:55:38 -0600 Ryan Hill dirtye...@gentoo.org wrote: These herds have no members: ... live-cd: app-admin/pwgen app-arch/pbzip2 app-misc/livecd-tools dev-python/pyparted dev-util/catalyst media-gfx/splash-themes-livecd sys-apps/ddcxinfo-knoppix sys-apps/gli sys-apps/hwdata-gentoo sys-apps/hwsetup sys-apps/parted sys-fs/squashfs-tools sys-libs/libkudzu x11-misc/mkxf86config x11-themes/gdm-themes-livecd x11-themes/gentoo-artwork-livecd A trivial matter - I've added the four @gentoo.org maintainers from the livecd alias list to herds.xml. Kind regards, jer
