[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-editors/leafpad: ChangeLog leafpad-0.8.14.ebuild
On Sat, 29 Mar 2008, Donnie Berkholz wrote:
On 19:37 Sat 29 Mar , Saleem Abdulrasool (compnerd) wrote:
1.1 app-editors/leafpad/leafpad-0.8.14.ebuild
src_compile() {
econf --enable-chooser --enable-print $(use_enable emacs)
emake
}
emake doesn't die on failure.
And IMHO the emacs USE flag should not be used here:
$ ./configure -hs
Configuration of Leafpad 0.8.12:
Optional Features:
[...]
--enable-emacs implement Emacs key theme (experimental)
$ equery uses =leafpad-0.8.12
[...]
+ + emacs : Adds support for GNU Emacs
As its description says, the flag is intended for GNU Emacs support
which is not the case here.
Ulrich
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] =sys-boot/grub-0.97-r5 testers wanted
Hi folks, The new -r5 of Grub provides a LOT of functionality and workings over the previous -r3 and -r4, however I would like more testers than I previously had. Specific functionality for testing: - GPT partition tables (bug 178586, 211584) - Large kernels (bug 160801) - * Long command lines (bug 183443) - * Ext3 partitions w/ larger inodes (bug 214563) - *^ Xen memory detection (bug 188312) - *^ CCISS arrays (bug 153393) If you do undertake to test these, I strongly recommend having a LiveCD on hand in case it goes awry. The GPT support I've tested myself enough, but further testing on other GPT layouts would be useful (esp. those created with partitioning tools other than parted). It does contain some definite fixes over the r4 codebase. The large kernel (3Mb) support I am concerned about side effects with, esp. when the configurable value is turned up high - I tested it briefly, but not in-depth. Items marked with a * were not tested by me personally, but I did get some feedback. Items marked with a ^ I have not had any feedback whatsoever on. Please file problems via Bugzilla (file to base-system, I'll see it), and success reports off-list to me. -- Robin Hugh Johnson Gentoo Linux Developer Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpuEkxaPY6Ag.pgp Description: PGP signature
Re: [gentoo-dev] explicit -r0 in ebuild filename
On Sun, Mar 30, 2008 at 05:40:44AM +0100, Ciaran McCreesh wrote: On Sat, 29 Mar 2008 21:16:51 -0700 Brian Harring [EMAIL PROTECTED] wrote: Contrasting tabs vs spaces is a whole other matter. One of the things you attempted to do in splitting PMS was to force certain technical tweaks through because frankly, they made sense (or you were stubborn, and it mostly made sense). That's fine. Not where those things involve large tree changes... Fairly obvious, the suffix0 case is pretty rarely used. It's used more than a lot of other things... Some file suffixes for unpack are only used by a single package, for example, yet they're still in there. Ditto for some of the utilities. This isn't relevant to the discussion at hand; besides, I'm unaware of any suffix *currently* that has some long time usage that is used by a mere .06% of the tree. LZMA likely would apply, but that also was introduced rather recent so isn't exactly representative. Finally, drawing parallels between unpack and forcing a specific form of suffix makes no sense- dropping a format from unpack has real world consequences, specifically breakage. Forcing one or the other suffix wise is a quick inspection of 15 ebuilds in gentoo-x86, and minor compat code if the package manager upstream wants to be friendly to the minority of users it may affect if they make suffix0 an error when dealing with vdb. Quick look at the commiters behind the explict 0 suffixes, you don't see any maintainer actually repeat it in another pkg- personally, I suspect majority of it was new dev mistake, in some cases propagated (wschlich feel free to correct me on this sine you've got the most there). For dvd95, well aware pylon wasn't new at that point, so theory doesn't quite hold there (although oversight may fly). Doesn't follow. Most upstreams don't use versions that fit an unversioned part most of the time. You wouldn't expect to see it repeated all over the place because in the real world it's not a very common (but importantly, not non-existent or massively rare) issue. There are lots of things that upstream does with versioning that doesn't map perfectly into ebuild versioning scheme- and that's actually quite fine. Besides, this discussion is *not* about banning _pre0, or _alpha0- it's about banning explicit usage of implicit version components in the on disk ebuild. Phrasing another way, it's pointless to have dev-util/diffball/diffball-1.0_alpha0.ebuild ; dev-util/diffball/diffball-1.0_alpha.ebuild is the exact same version. Banning _suffix0 (and -r0) loses nothing, but gains consistancy in on disk naming (thus less likely for devs to screw up as occured today), and simplifies working with ebuilds on disk for managers/repo modifiers. You don't want to start breaking people who use =..._alpha0 when the version in the tree uses plain _alpha, for example. Explicitly requiring on disk to not specify implicit components in no way breaks atom support, or anything else for that matter. Either this is a minor brain fart on your part, or again, you're going to have to be a fair bit more clear in your explanation. Introducing multiple sets of versioning rules is a far worse gotcha than a ban on duplicates. Banning _alpha etc in some places but not others gets very confusing very quickly. You're reaching. Nothing is lost here. What you're arguing for is thus- you can have name the ebuild either pkg-1.0_alpha0.ebuild, or pkg-1.0_alpha.ebuild. You must not have both on disk however versus you must name the ebuild pkg-1.0_alpha.ebuild. There is no multiple sets of versioning rules here, the versioning rules stay *exactly* the same. All that's being done is that the unique cpv constraint is pushed down to the on disk repository level, thus removing the issue permenentaly (while increasing consistancy across repos). As I've done in attempting to respond to your questions/counterargument, please site examples/data, or at the very least be explicit about what you're claiming. I know the versioning rules (unfortunately) quite well, and there is no 'multiple sets' introduced via this change- so either you're confused, or you see something I don't. Saves both of us a lot of time if you're explicit. Repositories are already not allowed to contain duplicated versions. That's a sufficiently strong guarantee. 2) not surprisingly, it actually simplifies manager implementation. Tracking internally whether 1.0 is actually 1.0-r0 on disk or not means extra level of mappings required, meaning more areas to screw it up. The package manager has to deal with equality and equivalence separately anyway... If you're storing 1.0 when the actual version is 1.0-r0 you have issues regardless of whether -r0 itself is banned on disk You're pretty clearly missing the point. When I state it makes repository/package manager operations simpler, this is a
[gentoo-dev] Re: explicit -r0 in ebuild filename
Brian Harring [EMAIL PROTECTED] posted
[EMAIL PROTECTED], excerpted below, on
Sun, 30 Mar 2008 02:39:46 -0700:
No need to ban 1.00; it's already banned by PMS- quoting from names.tex:
A version starts with the number part, which is in the form
\t{[0-9]+($\backslash$.[0-9]+)*} (a positive integer, followed by zero
or more dot-prefixed positive integers).
Note the 'positive integers'; so 1.00 is actually blocked by PMS. That
said, that same text seems to invalidly ban 1.0 also.
Well, positive integer as used must include zero also, or by that
definition, 0.xx style versions would be disallowed as well. That just
wouldn't be sane if we're to keep anything even /close/ to upstream
version mapping, so positive as used here must include 0 (and does by
the literal ranged definition), and both 0.xx and x.00 are therefore
defined as allowed, unless there's a further restriction elsewhere that
hasn't been quoted.
--
Duncan - List replies preferred. No HTML msgs.
Every nonfree program has a lord, a master --
and if you use the program, he is your master. Richard Stallman
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: explicit -r0 in ebuild filename
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duncan wrote:
| Brian Harring [EMAIL PROTECTED] posted
| [EMAIL PROTECTED], excerpted below, on
| Sun, 30 Mar 2008 02:39:46 -0700:
|
| No need to ban 1.00; it's already banned by PMS- quoting from names.tex:
|
| A version starts with the number part, which is in the form
| \t{[0-9]+($\backslash$.[0-9]+)*} (a positive integer, followed by zero
| or more dot-prefixed positive integers).
|
| Note the 'positive integers'; so 1.00 is actually blocked by PMS. That
| said, that same text seems to invalidly ban 1.0 also.
|
| Well, positive integer as used must include zero also, or by that
| definition, 0.xx style versions would be disallowed as well. That just
| wouldn't be sane if we're to keep anything even /close/ to upstream
| version mapping, so positive as used here must include 0 (and does by
| the literal ranged definition), and both 0.xx and x.00 are therefore
| defined as allowed, unless there's a further restriction elsewhere that
| hasn't been quoted.
|
non-negative integer must've been meant.
- --
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkfvqZAACgkQp/VmCx0OL2xPsQCbBNKtynU9aSdr3uY+x+sDt4tR
0SQAoK/sGruoV0qr8wyfB2qNPy0SzH7q
=QsyO
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] explicit -r0 in ebuild filename
On Saturday 29 March 2008, Ciaran McCreesh wrote: Brian Harring [EMAIL PROTECTED] wrote: The reason I'm emailing -dev is to ensure there is consensus on leaving off an explicit -r0 in the ebuild name- long term, it seems folks always followed the rule but it needs to be codified due to problems with uniquely identifying the ebuild in the repo. Even ignoring the unique identifiers, banning explicit -r0 globally is inconsistent anyway. We already allow and use _alpha and _alpha0 (which mean the same thing) and so on. those arent the same thing. -r# is a Gentoo-specific revision marking. _alpha/_rc/etc... are used to track upstream. if upstream uses _alpha0, then it makes our lives easier to also use _alpha0. -r0 has no benefit and it isnt inconsistent as that portion of the version is for Gentoo use only. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-editors/leafpad: ChangeLog leafpad-0.8.14.ebuild
On Sunday 30 March 2008, Ulrich Mueller wrote:
On Sat, 29 Mar 2008, Donnie Berkholz wrote:
On 19:37 Sat 29 Mar , Saleem Abdulrasool (compnerd) wrote:
1.1 app-editors/leafpad/leafpad-0.8.14.ebuild
src_compile() {
econf --enable-chooser --enable-print $(use_enable emacs)
emake
}
emake doesn't die on failure.
And IMHO the emacs USE flag should not be used here:
$ ./configure -hs
Configuration of Leafpad 0.8.12:
Optional Features:
[...]
--enable-emacs implement Emacs key theme (experimental)
$ equery uses =leafpad-0.8.12
[...]
+ + emacs : Adds support for GNU Emacs
As its description says, the flag is intended for GNU Emacs support
which is not the case here.
i think the USE flag makes sense. perhaps the description should be changed.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-editors/leafpad: ChangeLog leafpad-0.8.14.ebuild
On Sun, 30 Mar 2008, Mike Frysinger wrote: And IMHO the emacs USE flag should not be used here: $ ./configure -hs Configuration of Leafpad 0.8.12: Optional Features: [...] --enable-emacs implement Emacs key theme (experimental) $ equery uses =leafpad-0.8.12 [...] + + emacs : Adds support for GNU Emacs As its description says, the flag is intended for GNU Emacs support which is not the case here. i think the USE flag makes sense. perhaps the description should be changed. Certainly a USE flag makes sense here, but it shouldn't be USE=emacs. The emacs global USE flag is used by 82 other packages (all outside the app-emacs category). Its purpose is always that GNU Emacs specific files are installed; either directly, or indirectly by pulling another package via *DEPEND. So leafpad would be the first package assigning a different meaning to the flag. In my opinion, a local USE flag like emacskeys or emacs-keymap would make more sense here. (And I doubt that users who would enable Emacs key bindings in leafpad would always want GNU Emacs. Setting USE=emacs in make.conf will inevitably install it.) Ulrich -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-editors/leafpad: ChangeLog leafpad-0.8.14.ebuild
On Sunday 30 March 2008, Ulrich Mueller wrote: On Sun, 30 Mar 2008, Mike Frysinger wrote: And IMHO the emacs USE flag should not be used here: $ ./configure -hs Configuration of Leafpad 0.8.12: Optional Features: [...] --enable-emacs implement Emacs key theme (experimental) $ equery uses =leafpad-0.8.12 [...] + + emacs : Adds support for GNU Emacs As its description says, the flag is intended for GNU Emacs support which is not the case here. i think the USE flag makes sense. perhaps the description should be changed. Certainly a USE flag makes sense here, but it shouldn't be USE=emacs. The emacs global USE flag is used by 82 other packages (all outside the app-emacs category). Its purpose is always that GNU Emacs specific files are installed; either directly, or indirectly by pulling another package via *DEPEND. why cant it mean both ? USE flags are intended to control features, not dependencies. often times that just happens to translate into dependencies. realistically though, anyone who wants emacs wants all emacs things. if it were to just pull in the emacs dependency, then that could just as easily be accomplished by `emerge emacs` and then we can drop the USE flag entirely. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: explicit -r0 in ebuild filename
Ioannis Aslanidis wrote: If you are asking about mathematic stright definition: negative integer: -inf,...,-1 positive integer: 1,...,inf natural: 0,...,inf The group of natural numbers includes the positive integers and zero. That is the definition in most places in the world; however, in the United States and a few more countries, non-negative integers is how the lot is called. I was going to dig back to my math minor and wax eloquent about how this is incorrect, but it turns out we're both right: http://en.wikipedia.org/wiki/Natural_numbers The natural numbers may or may not include zero depending on who's using the term. That was actually news to me - my understanding is that zero was not considered a natural number, but it was considered a whole number. And now that we've totally drifted off topic here I'll be quiet... -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] explicit -r0 in ebuild filename
On Sun, 30 Mar 2008 12:24:10 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: those arent the same thing. -r# is a Gentoo-specific revision marking. _alpha/_rc/etc... are used to track upstream. if upstream uses _alpha0, then it makes our lives easier to also use _alpha0. -r0 has no benefit and it isnt inconsistent as that portion of the version is for Gentoo use only. Every other part allows the magic 0 behaviour. Banning it for one part only is another one of those 'special case' rules we're trying to avoid because no-one knows them. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] explicit -r0 in ebuild filename
On Sun, 30 Mar 2008 02:39:46 -0700
Brian Harring [EMAIL PROTECTED] wrote:
I'm unaware of any suffix *currently* that has some long time usage that
is used by a mere .06% of the tree. LZMA likely would apply, but
that also was introduced rather recent so isn't exactly
representative.
7z.
Finally, drawing parallels between unpack and forcing a specific form
of suffix makes no sense- dropping a format from unpack has real
world consequences, specifically breakage. Forcing one or the
other suffix wise is a quick inspection of 15 ebuilds in gentoo-x86,
and minor compat code if the package manager upstream wants to be
friendly to the minority of users it may affect if they make suffix0
an error when dealing with vdb.
Getting fifteen ebuilds changed might be something you could get done
via QA, but it's not PMS's job.
(Unless it's something really annoying, of course...)
There are lots of things that upstream does with versioning that
doesn't map perfectly into ebuild versioning scheme- and that's
actually quite fine.
Sure, but arbitrarily banning even more of them is wrong.
Besides, this discussion is *not* about banning _pre0, or _alpha0-
it's about banning explicit usage of implicit version components in
the on disk ebuild.
Phrasing another way, it's pointless to have
dev-util/diffball/diffball-1.0_alpha0.ebuild ;
dev-util/diffball/diffball-1.0_alpha.ebuild
is the exact same version.
But a different PV.
Banning _suffix0 (and -r0) loses nothing, but gains consistancy in
on disk naming (thus less likely for devs to screw up as occured
today), and simplifies working with ebuilds on disk for managers/repo
modifiers.
And means people need to start using versionator.
Introducing multiple sets of versioning rules is a far worse gotcha
than a ban on duplicates. Banning _alpha etc in some places but not
others gets very confusing very quickly.
You're reaching. Nothing is lost here. What you're arguing for is
thus-
you can have name the ebuild either pkg-1.0_alpha0.ebuild, or
pkg-1.0_alpha.ebuild. You must not have both on disk however
versus
you must name the ebuild pkg-1.0_alpha.ebuild.
There is no multiple sets of versioning rules here, the versioning
rules stay *exactly* the same. All that's being done is that the
unique cpv constraint is pushed down to the on disk repository level,
thus removing the issue permenentaly (while increasing consistancy
across repos).
But you're not pushing a unique CPV constraint unless you start banning
all sorts of other things.
As I've done in attempting to respond to your
questions/counterargument, please site examples/data, or at the very
least be explicit about what you're claiming. I know the versioning
rules (unfortunately) quite well, and there is no 'multiple sets'
introduced via this change- so either you're confused, or you see
something I don't.
Saves both of us a lot of time if you're explicit.
You're talking about forcing one lot of rules for on-disk packages and
another lot of rules for versions in general.
The package manager has to deal with equality and equivalence
separately anyway... If you're storing 1.0 when the actual version
is 1.0-r0 you have issues regardless of whether -r0 itself is
banned on disk
You're pretty clearly missing the point. When I state it makes
repository/package manager operations simpler, this is a classic
example- you don't have to worry about whether or not it was -r0 on
disk, or was revisionless. Via forcing consistancy into the spec,
you force it to be one or the other.
No! Even ignoring -r0, you still have to know whether it's 010 or 10 on
disk. Or do you want to ban that too? And all the other possible ways
of having multiple equivalent but non-equal versions?
-- if you want to prevent that, you have to start banning versions
like 086 and 1.00 too.
No need to ban 1.00; it's already banned by PMS- quoting from
names.tex:
A version starts with the number part, which is in the form
\t{[0-9]+($\backslash$.[0-9]+)*} (a positive
integer, followed by zero or more dot-prefixed positive integers).
Note the 'positive integers'; so 1.00 is actually blocked by PMS.
That said, that same text seems to invalidly ban 1.0 also.
Zero is a positive integer! We'd've said 'natural' if we wanted to ban
zero... Having said that, send a patch if you think we should cater to
people using other definitions.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] explicit -r0 in ebuild filename
On Sunday 30 March 2008, Ciaran McCreesh wrote: Mike Frysinger [EMAIL PROTECTED] wrote: those arent the same thing. -r# is a Gentoo-specific revision marking. _alpha/_rc/etc... are used to track upstream. if upstream uses _alpha0, then it makes our lives easier to also use _alpha0. -r0 has no benefit and it isnt inconsistent as that portion of the version is for Gentoo use only. Every other part allows the magic 0 behaviour. Banning it for one part only is another one of those 'special case' rules we're trying to avoid because no-one knows them. i dont particularly care about -r0, i'm just stating that banning _alpha0/etc... is not acceptable. besides, enforcing no -r0 in the tree is easy to do with a server side hook. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/iproute2: ChangeLog iproute2-2.6.24.20080108.ebuild
Donnie Berkholz [EMAIL PROTECTED] said:
On 17:26 Sat 29 Mar , Mike Frysinger (vapier) wrote:
1.1 sys-apps/iproute2/iproute2-2.6.24.20080108.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/iproute2/iproute2-2.6.24.20080108.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/iproute2/iproute2-2.6.24.20080108.ebuild?rev=1.1content-type=text/plain
local check base=${PORTAGE_CONFIGROOT}/etc/portage/patches
for check in {${CATEGORY}/${PF},${CATEGORY}/${P},${CATEGORY}/${PN}}; do
EPATCH_SOURCE=${base}/${CTARGET}/${check}
[[ -r ${EPATCH_SOURCE} ]] ||
EPATCH_SOURCE=${base}/${CHOST}/${check}
[[ -r ${EPATCH_SOURCE} ]] || EPATCH_SOURCE=${base}/${check}
if [[ -d ${EPATCH_SOURCE} ]] ; then
EPATCH_SUFFIX=patch
EPATCH_FORCE=yes \
EPATCH_MULTI_MSG=Applying user patches from
${EPATCH_SOURCE} ... \
epatch
break
fi
done
This looks like it should be generic code somewhere else.
Actually, I'd say this should just be removed. If a user wants to apply
a patch, they can put their own ebuild into an overlay and do it
themselves (presumably if they want to patch something, they'll know how
to make the simple modifications to an ebuild). By allowing the user to
arbitrarily patch something means we have no idea what the user has
built and is filing a bug about. If they installed an ebuild from an
overlay it is a lot easier to identify what they built. Sure, they
could patch the ebuild in their tree, but by supporting user supplied
patches easily in this way, we are encouraging them to patch things
without our knowledge. If we start supporting this across the board, I
can see bugs being filed when their patches break and they don't
understand what is happening.
Thanks,
--
Mark Loeser
email - halcy0n AT gentoo DOT org
email - mark AT halcy0n DOT com
web - http://www.halcy0n.com
pgp00OFv13uhm.pgp
Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/iproute2: ChangeLog iproute2-2.6.24.20080108.ebuild
Mark Loeser schrieb: Mike Frysinger [EMAIL PROTECTED] said: that's actually exactly what i'm encouraging. i'm not worried about such issues as they're easily resolved by people posting the full build log. Which is great, but I think this is something we should discuss and figure out if this is something we want to introduce into the tree (too late now, but better late than never). If it is something we want to move forward with, it should be introduced at the package manager level instead of being an in-tree package manager specific feature. I'm coming at this from a QA perspective and if we want to do it for one package, it should be introduced for all. We should document it and know how to support it as well. +1 on that, quite a bunch of overlayed ebuilds won't be needed if additional patches could be applied this way. we should just find a way to enable/disable this and make it visible on support requests. Greetz -Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/iproute2: ChangeLog iproute2-2.6.24.20080108.ebuild
On Sun, 30 Mar 2008 17:18:44 -0400
Mark Loeser [EMAIL PROTECTED] wrote:
If it is something we want to move forward with, it should be
introduced at the package manager level instead of being an in-tree
package manager specific feature.
cat /etc/paludis/hooks/ebuild_unpack_post/patches.bash
(
einfo Looking for user patches
cd ${S}
patchdir=/etc/paludis/autopatch/${CATEGORY}/${PN}
if [[ -d $patchdir ]] ; then
einfo Applying user patches
for p in $patchdir/*.patch ; do
einfo Applying $(basename ${p} )
patch -p1 ${p} || exit 1
done
einfo Done
fi
)
Not that I'd really encourage its use...
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/iproute2: ChangeLog iproute2-2.6.24.20080108.ebuild
Ciaran McCreesh kirjoitti:
On Sun, 30 Mar 2008 17:18:44 -0400
Mark Loeser [EMAIL PROTECTED] wrote:
If it is something we want to move forward with, it should be
introduced at the package manager level instead of being an in-tree
package manager specific feature.
cat /etc/paludis/hooks/ebuild_unpack_post/patches.bash
(
einfo Looking for user patches
cd ${S}
patchdir=/etc/paludis/autopatch/${CATEGORY}/${PN}
if [[ -d $patchdir ]] ; then
einfo Applying user patches
for p in $patchdir/*.patch ; do
einfo Applying $(basename ${p} )
patch -p1 ${p} || exit 1
done
einfo Done
fi
)
Not that I'd really encourage its use...
A similar hook can be rewritten (and I think solar already has) using
Portage bashrc support so we already have the custom patching support.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] New developer: Ahmed Ammar (b33fc0d3)
Petteri Räty wrote: Joining us from the land of the pyramids, we have Ahmed b33fc0d3 Ammar. w3l(0m3 4b04rd, 4hm3d. (h33r5, -jk7 -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] explicit -r0 in ebuild filename
On Sun, Mar 30, 2008 at 02:59:39PM -0400, Mike Frysinger wrote: On Sunday 30 March 2008, Ciaran McCreesh wrote: Mike Frysinger [EMAIL PROTECTED] wrote: those arent the same thing. -r# is a Gentoo-specific revision marking. _alpha/_rc/etc... are used to track upstream. if upstream uses _alpha0, then it makes our lives easier to also use _alpha0. -r0 has no benefit and it isnt inconsistent as that portion of the version is for Gentoo use only. Every other part allows the magic 0 behaviour. Banning it for one part only is another one of those 'special case' rules we're trying to avoid because no-one knows them. i dont particularly care about -r0, i'm just stating that banning _alpha0/etc... is not acceptable. Lay out your reasons please; the meaning doesn't differ (same version due to implicit 0 after all), and as I've pointed out an extreme minority are affected. Basically, looking to lock it down from a consistancy standpoint- in light of that, and that 15 ebuilds are affected out of ~24242, it's not seeming like it's losing much. ~harring pgprgCln6jLud.pgp Description: PGP signature
Re: [gentoo-dev] explicit -r0 in ebuild filename
On Sun, 30 Mar 2008 16:40:46 -0700 Brian Harring [EMAIL PROTECTED] wrote: i dont particularly care about -r0, i'm just stating that banning _alpha0/etc... is not acceptable. Lay out your reasons please; the meaning doesn't differ (same version due to implicit 0 after all) But the PV does. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] explicit -r0 in ebuild filename
On Mon, Mar 31, 2008 at 12:46:33AM +0100, Ciaran McCreesh wrote: On Sun, 30 Mar 2008 16:40:46 -0700 Brian Harring [EMAIL PROTECTED] wrote: i dont particularly care about -r0, i'm just stating that banning _alpha0/etc... is not acceptable. Lay out your reasons please; the meaning doesn't differ (same version due to implicit 0 after all) But the PV does. PV varying first of all, isn't incredibly grand from where I'm sitting- yet more any versionator style code has to account for. Second, so what? We're talking about 15 ebuilds here. It's not as though the ebuilds are completely screwed in this- dealing with the PV change for the ebuild is pretty minor. ~harring pgpYxtwxhqVeV.pgp Description: PGP signature
Re: [gentoo-dev] explicit -r0 in ebuild filename
On Sun, 30 Mar 2008 17:02:16 -0700 Brian Harring [EMAIL PROTECTED] wrote: But the PV does. PV varying first of all, isn't incredibly grand from where I'm sitting- yet more any versionator style code has to account for. Second, so what? We're talking about 15 ebuilds here. It's not as though the ebuilds are completely screwed in this- dealing with the PV change for the ebuild is pretty minor. But pointless, since it gives no advantage. If there were something to be gained from what you're proposing then maybe fifteen ebuilds wouldn't be so big a deal, but there isn't. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2008-03-30 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2008-03-30 23h59 UTC. Removals: dev-java/cryptix2008-03-24 22:00:11 caster dev-java/cryptix-asn1-bin 2008-03-24 22:00:12 caster dev-java/cryptix-jce-bin2008-03-24 22:00:13 caster dev-java/javamake-bin 2008-03-24 22:05:36 caster dev-java/minml2 2008-03-24 22:08:53 caster dev-java/jasmin-sable 2008-03-24 22:12:00 caster www-servers/orion 2008-03-24 22:35:10 betelgeuse dev-java/jsx2008-03-24 22:36:28 betelgeuse app-laptop/smcinit 2008-03-25 12:58:32 s4t4n sys-apps/tcb2008-03-27 14:44:47 flameeyes sys-apps/baselayout-lite2008-03-30 15:04:45 vapier Additions: gnome-base/gvfs 2008-03-24 00:13:44 leio dev-libs/libgweather2008-03-24 00:22:10 eva media-plugins/vdr-atscepg 2008-03-24 09:55:01 hd_brummy dev-util/gtk-doc-am 2008-03-24 15:34:57 dang sys-cluster/pypvm 2008-03-24 22:20:30 dberkholz sys-cluster/pbs-python 2008-03-24 22:22:04 dberkholz media-fonts/proggy-fonts2008-03-24 23:06:12 yngwin media-fonts/webby-fonts 2008-03-24 23:08:44 yngwin sci-mathematics/lybniz 2008-03-25 00:04:02 bicatali sys-boot/mbr-gpt2008-03-25 08:40:43 robbat2 x11-libs/openmotif-compat 2008-03-25 15:23:28 ulm net-p2p/frostwire 2008-03-25 17:43:16 wltjr dev-python/rdflib 2008-03-25 20:02:32 pythonhead app-misc/iguanaIR 2008-03-26 17:04:17 hd_brummy gnome-extra/mousetweaks 2008-03-26 22:45:13 eva sys-auth/tcb2008-03-27 14:45:01 flameeyes net-misc/mediatomb 2008-03-27 17:32:57 flameeyes sci-libs/parmetis 2008-03-27 19:01:47 bicatali app-emacs/grep-edit 2008-03-27 19:24:20 ulm media-plugins/vdr-extb 2008-03-27 22:17:38 hd_brummy dev-java/jazzy 2008-03-28 14:23:03 betelgeuse net-analyzer/centreon 2008-03-28 18:38:06 hollow dev-libs/ossp-uuid 2008-03-28 23:45:48 dev-zero media-sound/miniaudicle 2008-03-29 23:21:04 cedk media-sound/audicle 2008-03-30 00:20:06 cedk media-sound/sndpeek 2008-03-30 00:30:05 cedk media-sound/tapestrea 2008-03-30 00:52:47 cedk -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-java/cryptix,removed,caster,2008-03-24 22:00:11 dev-java/cryptix-asn1-bin,removed,caster,2008-03-24 22:00:12 dev-java/cryptix-jce-bin,removed,caster,2008-03-24 22:00:13 dev-java/javamake-bin,removed,caster,2008-03-24 22:05:36 dev-java/minml2,removed,caster,2008-03-24 22:08:53 dev-java/jasmin-sable,removed,caster,2008-03-24 22:12:00 www-servers/orion,removed,betelgeuse,2008-03-24 22:35:10 dev-java/jsx,removed,betelgeuse,2008-03-24 22:36:28 app-laptop/smcinit,removed,s4t4n,2008-03-25 12:58:32 sys-apps/tcb,removed,flameeyes,2008-03-27 14:44:47 sys-apps/baselayout-lite,removed,vapier,2008-03-30 15:04:45 Added Packages: gnome-base/gvfs,added,leio,2008-03-24 00:13:44 dev-libs/libgweather,added,eva,2008-03-24 00:22:10 media-plugins/vdr-atscepg,added,hd_brummy,2008-03-24 09:55:01 dev-util/gtk-doc-am,added,dang,2008-03-24 15:34:57 sys-cluster/pypvm,added,dberkholz,2008-03-24 22:20:30 sys-cluster/pbs-python,added,dberkholz,2008-03-24 22:22:04 media-fonts/proggy-fonts,added,yngwin,2008-03-24 23:06:12 media-fonts/webby-fonts,added,yngwin,2008-03-24 23:08:44 sci-mathematics/lybniz,added,bicatali,2008-03-25 00:04:02 sys-boot/mbr-gpt,added,robbat2,2008-03-25 08:40:43 x11-libs/openmotif-compat,added,ulm,2008-03-25 15:23:28 net-p2p/frostwire,added,wltjr,2008-03-25 17:43:16 dev-python/rdflib,added,pythonhead,2008-03-25 20:02:32 app-misc/iguanaIR,added,hd_brummy,2008-03-26 17:04:17 gnome-extra/mousetweaks,added,eva,2008-03-26 22:45:13 sys-auth/tcb,added,flameeyes,2008-03-27 14:45:01 net-misc/mediatomb,added,flameeyes,2008-03-27 17:32:57 sci-libs/parmetis,added,bicatali,2008-03-27 19:01:47 app-emacs/grep-edit,added,ulm,2008-03-27 19:24:20 media-plugins/vdr-extb,added,hd_brummy,2008-03-27 22:17:38 dev-java/jazzy,added,betelgeuse,2008-03-28 14:23:03 net-analyzer/centreon,added,hollow,2008-03-28 18:38:06 dev-libs/ossp-uuid,added,dev-zero,2008-03-28 23:45:48 media-sound/miniaudicle,added,cedk,2008-03-29 23:21:04 media-sound/audicle,added,cedk,2008-03-30 00:20:06 media-sound/sndpeek,added,cedk,2008-03-30 00:30:05 media-sound/tapestrea,added,cedk,2008-03-30 00:52:47 Done.
Re: [gentoo-dev] explicit -r0 in ebuild filename
On Mon, Mar 31, 2008 at 01:06:02AM +0100, Ciaran McCreesh wrote: On Sun, 30 Mar 2008 17:02:16 -0700 Brian Harring [EMAIL PROTECTED] wrote: But the PV does. PV varying first of all, isn't incredibly grand from where I'm sitting- yet more any versionator style code has to account for. Second, so what? We're talking about 15 ebuilds here. It's not as though the ebuilds are completely screwed in this- dealing with the PV change for the ebuild is pretty minor. But pointless, since it gives no advantage. If there were something to be gained from what you're proposing then maybe fifteen ebuilds wouldn't be so big a deal, but there isn't. Conversation is going pretty cyclical, so unless *new* points are brought up, I'll be waiting for new commentary. Going to reiterate this one more time; the proposal is simple enough; if it's an implicit 0 via cpv parsing, it should *not* be explicitly specified on disk. 'diffball-1.0_alpha0.ebuild' can just as easily be specified as 'diffball-1.0_alpha.ebuild', 'diffball-1.0-r0.ebuild' can just as easily be specified as 'diffball-1.0.ebuild'. Reiterating the gain: consistancy on disk, consistancy in dealing with PV/PVR. As you keep point out, PV does vary- having the results of ebuild execution change depending on whether or not you name your ebuild 'diffball-1.0_alpha0.ebuild' or 'diffball-1.0_alpha.ebuild' is *not* a feature, it is what you would classically call a design misfeature. PVR for 'diffball-1.0-r0.ebuild' being '1.0' instead of '1.0-r0' is yet another argument for punting explicit -r0 on disk- it's a gotcha, design flaw in the format. It's a simple tweak, with no real loss of functionality (lots of claims, no single hard proof thus far). As spanky has stated, there *is* a loss of ease of use in a small subset of ebuilds- worst case, .06% ebuilds. Personally, I don't consider that minority worth preserving since preserving that means leaving open several gotchas in ebuild writing, and complicates interactions (both pm and dev). So... there it is. Would be rather nice to have ebuild devs weight in on this one, rather then just package manager monkeys also (they're the ones bound most by the change after all). Laid out the advantages to this- kindly lay out the disadvantages, where this makes things worse if you're looking for a response. ~harring pgpGD8zDrXnLu.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/iproute2: ChangeLog iproute2-2.6.24.20080108.ebuild
On Sunday 30 March 2008, Mark Loeser wrote: Mike Frysinger [EMAIL PROTECTED] said: On Sunday 30 March 2008, Mark Loeser wrote: Actually, I'd say this should just be removed. If a user wants to apply a patch, they can put their own ebuild into an overlay and do it themselves (presumably if they want to patch something, they'll know how to make the simple modifications to an ebuild). By allowing the user to arbitrarily patch something means we have no idea what the user has built and is filing a bug about. If they installed an ebuild from an overlay it is a lot easier to identify what they built. Sure, they could patch the ebuild in their tree, but by supporting user supplied patches easily in this way, we are encouraging them to patch things without our knowledge. If we start supporting this across the board, I can see bugs being filed when their patches break and they don't understand what is happening. that's actually exactly what i'm encouraging. i'm not worried about such issues as they're easily resolved by people posting the full build log. Which is great, but I think this is something we should discuss and figure out if this is something we want to introduce into the tree (too late now, but better late than never). If it is something we want to move forward with, it should be introduced at the package manager level instead of being an in-tree package manager specific feature. I'm coming at this from a QA perspective and if we want to do it for one package, it should be introduced for all. We should document it and know how to support it as well. there is no package-manager specificness here. it's already completely doable from a user perspective, just having it in the ebuild makes my life and users' lives easier. i'm using it in packages that tend to have a lot of extraneous patchsets associated with them. the random patches were punted from ebuilds and now it's up to the user to maintain the feature sets. -mike signature.asc Description: This is a digitally signed message part.
