[gentoo-dev] Last rites: dev-java/ant*-1.8.1
1.8.1 has been stable for quite some time so let's get rid of 1.7.x +# Vlastimil Babka cas...@gentoo.org (15 Feb 2011) +# Masked for removal of all versions older than 1.8.1 in few weeks. +dev-java/ant-core-1.8.1 +dev-java/ant-antlr-1.8.1 +dev-java/ant-apache-bcel-1.8.1 +dev-java/ant-apache-bsf-1.8.1 +dev-java/ant-apache-log4j-1.8.1 +dev-java/ant-apache-oro-1.8.1 +dev-java/ant-apache-regexp-1.8.1 +dev-java/ant-apache-resolver-1.8.1 +dev-java/ant-apache-xalan2-1.8.1 +dev-java/ant-commons-logging-1.8.1 +dev-java/ant-commons-net-1.8.1 +dev-java/ant-jai-1.8.1 +dev-java/ant-javamail-1.8.1 +dev-java/ant-jdepend-1.8.1 +dev-java/ant-jmf-1.8.1 +dev-java/ant-jsch-1.8.1 +dev-java/ant-junit-1.8.1 +dev-java/ant-junit4-1.8.1 +dev-java/ant-nodeps-1.8.1 +dev-java/ant-swing-1.8.1 +dev-java/ant-testutil-1.8.1 +dev-java/ant-trax-1.8.1 +dev-java/ant-1.8.1
Re: [gentoo-dev] News item: Dropping Java support on ia64 (retry)
Hi, since Betelgeuse didn't actually commit the news item in November, here's my try. Slightly reworded the text, comments welcome. Otherwise I plan to commit this on Friday. Thanks, Vlastimil On 11/14/2010 08:36 PM, Petteri Räty wrote: Any improvements to the text are welcome. Regards, Petteri Title: Pending Removal of Java support on ia64 Author: Petteri Räty betelge...@gentoo.org Author: IA64 Arch Team i...@gentoo.org Author: Vlastimil Babka cas...@gentoo.org Content-Type: text/plain Posted: 2011-02-18 Revision: 1 News-Item-Format: 1.0 Display-If-Keyword: ia64 Display-If-Installed: dev-java/java-config Since the IA64 arch team does not have the resources to maintain Java support, we have agreed that ia64 keywords will be dropped from Java packages, and the java USE flag masked on ia64, unless more manpower becomes available. If you are willing to help with the maintenance, please contact i...@gentoo.org. If there is no interest, the removal of Java support well be done during the second half of March 2011. The removal is tracked in bug #345433.
[gentoo-dev] Packaging LSB symlinks for ld-linux.so
Hi, when trying to bump sci-geosciences/googleearth to a 6 beta version [1], there's a problem with missing /lib/ld-lsb.so.3 file, which the binary somehow requires, and otherwise fails with a rather cryptic error message (saying that the binary itself is missing). Apparently this is mandated by LSB and some distros provide it in packages such as lsb-core (debian/ubuntu), redhat-lsb (fedora) or glibc-lsb (mandriva), possibly along with other files. It's always a symlink to ld-linux.so.2. Gentoo only seems to have one lsb-related package (sys-apps/lsb-release) which is just some query script. So, I think the options are: 1) adding the symlink to the googleearth itself 2) adding an extra package for the symlinks 3) adding the symlink to glibc itself 4) working around it somehow I've tried 4) with no luck (executing ld-linux.so.2 googleearth-bin, trying LD_LIBRARY_PATH overrides, putting ld-lsb.so.3 symlink in the same directory as the binary), nothing worked except creating the symlink under /lib. If there was a way, it would be easiest for me. Doing 1) would be easy but rather incorrect and possibly result in collisions in the future. Doing 3) would be a question for glibc maintainers (didn't try yet), but I guess they won't like it. Doing 2) is a question of what package to put it in and what else to put there. Frankly, I don't want to study all of LSB to see what's the lsb-core/redhat-lsb packages about, just to get googleearth working, if there's no general interest in LSB compliance. The mandriva approach seems easiest for my needs (it's just the ld symlinks and nothing more). But I understand that I shouldn't make such decision myself, so I ask here. Thoughs? Thanks, Vlastimil [1] https://bugs.gentoo.org/show_bug.cgi?id=348911
Re: [gentoo-dev] Packaging LSB symlinks for ld-linux.so
On 01/31/2011 04:23 PM, Nathan Phillip Brink wrote: Have you checked if patchelf can fix the googleearth binary? I think that it is intended for this sort of problem: http://nixos.org/patchelf.html . Thank you, this really helped! And since patchelf is in the tree, I could workaround googleearth immediately (which allowed the long overdue version bump). But if there's any outcome regarding the LSB symlinks, I will be happy to switch it. Vlastimil
Re: [gentoo-dev] metadata.xml: changepolicies
On 02/25/2010 02:41 PM, Markos Chandras wrote: On Thursday 25 February 2010 08:22:17 Ulrich Mueller wrote: On Wed, 24 Feb 2010, Robin H Johnson wrote: Metadata.xml should allow use of achangepolicies element. Within the element, package maintainers should be able to describe how non-maintainer changes to the package are handled. Could we allow this element in the category metadata files, too? Its value there would be the default for the category, with the possibility to override it for individual packages. Ulrich How are you so sure that a general rule can apply to a whole category? E.g. the x11-misc/ one. Which rule for non-maintainer changes are you going to apply since every single developer is maintaining a x11-misc application? Same for app-misc etc. I think it would make more sense in herds.xml. Not sure about packages with more than one herd though :) maybe use the stricter one? This would definitely need some tool support for simple queries, to be usable. Vlastimil
Re: [gentoo-dev] Re: QA: package.mask policies
Duncan wrote: In theory that's what those stupid version string thingys are for, but it's s much easier just to forget one! =:^[ Maybe something about this should go in the handbook -- a suggestion that if one is going to use a package.unmask entry, that they copy the package.mask entry over, thus at least letting the devs minimize the version spread damage with their package.mask entries. That's what I've started doing, and it works surprisingly well, as I have right there the comment on why it was masked (and add a comment on why I'm unmasking, when I think I might wonder, later), and it's the exact same versions the devs masked in the first place, so I don't have to worry so much about unintended version spread -- at least as long as the devs doing the masking worried about it then. =:^) What do you devs think? Would that be a practical hint for the handbook? Would it be helpful in allowing /you/ to control the version spread of the unmask, by consequence of your control of the version spread on the mask in the first place? Hi, handbook is one thing, but maybe portage could make it more prominent when it displays the packages to be merged, so that the users hopefuly notice? - visibly distinguish (red color and stuff?) packages that are to be installed thanks to package.unmask or ** keyword - print extra warnings about those entries in package.unmask and ** keywords that are not version restricted, if they contain the packages to be merged. This could follow the suggestion above - aside from the distinguished packages, below the list and above the yes/no (if --ask is used) there would be Warning: the following packages have broad unmasks, you sure you want these versions? and the list. Vlastimil
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild
Ben de Groot wrote: 2009/11/8 Mark Loeser halc...@gentoo.org: Also, please learn how to communicate in a manner that is constructive instead of acting like a dick at every opportunity. Looks to me this should be applied to some others in this thread first. Really, aren't there more constructive ways to communicate your (meaning all of you in this thread) concerns, without demotivating the person who does so much work for Gentoo? Cheers, I totally agree. And I must say it started with the very first mail of pva. Accusing of not knowing quizzes was totally uncalled for. As patrick said, the SRC_URI thing was simply forgot to be polished after testing, and the dobin thing he didn't even touch. Who remembers what everything should have || die or not from the top of his head and spots it immediatelly? And this offensive tone just provoked adequate reaction and here we are, useless flame. People can sometimes commit much worse stuff by mistake, this didn't break anything. If the first mail was just a 'hey this should bw changed to X and Y', that could be it. It's great that somebody cares to fix stuff, it's also great that somebody watches the commits for mistakes, but let's be civilized about it. Vlastimil
Re: [gentoo-dev] Illegal news item name
Zac Medico wrote: Vlastimil Babka wrote: The question is what to do now, rename it? Users will then see it again, and I don't know if there are even worse consequences. AFAIK, seeing it again is the worst that will happen. The cvs - rsync script will ensure that the incorrectly named new item is deleted on the rsync side after it's removed from cvs. Hi, unfortunately this is what happens in current eselect-news. # eselect news list Unread news items: (none found) Read news items: 2009-04-18-java-config-wrapper-0.16 (no title available) 2009-04-18-java_generation1_deprecation Generation 1 Java Setup Deprecated # eselect news read all 2009-04-18-java-config-wrapper-0.16 /usr/share/eselect/modules/news.eselect: line 92: /usr/portage/metadata/news/2009-04-18-java-config-wrapper-0.16/2009-04-18-java-config-wrapper-0.16.en.txt: No such file or directory /usr/share/eselect/modules/news.eselect: line 99: /usr/portage/metadata/news/2009-04-18-java-config-wrapper-0.16/2009-04-18-java-config-wrapper-0.16.en.txt: No such file or directory 2009-04-18-java_generation1_deprecation ... This is because the old entry stays in /var/lib/gentoo/news/news-gentoo.read Executing 'eselect news purge' will fix that, but obviously with the side effect of purging everything else :) So what to do? Fix eselect first and then do the rename? Rename now, recommend purge, and fix eselect later? Update GLEP 42 to allow dots in news item filenames? Any technical reason they are not allowed, except for hypothetical compatibility (nothing broken was reported due to this item yet). (attached is the renamed version with bumped revision and note explaining users that they might see this twice because it was renamed) Thanks, Vlastimil Title: Generation 1 Java Setup Deprecated Author: Petteri Räty betelge...@gentoo.org Content-Type: text/plain Posted: 2009-04-18 Revision: 3 News-Item-Format: 1.0 Display-If-Installed: =dev-java/java-config-wrapper-0.16 Note: Apologies for reading this news item twice. It had to be renamed to comply with news item specitication, which may result in a news reader detecting a new item. For a long time the Java team required a 1.4 JDK to be installed in order for old java ebuilds to work. All these ebuilds are now gone from the main tree so the requirement to have a 1.4 JDK installed has been lifted. In order to remove things left over by the generation 1 setup please run java-check-environment and follow the instructions. If you want to remove 1.4 JDKs, you should use emerge --depclean. Depending on what you have installed you might not need a 1.4 JDK any more. To see if you still need a 1.4 JDK use: emerge -av --depclean virtual/jdk:1.4 If you don't need virtual/jdk:1.4 any more then you can remove the individual JDKs. First get the list of installed JDKs with eselect and then remove those that are not needed any longer with depclean, for example: eselect java-vm list emerge -av --depclean sun-jdk:1.4 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Illegal news item name
Hi, it was brought up by ulm that the news item '2009-04-18-java-config-wrapper-0.16' has an illegal name because it contains a dot. As it was me who named and commited it, I am sorry for this mistake. The file name in -dev review mail was called 'generation1-deprecation' and I probably should have just added the date to it and not try to stick to the package name + version. My bad. The question is what to do now, rename it? Users will then see it again, and I don't know if there are even worse consequences. Betelgeuse suggested also commit hook that would check filenames. Cheers, Vlastimil
Re: [gentoo-dev] Retiring
Peter Faraday Weller wrote: On a more serious note, the problem seems to be the complete lack of management in the required places, Gentoo is fast becoming (or more likely, already is) an anarchic organisation, where it's becoming nigh-on impossible to keep track of things. I see a number of issues with Gentoo these days. The lack of a proper leadership body. Lack of people working together in unison. The tree needs to be sorted out: we have 16000 packages, and 200-250 developers, not all of which are ebuild developers) - We're still using CVS, we do *not* have the manpower to keep all the packages updated properly using a centralised VCS. If these issues were fixed, I don't know/care how they do get fixed, but if they were, I might consider coming back. Hi, am I the only one to see a contradiction here? You criticise a centralised VCS and anarchism/lack of unison work at the same time. Wouldn't that be even worse with a distributed VCS then? :) I think it would. Also too much use of overlays seems bad to me (yeah the Java team is very guilty here :) and the idea of splitting tree to overlays (which pops up from time to time) is just nonsense IMHO. It seems that some people think distributed VCS (git) is a silver bullet that will fix everything? Or pushing more and more EAPI's will? I'm quite sure it won't fix the lack of focus. Which I somewhat feel too, but that may be just from the fact that I currently lack time (not motivation though, that seems almost inversely proportional :) ) for Gentoo. If more people agree on the lack of focus, then we should do something about it, instead of hoping that using better tools fixes it themselves. Vlastimil
[gentoo-dev] Last rites: dev-java/ant*-1.7.0* and whole dev-java/ant-tasks
dev-java/ant-tasks was a meta ebuild that is no longer used in 1.7.1 so it's going away completely # Vlastimil Babka cas...@gentoo.org (30 Apr 2009) # masked for removal, bug #261563 =dev-java/ant-core-1.7.0* =dev-java/ant-antlr-1.7.0* =dev-java/ant-apache-bcel-1.7.0* =dev-java/ant-apache-bsf-1.7.0* =dev-java/ant-apache-log4j-1.7.0* =dev-java/ant-apache-oro-1.7.0* =dev-java/ant-apache-regexp-1.7.0* =dev-java/ant-apache-resolver-1.7.0* =dev-java/ant-commons-logging-1.7.0* =dev-java/ant-commons-net-1.7.0* =dev-java/ant-jai-1.7.0* =dev-java/ant-javamail-1.7.0* =dev-java/ant-jdepend-1.7.0* =dev-java/ant-jmf-1.7.0* =dev-java/ant-jsch-1.7.0* =dev-java/ant-junit-1.7.0* =dev-java/ant-junit4-1.7.0* =dev-java/ant-nodeps-1.7.0* =dev-java/ant-swing-1.7.0* =dev-java/ant-trax-1.7.0* dev-java/ant-tasks =dev-java/ant-1.7.0* signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last Rites: games-puzzle/ksudoku
Richard Freeman wrote: Tobias Scherbaum wrote: Wouldn't it make much more sense to package move ksudoku then? I was thinking the same thing - this is a stable package, so ideally it shouldn't be replaced with an unstable one. Why not keep -0.4 in the tree for stable users? +1 Also the games-puzzle one is for kde-3, the kde-base one for kde-4, so as long as we keep kde-3... There's also bug 257162 about this already. Caster signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Usage of econf with an additional || die
Thomas Sachau wrote: I see many ebuild that still use econf || die, also econf should die by itself. Are there any specific reasons for this? Some cases where econf does not die also it fails? Or some other reason for this? My guess is that due to the general lack of consistency in what dies and what not, people either make mistakes or just take the safe route? Caster signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Making built_with_use die by default with EAPI 2
David Leverton wrote: On Saturday 20 September 2008 18:15:27 Alexis Ballier wrote: I can think of checks like: - foo is a dep/rdep of bar - foo has a plugin like architecture - bar will work with minimal foo - most people will expect some features in bar that come with foo's plugins - we might want to display warnings for the most useful features - having useflags in bar for each of foo's useflags doesn't seem wise If you mean something like built_with_use cat/foo coolfeature || ewarn bar will be more useful if you rebuild cat/foo with USE=coolfeature then you can use has_version 'cat/foo[coolfeature]' || ... instead. Which is much better because it's handled directly with the PM and not eutils going looking in vdb by hand, right. In that case we should really encourage this and make built_with_use die or at least emit a qa warning? The only downside is that use deps don't support the --missing stuff and we'll see how big problem this turns out to be in practice... Caster signature.asc Description: OpenPGP digital signature
[gentoo-dev] Preventing $ARCH flags in USE
Apparently, setting USE=x86 in make.conf on amd64 arch can have funny consequences such as [1]. And I can imagine even more subtle and hard to detect errors due to this. I think it's better to prevent this rather than waste time with bug reports like that. I asked Zac on IRC whether portage could filter such flags. He suggested using use.mask in profiles. Well since ARCH is also set by a profile, why not. Although a really persistent and stupid user could use.unmask, it's better than no protection. And then we can think how to replace the current ARCH-USE flag system with e.g. USE_EXPAND. What do you think? Vlastimil [1] http://bugs.gentoo.org/show_bug.cgi?id=236801 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: GLEP 55
Fernando J. Pereda wrote: On 10 Jun 2008, at 15:33, Joe Peterson wrote: Luca Barbato wrote: Check if exists a line EAPI=*$, if does and the rest of the string matches an understood eapi, go on sourcing, otherwise ignore/mask it... And placing it out-of-band (like # EAPI=...) avoids any sourcing errors, makes parsing faster, etc. No, it doesn't make parsing faster. Had you bothered to profile any package manager you'd know that. How much is parsing speed relevant when users in majority of cases already have the metadata cache from the rsync servers? For devs (or users) hacking on an ebuild they have to source it anyway so the addition pre-parsing is negligible... VB -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
Joe Peterson wrote: The problem with a simple echo is that no * appears on the left to maintain continuity with the rest of the output - and in a color that makes sense in the context (maybe this isn't a problem - it depends on whether that visual continuity is desired). The far biggest problem of echo is IMHO that it's not part of the elog framework, which means you will see only it if you are watching the thing build. But it won't be processed by anything else set in PORTAGE_ELOG_SYSTEM, for example the echo system which reprints all gathered elog stuff from all built packages when emerge finishes, and which I find very useful. Absence of newlines there makes that however often hardly readable. Using elog commands instead of plain echo helps this, but as you mentioned, could be done better. So I'm also for some *unified* way to specify separators in elog commands. I would prefer something that doesn't add extra lines to ebuild. So how bout some switch to elog commands that adds extra newline after the message, might look better than wltjr's proposal. There could be also switch to add newline before the message but I can't think of a use for it myself. The question is how to name the switch :) -n could be confusing as echo -n has the opposite effect. Maybe -b for blank? -- Vlastimil Babka (Caster) Gentoo/Java signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [GLEP56] USE flag descriptions in metadata
Doug Goldstein wrote: 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. What reason does the QA Project have to disallow such thing? Is it just so that package-specific info does not concentrate in one huge file? Or is it the danger that the meaning of package-specific flags would drift too far from the global flag's meaning and lead to confusion? If it's the first, then metadata.xml seems like a good place. If the latter, then it wouldn't make much sense to approve the syntax and then disallowing it by QA :) I encourage any and all _technical_ feedback. Technically, I think linking to blogs, especially outside of g.o domain is not the best thing durability-wise :) -- Vlastimil Babka (Caster) Gentoo/Java signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [GLEP56] USE flag descriptions in metadata
Marius Mauch wrote: It's not about forcing anyone to do something but giving people enough information on how to implement it _if they choose to do so_. With the current GLEP they'd have to make arbitrary decisions if e.g. a flag is defined in both use.local.desc and metadata.xml, or some people might think that it replaces use.local.desc completely. Really, all I'm looking for is something like This proposal does not intend to replace the existing use.local.desc format. If a flag is defined for a package in both use.local.desc and metadata.xml the latter should be preferred by tools ++ I suppose you want people to read the package-specific information and not e.g. fill bug reports caused by wrong assumptions about the flag's meaning. -- Vlastimil Babka (Caster) Gentoo/Java signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Default blank lines for error, elog, einfo, etc
Joe Peterson wrote: The comment from Vlastimil about echo not being part of the elog system is a very valid point indeed. As for how to specify that a newline should be inserted, I think that using elog switches like -n, -p, etc., as well as putting more than one string on a line present two problems: the newline would be connected with the elog or ewarn (or whatever style of output was chosen) In the ebuild it would look like connected but in fact portage could just note that there was a newline switch and output it in whatever style it wants. and it would also potentially make the ebuild code harder to read/debug. Well you can always insert a completely blank line in the ebuild after a -n message. That's easier to read than a eseparator line. For example, if you have a block of ewarn lines, then a blank line, then a block of elog lines, you would have to decide in which style to place the special switch (so portage would not have the opportunity to do auto-context coloring/formatting). Like I said above, it still has the oportunity to do whatever it wants. I personally would prefer a new command like eseparator that could be treated smartly by portage, taking on the appropriate color based on what is before and after. It could also avoid multiple newlines in the case in which two eseparator lines occur together due to pattern of conditional blocks in the ebuild invoked under certain circumstances (I have found this hard to code in a way that covers all possibilities, as I mentioned before). Also, separators at the very beginning or very end of all lines output by the ebuild could be handled consistently (either ignored or collapsed into an implicit separator, as appropriate) by portage to produce nice output. That should all be possible with the switches, unless I miss something. My idea is that a switch for post-newline is enough, and there's no need for pre-newline. You use that switch whenever you end a logical block of elog lines. Portage just notes you used it, and when another elog comes, newline is emitted first. Multiple newlines should not even happen (and if yes, could be easily collapsed). Last newline of the ebuild is just consumed. Or perhaps use this processing only for the elog post-processing system (which I personally think matters more), and during the build itself emit the newlines immediatelly so that non-elog output is not tied too closely to ends of elog blocks. -- Vlastimil Babka (Caster) Gentoo/Java signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] What are blocks used for?
Enrico Weigelt wrote: * Ciaran McCreesh [EMAIL PROTECTED] schrieb: Hi, Hi Enrico, long time no see! b) Marking that two related implementations are mutually incompatible at runtime because they both provide the same binary. Classical example: MTA's: Traditionally they tend to provide an /usr/sbin/sendmail executable. So you can't have multiple MTAs installed. Here the problem isn't that portage can't give more advise, but the system only allows I see you've been missing this list for a long time. Today it's not politically correct to say bluntly portage but package manager (PM)! For example, for class d) blocks such as the recent coreutils / mktemp mess, Yes, this is *really* a mess, especially because critical packages are involved here. IMHO the problem is clearly made by the two packages themselves. Actually I didn't track yet who was first, but according to the ebuilds, the conflict arises w/ 6.10 (not yet in 6.9). IMHO the external mktemp should be preferred and the coreutils's one skipped. Um no, we should not stick with packages forever for historical reasons. the package manager can suggest to the user to install the new package and then uninstall the old package, rather than forcing the user to uninstall the old package by hand (possibly leaving their system without critical utilities) and then install the new package. Yes, but this requires the ebuild author to provide enough information *very carefully*. Yes, ebuild author should be careful, OTOH the end users wouldn't have to be as much careful as they had to be now when dealing with it themselves. In this specific case, portage could automatically decide to replace the separate mktemp package by newer coreutils. But what happens if some package depends on the mktemp package ? Such deps should obviously be transformed to || ( =coreutils-6.10 mktemp) beforehand. Portage has to catch these deps and map them to coreutils if they provide mktemp (and only for those versions which *really do*). No, it should probably just state there's a dep conflict (as it does now if there are several depends asking for different versions inside one slot). This all adds a lot of complexity, and I doubt it's really worth it. Stating dep conflict should be less complexity, and yes it's worth it. Removing mktemp and properly maintaining the standalone package seems much easier and cleaner to me. Sure, legacy and maintainership burden ftw! I'm tempted to say we are not debian but since I'm not council... :( Caster -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Early stabilisation
Samuli Suominen wrote: Wed, 16 Apr 2008 12:09:24 -0700 Chris Gianelloni [EMAIL PROTECTED] kirjoitti: On Wed, 2008-04-16 at 11:49 +0200, Vlastimil Babka wrote: thirty days is the norm for the minimal period between an ebuilds last It is the norm. It is not a requirement. In fact, it is specifically a guideline rather than a hard rule. It is up to the maintainer's discretion when to ask for stabilization, just like it is up to the arch team's discretion when to actually *do* the stabilization. If you don't think that it's ready on your arch, say so, but be prepared to defend why you think so when the package maintainer, who should be much more familiar with the package, thinks that it is ready. Okay. So we can just agree it's better if the maintainer tells his reasons when opening the bug, to spare the later clarifications? On the other hand, maybe these early stabilisation bug reports are a sign of the times and we need to shorten the normal thirty day period, become even more of a cutting edge distro - or at least discuss the options. I'd say leave the current norm and smack the misbehaving maintainers :) Who says that they're misbehaving? Again, the maintainers probably know their packages better than anyone else, so why are we not trusting their judgement again? Thanks for this, I was going to reply in similar fashion but didn't want to (accidentally) start flaming.. Sorry I used a harsh word myself, didn't want to flame neither. Caster -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] What are blocks used for?
Enrico Weigelt wrote: * Ciaran McCreesh [EMAIL PROTECTED] schrieb: Hi, Hi Enrico, long time no see! b) Marking that two related implementations are mutually incompatible at runtime because they both provide the same binary. Classical example: MTA's: Traditionally they tend to provide an /usr/sbin/sendmail executable. So you can't have multiple MTAs installed. Here the problem isn't that portage can't give more advise, but the system only allows I see you've been missing this list for a long time. Today it's not politically correct to say bluntly portage but package manager (PM)! (the kind reader can then usually substitue implementation name depending on the e-mail sender) For example, for class d) blocks such as the recent coreutils / mktemp mess, Yes, this is *really* a mess, especially because critical packages are involved here. IMHO the problem is clearly made by the two packages themselves. Actually I didn't track yet who was first, but according to the ebuilds, the conflict arises w/ 6.10 (not yet in 6.9). IMHO the external mktemp should be preferred and the coreutils's one skipped. Um no, we should not stick with packages forever for historical reasons. the package manager can suggest to the user to install the new package and then uninstall the old package, rather than forcing the user to uninstall the old package by hand (possibly leaving their system without critical utilities) and then install the new package. Yes, but this requires the ebuild author to provide enough information *very carefully*. Yes, ebuild author should be careful, OTOH the end users wouldn't have to be as much careful as they had to be now when dealing with it themselves. In this specific case, portage could automatically decide to replace the separate mktemp package by newer coreutils. But what happens if some package depends on the mktemp package ? Such deps should obviously be transformed to || ( =coreutils-6.10 mktemp) beforehand. Portage has to catch these deps and map them to coreutils if they provide mktemp (and only for those versions which *really do*). No, it should probably just state there's a dep conflict (as it does now if there are several depends asking for different versions inside one slot). This all adds a lot of complexity, and I doubt it's really worth it. Stating dep conflict should be less complexity, and yes it's worth it. Removing mktemp and properly maintaining the standalone package seems much easier and cleaner to me. Sure, legacy and maintainership burden ftw! Including backporting security fixes! I'm tempted to say we are not debian but since I'm not council... :( Caster signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] What are blocks used for?
Enrico Weigelt wrote: * Bernd Steinhauser [EMAIL PROTECTED] schrieb: Hi, e) A package needs a newer version of another package, but doesn't depend on it. This was the case with KDE4. kdelibs-4.0.x block these packages: !kde-base/kdebase-3.5.7-r6 !kde-base/kdebase-startkde-3.5.7-r1 !=kde-base/kdebase-3.5.8 !=kde-base/kdebase-3.5.8-r1 !=kde-base/kdebase-3.5.8-r2 !=kde-base/kdebase-startkde-3.5.8 I don't know very much about KDE stuff, since I got rid of it for a long time, but IMHO it seems there's an principle problem on the install layout - 3.x and 4.x should be completely separate, never conflicting each other. So some package kfoo either depends on kdelibfoo-3.x OR kdelibfoo-4.x. Of course I don't know whether the problems comes from ebuilds or upstream ;-o If you don't know why the blocks nned to be there then why comment on that? -- Vlastimil Babka (Caster) Gentoo/Java signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Early stabilisation
Jeroen Roovers wrote: Dear ebuild maintainers, thirty days is the norm for the minimal period between an ebuilds last non-keywording change while in the tree and the usual call for stabilisation. If you cannot find a pressing reason to push stabilisation forward, then don't ask. In the last few days I have seen several early calls for stabilisation (bugs #217148, #217845, #217841 and #217839 for instance) where no adequate reason was given, in my opinion. Given that 3 of the 4 are from one person, I wouldn't draw broad conclusion from this. A good reason might be an important fix of a severe bug, a fix for a build problem that couldn't be applied to a stable version but had to go into an ebuild revision, or a version/revision that fixes a security problem. On the other hand, maybe these early stabilisation bug reports are a sign of the times and we need to shorten the normal thirty day period, become even more of a cutting edge distro - or at least discuss the options. I'd say leave the current norm and smack the misbehaving maintainers :) Caster -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-portage-dev] Re: Problems with the new no downgrades
Petteri Räty wrote: Vlastimil Babka kirjoitti: *portage-2.1.5_rc1 (04 Apr 2008) 04 Apr 2008; Zac Medico [EMAIL PROTECTED] +portage-2.1.5_rc1.ebuild: 2.1.5_rc1 release. In the event that a previously installed package has since been masked, emerge will no longer perform an automatic downgrade as part of a world update. You should either unmask such packages or else explicitly re-merge them in order to have them dowgraded to an unmasked version. Bug #216231 tracks all bugs fixed since 2.1.4.x. Assuming it's because of bug 197810, but that only talks about packages masked by corruption. But is it really so good to apply this also to keyword/package.mask or even ebuild being removed? For example, we had swt-3.3.1.1 in SLOT=3 and released swt-3.4_pre6 with SLOT=3. Later realized it's not backwards compatible enough and released swt-3.4_pre6-r1 in SLOT=3.4 removing the 3.4_pre6 ebuild. So I would expect the slot 3 to downgrade back to 3.3.1.1 (especially if something pulls slot 3 via slot dep). (Note that we can't use slotmove because changing slot in java package means also changing where it's installed and expected.) Now thanks to this change, downgrade won't happen. I think it's not good. VB You can use atoms like dev-java/swt-3.4_alpha:3 to force it OK that solves my problem, thanks. But in general case I think it's still wrong. Package is found to be broken, gets p.masked, but people will keep the masked version and not downgrade. And because it doesn't even warn about that fact, they won't even know! Caster -- gentoo-portage-dev@lists.gentoo.org mailing list
User patches (Was: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/iproute2: ChangeLog iproute2-2.6.24.20080108.ebuild)
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 think that maybe we should first introduce new patching phase and then make this user patch really usable feature. For example if you want to patch something that's input to running autotools, doing it in post_src_unpack is too late... Caster -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
Petteri Räty wrote: Attached is a patch that fixes this. Arrays? How non-POSIX1 Anyway, why don't we instead discuss what phases to add to next EAPI, so we can avoid these hacks :) -- Vlastimil Babka (Caster) Gentoo/Java signature.asc Description: OpenPGP digital signature
[gentoo-portage-dev] relying on vdb only
Hi, reading comments on bug 209538, I've seen this dangerous thing from Zac: Once these issues are solved it will be nice if we can rely exclusively on the dependencies from /var/db/pkg. Well, the idea that devs will have to revbump packages just for RDEPEND version restrictions so that portage picks it freaks me :) Then there's: I do have a tool that copies metadata from ebuilds but I'd prefer to avoid doing anything like that if possible. So maybe it's time to discuss what's possible? :) If that discussion already happens/happened elsewhere, then sorry for noise and please point me there :) Thanks, Caster -- gentoo-portage-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] VDB access
Zac Medico wrote: If the package manager exposes a slightly lower level interface to the USE flags then build_with_use can use that instead, and the package manager won't have to implement the full build_with_use interface. For example, portageq currently supports a metadata command that can be used to query installed package metadata such as USE and IUSE. Perhaps we should use some type of interface similar to that. I'd say it depends on whether we want to support native_built_with_use just as a temporary workaround until there are use deps (then just package managers not using vdb would implement it, and portage need not care), or we would want to use the general metadata query also for other purposes. Anyway, restricting ebuilds from vdb access sounds like a good idea to me. -- Vlastimil Babka (Caster) Gentoo/Java signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: I want to steal your tools
Ciaran McCreesh wrote: On Mon, 04 Feb 2008 15:59:26 -0600 Ryan Hill [EMAIL PROTECTED] wrote: I want something that anybody can use in their scripts without having to install paludis What's the difference between installing Paludis and installing Perl in order to use a tool? About 10 minutes (YMMV) Mon Nov 19 22:26:38 2007 dev-lang/perl-5.8.8-r4 merge time: 6 minutes and 10 seconds. Wed Nov 7 12:46:01 2007 sys-apps/paludis-0.24.6 merge time: 16 minutes and 25 seconds. -- Vlastimil Babka (Caster) Gentoo/Java signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] new portage categories
Donnie Berkholz wrote: On 20:11 Mon 04 Feb , Jonas Bernoulli wrote: Thinking about it again I would say tags and categories just fulfill different purposes. Tags can not replace categories but might be a useful extension to categories for the tasks I described, not more not less. They are not better or worse, just different:) Why don't you think they can replace categories? For example: # eix -e fuse * app-emulation/fuse Description: Free Unix Spectrum Emulator by Philip Kendall * dev-java/fuse [1] Description: Fuse is a lightweight resource injection library specifically designed for GUI programming. * sys-fs/fuse Description: An interface for filesystems implemented in userspace. Also imagine all those packages sorted into subdirs just by first character of the name (because having them all in one huge dir would be murder), yuck :) -- Vlastimil Babka (Caster) Gentoo/Java signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [RFC] Auto-select slots based on system configuration
Daniel Barkalow wrote: It shouldn't remove the Java VM that java-config is set to. This would be a bit trickier I guess, as every user can have it set differently :) Caster -- gentoo-portage-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Best practices for package.mask removals
Mike Frysinger wrote: On Monday 28 January 2008, Ryan Hill wrote: In your package.mask entry, it would help to have the following info: it would help too if you add a comment like this to the top of the mask file -mike I've did it instead: Index: package.mask === RCS file: /var/cvsroot/gentoo-x86/profiles/package.mask,v retrieving revision 1.8234 diff -u -B -r1.8234 package.mask --- package.mask3 Feb 2008 10:28:21 - 1.8234 +++ package.mask3 Feb 2008 13:06:48 - @@ -3,7 +3,7 @@ # When you add an entry to this file, add your name, the date, and an # explanation of why something is getting masked # -# NOTE: Please add your entry at the top! +# NOTE: Please add your entry at the top (below the examples)! # ## @@ -21,6 +21,25 @@ ## End example ## +## Best last rites (removal) practices, as suggested by +## Ryan Hill [EMAIL PROTECTED] +## +## Include the following info: +## a) reason for masking +## b) bug # for the removal (and yes you should have one) +## c) date of removal (either the date or in x days) +## d) the word removal +## +## Example +## +# Dev Elepor [EMAIL PROTECTED] (25 Jan 2012) +# Masked for removal in 30 days. Doesn't work +# with new libfoo. Upstream dead, gtk-1, smells +# funny. (bug #987654) +#app-misc/some-package +## +## End example, put the real deal below. + # Benedikt Böhm [EMAIL PROTECTED] (03 Feb 2008) # Masked for removal in 30 days wrt #208584 # Does not use webapp/depend.apache eclass correctly signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Changes to some profiles
Chris Gianelloni wrote: Do we really need a front-page news item for this? I don't think the impact would be terribly great, as I suspect this affects a very small number of people whom are likely to be more advanced users. I think adding the info to GMN/gentoo-dev-announce/gentoo-user should suffice. If someone thinks we need to do a front-page article, we can do that, too. IIRC it will affect only 2008 profiles, and not older, so people have to switch profiles first? Which already involves knowing what you're doing? So what about putting up a GMN/front page article announcing all such changes in new profiles, and not just for debianutils removal. I don't recall there was this kind of article/documentation before, but might be wrong. Vlastimil signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Changes to some profiles
Duncan wrote: A GWN or similar announcement before it moves beyond the dev profiles would be nice, but if the affected devs (incl. bugwranglers) are willing to deal with the complaints and they seem to be, the leaner system and image is IMO a good thing, and announcement or not, people really /should/ be checking their depcleans. =8^) How about just some elog If you use make install, emerge --noreplace debianutils in the kernel's postinst or something. Though I wonder why kernel depends on stuff like $distroutils :) VB signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: removal of digest files from the tree
Chris Gianelloni wrote: I think throwing up an announcement today/tomorrow for Thursday/Friday should be sufficient for this sort of a change, as it won't affect any user who has a version of portage released in the past ~1.5 years. So, since it seems nobody objected it, time for the announcement? And the removal (server-side by robbat2) would be best done right before the snapshot? VB signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: removal of digest files from the tree
Chris Gianelloni wrote: On Sun, 2008-01-27 at 17:11 -0800, Zac Medico wrote: If there are no objections then I don't so any reason not to go ahead and add the manifest1_obsolete sometime in the near future. Thoughts? Let's do it. I look forward to a lot less inodes on my disks. Let's schedule a date for it then and we can have a big announcement to let everyone know. Dammit. I wanted this before January 31st, so it would make it into the 2008.0 snapshot. Do we think we can get this done by January 31st? Would be great. I think so. One reason that I think that we don't need to wait very long is rather simple. People running very old versions of portage that will be affected by this are also not likely to read our news or see our front page on a regular basis. They're likely to get broken, no matter what we do. Hell, even posting it to the GMN/forums/lists/planet/front page, we'll still end up getting complaints from these people when they come back $months from now and the news is no longer sticky in the forums, has rotated off the front page, isn't even a distant memory on the lists, and is in a several month old newsletter. Sounds logical. I think throwing up an announcement today/tomorrow for Thursday/Friday should be sufficient for this sort of a change, as it won't affect any user who has a version of portage released in the past ~1.5 years. ++ Caster -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: debianutils: system worthy ?
Duncan wrote: At minimum, I'd say make the usual BIG WARNING NOISES in the usual places, and probably still expect complaints. It may still be worth doing to cut down on system size... or not, depending on where the system size vs. inevitable complaints comes down. (FWIW, it's precisely this sort of early warning that's a big reason I read this group. One would think such early warnings would be even /more/ important to those running production systems on Gentoo, but...) I'd relax, removing from system doesn't make the package automagically uninstall for everybody who has it. And running emerge --depclean without --pretend, especially on production systems, sounds stupid anyway :) Caster signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Available hardware
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Hill wrote: | I think Jakub should get the Octane2. Then he can help with all those mips bugs. :) I thought removing keywords was easy even without the actual hardware :P Caster -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHj6sotbrAj05h3oQRAuGSAJ0Rd1vHDbzl5fsF8FbbMvOBe9f7iwCgpSe7 s8JhXSPQBLnUik82XFmbEGk= =VMO0 -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] USE flag documentation
Santiago M. Mola wrote: But stuff like aac needs encode and cdio conflicts with cdparanoia should be something separate from USE flag documentation. Well, at least until it's handled at ebuild level, local USE flag documentation can be used to explain the implications to the user beforehand (ewarns work too, but only after user tries to actually install the package). VB -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: USE flag documentation
Ryan Hill wrote: What do people think of this? a) Keep use.desc as it is: a list of common flags and a short general description of their meaning. Good. b) Keep use.local.desc as it is: a list of per-package flags that are specific to one to a few ebuilds (i think 5 is the number though i think 10 is more appropriate, but that's not relevant to this discussion). Again, each has a short description. c) Allow flags from use.desc to also exist in use.local.desc. In the case that a flag for a package exists in both, the use.local.desc description overrides the use.desc one. This allows a more specific per-package description of global flags. Good. d) Allow long descriptions in a package's metadata.xml, as some have begun to do already, for cases where more info is needed. For example I'd like to explain exactly what the bindist flag on freetype does and what legal implications disabling it can have. Right. Also why not also add short descriptions there, and deprecate use.local.desc when tools are converted? Placing package-local info to global files (when not needed to distinguish profiles as with package.use.mask etc) is icky. Note that the metadata.xml should be able to record per-version differences somehow. On the other hand, if there are any far-reaching changes we need made to the USE flag system - any features we wish we had or misfeatures we wish we didn't - now would be a good time to address them. I wish for use deps :P Well, addressing conflicts and implications between flags at ebuild/PM level would be also nice, but really shouldn't affect the way documentation is handled, IMHO. VB -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] New eclasses for KDE 4
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wulf C. Krueger wrote:
| We would welcome any comments, especially if accompanied by patches ;)
| and, of course, your kind approval to commit it. :-)
Hi,
Checked only briefly, it's late :) but I miss a comment in the header
that you need EAPI=1 in ebuild to use this eclass (slot deps...),
perhaps a check that it's really set?
And some small things I noticed:
DEPEND=${DEPEND} - first time you define DEPEND it's empty, no? Not
carried from eclass to eclass (as it used to be when the portage
behavior was broken IIRC) but separate in each eclass.
kde4-meta.eclass says # @ECLASS: kde4-functions.eclass
The (non-existing atm :) Copyright could use 2008 already :)
VB
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkeIB5wACgkQtbrAj05h3oTtbQCeM+V7yKKG5uOLablx357W8QId
2KAAn1bTJvdZ8wM+38QgWBnHwGO0cbB0
=rVAg
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for January
Ciaran McCreesh wrote: a) Drop all keywords but those of mips. Leaves mips and, more importantly, its users with a vulnerable and unmaintained set of packages. ...and break the tree spectacularly, causing huge amounts of pain for your fellow developers when they encounter horrible repoman output when they try to do anything. Can somebody clarify to me why would it cause this? Maybe I just miss something. VB -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] app-text/jasperreports removed from the tree
Does not build, was already p.masked for a long time: # Petteri Räty [EMAIL PROTECTED] (24 May 2007) # Doesn't compile atm. See https://bugs.gentoo.org/show_bug.cgi?id=164074 # for more details. =app-text/jasperreports-1.0.1 Moved to java junkyard. Could be added back to tree when bumped and fixed, work in progres in java-overlay, bug #164129. Vlastimil Babka -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Improving use.desc
Markus Ullmann wrote: -junit - Adds junit awareness -- useful for developers. +junit - Adds junit testframework awareness -- useful for developers junit - Adds junit test framework awareness -- useful for developers Actually, this flag should probably go away with gen-1 java ebuilds (gen-2 uses standard FEATURES=test for junit tests). Quick grep shows that it's already not used anywhere. VB -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI placement
Ciaran McCreesh wrote: On Wed, 12 Dec 2007 23:14:24 +0100 Carsten Lohrke [EMAIL PROTECTED] wrote: I disagree here. It would be annoying and possibly even hindering in future not being able to use higher EAPI features in eclasses. Point is the eclass has to check, if the author of an ebuild sets another EAPI and throw an error, in this case. There is no way for an eclass to throw an error. Nor, with the current way Portage implements EAPI, is there a way to add such a way. How bout declaring all supported (possibly with later conditional checks on EAPI variable etc) EAPIs in eclass via some variable, and repoman checking that EAPI set in the ebuild is compatible with all inherited eclasses? And if you need newer EAPI in the ebuild, get eclasses updated first (even if its just updating the compatibility declaration). Also, repoman could check that EAPI is not being set in the eclass. VB -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] The return of the old fart: Mark Loeser (halcy0n)
William L. Thomson Jr. wrote: On Fri, 2007-12-14 at 18:00 +0200, Petteri Räty wrote: He doesn't have a family yet but perhaps that's why he's into photographing. What's that implying he is some photo perv or something. Taking pictures of others families? Taking photo's makes up for a lack of having a Actually, he's taking pictures of cats: http://pbfcomics.com/archive_b/PBF215-Kitty_Photographer.jpg Anyway, welcome back and on and on! Vlastimil -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] USE flag how are they supposed to work?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steen Eugen Poulsen wrote: Alistair Bush skrev: * It is used by many different packages. yes, this is the rubber rule. It pretty much allows any use flag to be promoted to global when it has XX packages with it, the confusion comes because the number of package using a flag is no indication whatever you should set the flag globally or pr. package. Right, the only indication is if you want the functionality of the flag globally or per package :) Seem to me that the word global is used in the portage tree to mean one thing and then when we edit make.conf and /etc/portage we get another global/local meaning. That's right. Global/local use flag descriptions have no relation to global/local setting via make.conf/package.use. As a non-dev you might just ignore the first classification. I'm trying to write a Replicator for /etc/portage and that leads me to work with USE flags, trying to design the replication of them among similar systems, but I can't find the golden set of rules for how best to apply USE flags. There seem to be a global/local USE flag system, but many so called global flags has duplicated description marking them as local flags, or they enable unneeded optional support. Unneeded by whom? The package in order for it to work. You don't need Java, Python, Perl, Lua, whatever scripting support in most packages. For most of the ones I've seen, I have to go write a Java/Python/Perl/Lua program, before I actually need it. Well then don't enable those flags globally (that they are global doesn't mean you have to), enable them only for packages which have depending packages requiring them. Which you currently find out only by errors (graceful die messages, except bugs like the one you mentioned :) until there are finally use deps. The words is given different meaning depending on whatever I'm looking at the portage tree or working on configuring emerge. The portage trees global flag, is no indication whatever I should put the flag in USE= in make.conf, in many cases a portage tree global flag is more an indication that I should use it locally pr. package. Right, as mentioned above, there is no relation, although the global/local notion may suggest it. One might even ask why we have separate use.desc and use.local.desc then. Good question :) IMHO it's mostly administrative thing so people don't add many new global flags without consultation, but still can quickly add local flags just for their package. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG42AktbrAj05h3oQRAkfjAJ4zdWFWzLAswbDTq/hvszouoI1gYgCfV/j4 w0aFRUzi5RbOJMAs9M7O3no= =7Y8j -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Warner wrote: perhaps it'd be useful to introduce an anal_die. developers run anal tests, users get sane tests. -mike Anal ftw -Alec Also known as FEATURES=stricter. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGxdAXtbrAj05h3oQRAsUxAJ48+iW/EEhe87Q37xEP/gWwUPmrPACfbS1e rVtezxohQ6Bh+NOTEbWH02c= =uhBq -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
Jeroen Roovers wrote: On Fri, 03 Aug 2007 15:06:07 -0700 Chris Gianelloni [EMAIL PROTECTED] wrote: list of trivial changes There's a couple more that I wouldn't mind seeing as things developers can do without the maintainer, but I can see how these might be a bit more controversial, so I'm asking for input. Another good candidate is correcting errors in anything dodoc is tasked to install. When a TODO or other metafile goes missing in the course of development, I often find ebuilds that still mention them. When I haven't done my arch commit yet, I often correct the error after I check whether the file has simply been moved, by either correcting the path or removing the filename from the dodoc call. dodoc calls should have || die and USE=doc should be tested before commiting a bump, IMHO -- Vlastimil Babka (Caster) Gentoo/Java -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New PDEPEND behaviour.
Carsten Lohrke wrote: Well, I should point out where I come from. There is no need to install a pure runtime dependency before the ebuild pulling it in. If pure runtime dependencies would be handled this way, there would be no need for PDEPEND at all. I consider the current way Portage handles pure runtime dependencies (causing the need for the artificial PDEPEND in the first place) as conceptually broken. There are uses for it: A: RDEPEND=B B: RDEPEND=A Here you really don't need PDEPEND because in current portage, pure runtime dependency indeed doesn't have to be satisfied before the ebuild pulling it. But consider this: A: PDEPEND=B B: DEPEND=A Here you can't use RDEPEND instead of PDEPEND, because DEPEND=A says the package must be merged in a working state, thus *with all its RDEPENDs* and thus it would cause circular deps. PDEPEND is a way to relax this for such cases. If this is what you call RDEPEND conceptually broken, then sorry for useles try to explain it :) Maybe package manager could be smart enough and relax the RDEPEND in such cases itself, maybe it's better to say that via PDEPEND explicitly... -- Vlastimil Babka (Caster) Gentoo/Java -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 stablisation plans
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roy Marples wrote: On Sat, 2007-07-21 at 17:22 -0400, Mike Frysinger wrote: indeed, that'd be sleeky and sexy ... go file a bug ;) Let bug #186156 [1] be henceforth known as the sleeky and sexy bug! [1] http://bugs.gentoo.org/show_bug.cgi?id=186156 Thanks As you wish! [1] :) [1] http://bugs.gentoo.org/show_activity.cgi?id=186156 - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGooZEtbrAj05h3oQRApS1AKCU0vyw+Oka3yPc4bByDHxPyQEDFwCgpzIL F8ot8iOS1irR5UlcvDgpxFY= =Ydgn -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] x86 toolchain changes heads up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Gordon wrote: On Tue, 2007-07-17 at 19:47 -0400, Mike Frysinger wrote: historically, gcc on x86 has always defaulted to i386. some people noticed recently that glibc-2.6 fails to build in this situation as they were only setting -mtune via CFLAGS, not -march. i'll be tweaking gcc so that it will default -march based on your CHOST. so all the i686-* people will now have a default -march=i686 implied in their gcc systems, i586-* people will have -march=i586, etc... keep in mind this is merely the default. -mike Does this mean that any user-set -march flag is overridden for these cases? Just curious. I think he meant CHOST sets just *default* so any user-set -march overrides that. But I wonder what happens to user-set -mtune then? Since AFAIK -march implies -mtune, will also the default -march override user-set -mtune? - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGndsrtbrAj05h3oQRAp5hAJ4in2JnV637D7GyDMvG6hc8A8/n4QCeK9Eo IFUTZxAFqfSVx3Za64GQM0c= =6wSA -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC : New ebuild function pkg_create for creating corespondent sorce tarball
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jan Kundrát wrote: Alin Năstac wrote: The upstream doesn't offer a source tarball, so I need to construct it myself from their svn repository. If your aim is to create an ebuild for a specific version, you might as well checkout stuff yourself and let Gentoo mirror the generated tarball (your mail doesn't talk about RESTRICT=fetch). If you let Gentoo mirror the tarball, users are likely to be happier because they'll get the file faster and in a more reliable way. I think he wants to do exactly that, but having the code needed for this right in the ebuild, so it can benefit from varibles like PV and versionator eclass for converting PV to e.g. CVS tags... I think it's quite elegant for this, and that you don't need another script maintained somewhere else. If there was also switch in the respective new 'ebuild foo.ebuild src_create' command to automatically scp files specified by mirror://gentoo in SRC_URI to the right place... mmm :) The only downside is that users will download something that they won't find often useful (but think local overlay bumps and bugzilla reports on version bump that just renaming the ebuild works?). OTOH, while this might be useful for more than few packages (I can also think of some), it's not too many to clutter the tree significantly. Or am I missing something? Cheers, -jkt - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGnJkEtbrAj05h3oQRArf4AJ4n/nvrxsDV1hFixnf9HcGNlscUcgCeJaG8 1Rkm4mQ0HKeJX39P+vwwPz8= =jTzj -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Gaffney wrote: Donnie Berkholz wrote: Matthias Langer wrote: no offense, but this is one of the worst proposals i've ever read on this list; why? because, one of gentoo's major problems is that it is becoming more and more a toy exclusively for its own developers. Gentoo's always been exclusively for the developers. Nobody's paying us to do this. It just so happens that the things we want to do also benefit other people, and so they use them. That was my thought as well. We (the developers) owe nothing to the community at large. We are volunteers, and if we want to treat Gentoo as our own personal toy (which we currently aren't), then so be it. Are you people serious? Let's ban nondevs from bugzilla then? Close #gentoo, disband PR, etc? Not sure if we can keep any sponsors then... - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGm2AFtbrAj05h3oQRAnqlAJ4yiS73x/jAdaWJMv+Fh6fG33vaSACfdWJX GUCkyeDMTw0paODJ2bD86GU= =f7s+ -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] So...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Doug Goldstein wrote: So it's 97 degrees outside.. it's pretty hot... Since everyone loves to debate non-technical things on this list.. Let's debate Fahrenheit vs Celcius... Discuss! I don't care, as long as the temperature is somewhere in the middle of linear scale between freezing water and average healthy human body temperature. And not higher than the latter, as nowadays! - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGm8antbrAj05h3oQRAsB2AJ4tmemfppz36p5wUnFS7uTvXwObdQCglSsG C93JXdRGdMDLwteYd9p3ZeI= =ElDz -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: For Jakub (and the other procmail-impaired)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Long wrote: And no, I don't like being lumped in with Mr McCreesh. Why would anyone do that? His trolling is sophisticated, but you're just an annoying spammer. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGnC4+tbrAj05h3oQRAogfAJsHwaCR8rOhveFWrmODgKheBHPTyQCgjx1G uhvlN37SxRrUWS9MaRoIMis= =s82z -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007/08
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Raúl Porcel wrote: good, now my nick is armin79 :D Lies! No way your karma would go up! Cheater! armin79-- armin78-- armin77-- You're good now. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGi/NHtbrAj05h3oQRAkiNAJ91U4ZZXkId0CcS5ZNKyiHHnsjaCACePi9o tID1LiLSbO9FL/5dFQ0YWzo= =AoMW -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: cyclic dependency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Hill wrote: Marijn Schouten (hkBst) wrote: Vieri Di Paola wrote: The two software packages depend at run-time. then they can simply RDEPEND on eachother. The package manager should do the right thing. It doesn't. See freetype which requires =fontconfig-2.3 at runtime which in turn requires freetype at runtime. Bug #179736. I think the problem is that fontconfig has freetype not just in RDEPEND but also DEPEND (see how in the emerge error output one dep is reported as medium and the other as hard). Which is interpreted as 'needed at build time in working state, thus with all its RDEPENDs (which includes satisfied', creating the circular deps. So, just RDEPEND on each other should be fine (at least in recent portage, I think older ones treated RDEPEND and DEPEND the same). But if one package has DEPEND, the other one needs PDEPEND. P.S. I think the solution with PDEPEND is wrong for bug 179736. If I understand it correctly, then freetype-2.2 doesn't NEED =fontconfig-2.4, but, if installed, will crash older versions. Then there should be a blocker on fontconfig-2.4 in freetype. I think portage handles that correctly since some point. And if not, it should :) - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGiaA2tbrAj05h3oQRAuyAAJ4nu6QcexxRQkQEpg98pXGn09Ry+gCfVDtk H3ENhWchaop/RzVBH8kNQoI= =Ad8b -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] gentoo-dev-announce list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Warner wrote: I vote no, because someone has to. -Alec PS: Thanks to be keeping the packages in the tree up to date. So that's only one negative vote :) and others IIRC positive. Time to fill some infra bug until it's forgotten again? Or do we need a GLEP and/or council approval? (just kidding) ((hopefully)) - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGfmeVtbrAj05h3oQRAuQLAKCT7ePtnoD3mUW+y1H/eDIJc4x9mQCeM9vO 19m8qWAuAiF/WN9Q5HMyzNk= =Y0o3 -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: On Wednesday 20 June 2007, Mike Frysinger wrote: On Wednesday 20 June 2007, Josh Saddler wrote: Do potential licensing/copyright issues like these factor into your proposal in any way? no, that's an exercise for the user and no one else ... there's no way i'd have the tools prevent this. about the only thing i'd add is a reminder message if binpkg is in IUSE and not in USE. i like this idea so it's been added: # quickpkg pycrypto * dev-python/pycrypto-2.0.1-r5: package was emerged with USE=-bindist! * dev-python/pycrypto-2.0.1-r5: it may not be legal to redistribute this. * Building package for dev-python/pycrypto-2.0.1-r5 ...[ ok ] * Packages now in '/usr/portage/packages': * dev-python/pycrypto-2.0.1-r5: 188K -mike You should do also this (mockup): * dev-java/ibm-jdk-bin-1.5.0.5: package has RESTRICT=fetch/(no)mirror! * dev-java/ibm-jdk-bin-1.5.0.5: it may not be legal to redistribute this. * Building package for dev-java/ibm-jdk-bin-1.5.0.5 ... [ ok ] * Packages now in '/usr/portage-packages': * dev-java/ibm-jdk-bin-1.5.0.5: 50.9M - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGehf7tbrAj05h3oQRAi3BAJ9CIIQ4We8aY2LIRlCcXvhEO/04yACfRtrh Xn8cfOd3YLaHNp8H/efM84s= =FJ2n -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ned Ludd wrote: On Wed, 2007-06-20 at 23:04 -0400, Mike Frysinger wrote: On Wednesday 20 June 2007, Mike Frysinger wrote: On Wednesday 20 June 2007, Josh Saddler wrote: Do potential licensing/copyright issues like these factor into your proposal in any way? no, that's an exercise for the user and no one else ... there's no way i'd have the tools prevent this. about the only thing i'd add is a reminder message if binpkg is in IUSE and not in USE. i like this idea so it's been added: # quickpkg pycrypto * dev-python/pycrypto-2.0.1-r5: package was emerged with USE=-bindist! * dev-python/pycrypto-2.0.1-r5: it may not be legal to redistribute this. * Building package for dev-python/pycrypto-2.0.1-r5 ...[ ok ] * Packages now in '/usr/portage/packages': * dev-python/pycrypto-2.0.1-r5: 188K -mike Please do the same for qpkg.c tia. And for emerge -b/-B/FEATURES=buildpkg. Too bad people will miss those messages there anyway :) - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGehl8tbrAj05h3oQRAhWeAJ97LB2wCjQS9ClzfcVBZWWL4BU/mACfeUie 162BuT7lbvHmvxGaW7CCJbY= =+o1J -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: QA issue: No stable skype in Tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Long wrote: As for potentially useful, so was Internet Explorer, last time I looked at what you could do with its Object Model. I still ain't voting to bring it to Gentoo.. ;) Looks like you lost your vote :) # ChangeLog for app-emulation/ies4linux *ies4linux-2.0.5 (21 Jun 2007) 21 Jun 2007; Jurek Bartuszek [EMAIL PROTECTED] +ies4linux-2.0.5.ebuild: Initial version (closing bug #143798), credit goes Mathieu Bonnet [EMAIL PROTECTED] for providing the ebuilds. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGev2/tbrAj05h3oQRAvBeAJ95RW2XbmVLHYTQHSvoEl91THr4yACdE7aX 3H6Xsw407WrZc//h9Pq7n2g= =uXox -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New developer: Ali Polatel (hawking)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Raschbacher - LordVan - Gentoo wrote: i assume Petteri means to apply sed s/stupid/student/ ? ;) I assume that too. Wonder what would Freud say about this mistake :) I think Petteri is also a student himself :) Anyway, welcome Ali :) - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGeaJOtbrAj05h3oQRAi3lAJwKducWie0CgqMwZeXN4aI3apvBUwCffgF7 6PX1hIR+D1jEg4+dwU9p6+4= =P7os -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI-1 (or 1, perhaps) Proposal: AND Dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marijn Schouten (hkBst) wrote: John R. Graham wrote: What I'd really like to be able to code is a range with an AND operator, something like this ( =some-cat/foo-4.0 some-cat/foo-4.3 ) AND is already the implicit combinator. Thus simply listing both these atoms gives what you want: =some-cat/foo-4.0 some-cat/foo-4.3 Not always, AFAIK Imagine there's some 3.x versions in slot 3, 4.x in slot 4, 5.x in slot 5. With this atoms you could end up with both 3.x and 5.x installed, and no 4.x :) It doesn't try to satisfy both atoms with one version. Still a special syntax for ranges seems like a good idea. If only portage would not upgrade past such specifications (and downgrade the next time). IIRC upgrade/downgrade loops were already solved in some recent version? Now it spits some error about conflicting deps that cause that. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGcmHKtbrAj05h3oQRAjxQAJ9jYtK7aAAWBvYttCTLW1Kt7a/OzACeL2Oe aLZwTVOKohkRfcyyfRKpqMY= =gYLD -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] QA issue: No stable skype in Tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jan Kundrát wrote: Abhay Kedia wrote: I am involved in this thread since its very beginning but looks like I am not being able to understand the problems. Would you please be kind enough to enumerate the issues discussed in this thread that warrant complete removal of Skype (rather than masking it) from the tree? We have a policy that ebuilds should be in the tree for at least 30 days before we mark them stable. Skype uses funny license that forbids us to mirror the installer file. Skype wants to remove that older file from their mirrors in less than 30 days after they release a new version. Current Gentoo stable would be unistallable. New version can't be marked as stable because it won't have been properly tested yet. Users will see that stuff that used to work for them is broken now. That's a regression that could have been avoided if Skype wasn't marked stable. It could be interesting to evaluate a new rule fetch/mirror restricted package can't be marked stable :). I believe common sense and per-package experience is better than such general rules :) - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGco4HtbrAj05h3oQRAi+rAJ92CyJ80p8JXWpIM1mJCnMrCFSXQQCgn6Ej JSWpRQFMvCCL6LM3MR9FEjQ= =sc5A -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI-1 (or 1, perhaps) Proposal: AND Dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John R. Graham wrote: I occasionally run across a package version dependency issue that cannot be elegantly solved by the current dependency syntax. Every time I've come across this, it's boiled down to a range. For example, package some-cat/foo has the following versions in the tree some-cat/foo-4.0.0-r2 some-cat/foo-4.1 some-cat/foo-4.1.1 some-cat/foo-4.1.2-r2 some-cat/foo-4.2.1-r5 some-cat/foo-4.3 some-cat/foo-4.4 Now, package other-cat/bar has a runtime dependency on some-cat/foo but it only works with the 4.1 and 4.2 slot. The other-cat/bar ebuild was originally composed before the some-cat/foo-4.3 package came out, so the ebuild developer coded the runtime dependency as =some-cat/foo-4.1 But, when some-cat/foo-4.3 came along, it got messy. The only possible solution today that I know of is ( || =some-cat/foo-4.1* =some-cat/foo-4.2* ) and this potentially grows over time as new versions stabilize. If 4.1 and 4.2 are really SLOTs as you say, then this || syntax makes good sense. Of course would be better with real slot deps :) So your example is not so ideal. But nevermind. What I'd really like to be able to code is a range with an AND operator, something like this ( =some-cat/foo-4.0 some-cat/foo-4.3 ) Syntax shouldn't repeat package name twice. It wouldn't make much sense to use it with =some-cat/foo-4.0 some-cat/bar-4.3 would it? So, my question is, does this make sense? Is something like this planned for some EAPI0? Would it be appropriate for me (a non-dev) to file a bug and link it to SpanKy's EAPI-1 tracker bug? There's been bug 4315 for ages, so maybe just reassign it to PMS? - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGchsotbrAj05h3oQRAjg8AJ46/ofZuK6EI+LnQcTivJDzOjgj4gCfWNRe a56SGjmxI16imQxdkfRRoQI= =bu3E -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: OT: gentoo-kindergarten
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thilo Bangert wrote: I want a gentoo-kindergarten list, where useless discussions like this (sub)thread can be directed to. kids, grow up! right s/gentoo-// - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGb8wftbrAj05h3oQRAgFoAJ4iONPCQQD3HWGR0grxNCzDzgOjKwCfZEV4 dpBt6VnzHYivDAVIbrH6ehQ= =a6jD -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] QA issue: No stable skype in Tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gustavo Felisberto wrote: Any alternatives? Drop it from stable completely, possibly package.mask or move to overlay. Why should this closed-source rootkit be in stable? - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGcB4ztbrAj05h3oQRAoVMAKCg9kpnE0wPRI5SCNOh00n2eVXC5ACdE+8B v1PFWyt5iFbKcdlP8Eq+V1s= =UGYh -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] QA issue: No stable skype in Tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 George Shapovalov wrote: Wednesday, 13. June 2007, Daniel Gryniewicz Ви написали: The first option will trigger portage errors and prompt users to open bugs until we have a stable 1.4, the second gives us a chance to explain the issue. Any alternatives? 3. Mask 1.4 on the 19th with a descriptive message. That should have the effect of 1 and 2, without breaking anything necessarily? I'd say mask 1. as soon as anything 1.4 hits the tree (even p-masekd). This way we warn users but also give them a chance to save a local copy of their favorite version. *We* cannot mirror sources, but as I understand, nothing prohibits end users from saving their stuff locally. Is this right? This will show warnings about all versions masked or removed for stable users that already installed 1.4 version before, and cause confusion. Maybe you could (either when final 1.4 hits ~arch or on 19th) change the RESTRICT=mirror to RESTRICT=fetch in 1.4 and explain the situation in pkg_nofetch() via einfo, telling users they either find the distfile themselves (might have it on another computer, or get from a friend or just maybe have luck with google) or use the ~arch 1.4. This won't affect users that already have 1.4 installed, or just have the distfile. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGcDdAtbrAj05h3oQRAilcAJ0flzyZXqhYVpNyD8287fbyEBdzrACgikyT lP540mMlV8t/zcFq6Ixkh6o= =qKJI -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] QA issue: No stable skype in Tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Abhay Kedia wrote: On Wednesday 13 Jun 2007 10:11:24 pm Vlastimil Babka wrote: Drop it from stable completely, possibly package.mask or move to overlay. Why should this closed-source rootkit be in stable? If closed source is the criteria of getting dropped from stable status or tree, than are we dropping netscape-flash, vmware and NVIDIA etc. as well? Nah it's not the only criteria, the focus is on the rootkit :) part [1] Also, ion3 was IIRC removed recently also for upstream trying to force new versions against our stable policy. And that was opensource. But maybe Skype is not so pressing to upgrade, just doesn't provide distfiles anymore. Then maybe we don't have to obey, but still it's really questionable if it should be marked stable at all. And yeah I'm a Java dev but at least Java is now open (I admit that the stable VM's in tree are not, yet) and I don't see that coming for Skype. Also Java (and your examples of closed source stuff) are not infamous for the bad stuff mentioned above. [1] http://en.wikipedia.org/wiki/Skype#Criticisms [2] [2] Oh noes I cited wikipedia, unreliable source of arbitrary information. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGcFKStbrAj05h3oQRArJMAJ9dAajoI7l1tde7/FvKzrubw0TCmgCfYrNj dCiD3UU7fiGY0YRFox/KXfw= =96ut -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] QA issue: No stable skype in Tree
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kent Fredric wrote:
On 6/14/07, Vlastimil Babka [EMAIL PROTECTED] wrote:
Also, ion3 was IIRC removed recently also for upstream trying to force
new versions against our stable policy. And that was opensource.
[U] x11-wm/ion3
Available versions: (~)20060326 (~)20061223 (~)20070318-r2
(~)20070506-r1
{doc ion3-voidupstreamsupport-truetype unicode xinerama}
*waves finger at humourously* didn't even eix? .. or do i need to
sync again on this slow connection to witness insanity of pain :(
Yes you need to sync :)
http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-wm/ion3/ChangeLog?hideattic=0rev=1.56view=log
- --
Vlastimil Babka (Caster)
Gentoo/Java
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGcFcWtbrAj05h3oQRAhipAJ93T+PRRsN5Zdu6r+h22Ywgn1OGsACghlX9
1eB5gqvrc1n5Il3KLJH4bjQ=
=NAPB
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Are you guys for real?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jayson Vaughn wrote: Ok, Gentoo is over. Hardly :) As an outsider who has been following gentoo-dev and other gentoo lists for a while, this is just completely nuts. Seen worse :) Is there any order or clear idea anymore for this distro? No other distro seems to be as lost or confused as Gentoo is. Are you following also mail lists of other distros? And WTF is this list going to discuss development? Do you guys develop ANYTHING? Or Do you just bitch all day? Yep there's still development going on, devs commit ebuilds and stuff. Also, as said many times, number of devs participating in flamewars here is pretty low compared to number of all devs... Most people really just silently develop. Good bye Gentoo, when you grow up and know what your goals are etc I'll be back. Love the distro, but Jesus the politics and the bitching gets out. Just unsubscribe the list and you won't see it :) - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGcGTZtbrAj05h3oQRAj0SAJ0RLIx//xj8AsyLBs+9ZT3KSchZAwCfafh9 OClYgnPgfpYs+4WvlfGuQOk= =YAJ8 -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Do not modify ebuilds which are already in the tree... even if masked
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 cilly wrote: I also recommend to manage hard-masked packages the same way, it prevents confusion in bug-reports. I don't agree for hard-masked packages. Sometimes they are hard-masked because of being under development, and are changed several times until unmasked (think about new KDE versions etc). Revbumping with each change and then finally unmasking something like -r15 is nuissance and looks weird. Users shouldn't be using p.masked packages and if they do, they should really know what they are doing, especially when filling bugs for such packages as there are no guarantees while in p.mask. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGboh4tbrAj05h3oQRAvv1AJ45RRl0kr1246ug5H1ZdSTZ5i5j5QCfaq25 xLWsB9Pqbb8kPXVSe4Co4NM= =SSi6 -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [gentoo-java] Last rites: dev-java/jdbc-mssqlserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vlastimil Babka wrote: +# Vlastimil Babka [EMAIL PROTECTED] (10 Jun 2007) +# Outdated version, proprietary binary package, library that nothing in tree +# uses. Still generation-1. Assuming nobody needs it as there was never a +# version bump request. Will be removed after 30 days into java junkyard +# unless users show the need for it. +dev-java/jdbc-mssqlserver Recalled, will stay. Users want it and betelgeuse did already migrate it to gen-2 so the mail was wrong in that. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGbVKptbrAj05h3oQRAgdhAKCVwI+EGE1d1xbp7SaRisY4c77u/ACeItc6 isjBZXxufsGGgaONeP5i2hk= =SgEM -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites: dev-java/jdbc-informix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +# Vlastimil Babka [EMAIL PROTECTED] (10 Jun 2007) +# Outdated version, proprietary binary package, library that nothing in tree +# uses. Still generation-1. Assuming nobody needs it as there was never a +# version bump request. Will be removed after 30 days into java junkyard +# unless users show the need for it. +dev-java/jdbc-informix - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGayi8tbrAj05h3oQRAqU8AKCN9j4laLiVP7dF6JVrwyQXsm9dzACgifPG HO8aA7LHRbmxg2fYvIGaoxA= =mFFC -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] [gentoo-java] Last rites: dev-java/jdbc-mssqlserver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +# Vlastimil Babka [EMAIL PROTECTED] (10 Jun 2007) +# Outdated version, proprietary binary package, library that nothing in tree +# uses. Still generation-1. Assuming nobody needs it as there was never a +# version bump request. Will be removed after 30 days into java junkyard +# unless users show the need for it. +dev-java/jdbc-mssqlserver - -- Vlastimil Babka (Caster) Gentoo/Java - -- [EMAIL PROTECTED] mailing list -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGaysZtbrAj05h3oQRAueXAJ92/l0cj3Wyd2JjTlVnq+ubBj+8ywCaAoW/ JFRFOdEAzD0pdx28WWkNxiQ= =pRN0 -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New global use flag, xulrunner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Raúl Porcel wrote: Vlastimil Babka wrote: Raúl Porcel wrote: Agreed from mozilla. firefox and seamonkey already have the global use-flag Is there any guideline from mozilla team about what to do when there are more than one of these flags (firefox/seamonkey/xulrunner) supported by package AND enabled by user? Some of those local flag descriptions suggest that USE=firefox xulrunner results in using xulrunner (so it has higher priority). So is that recommended, and how about seamonkey? Sorry, didn't saw this msg. I don't know of any guideline. Anyway all apps should start to use Well maybe I could've just read the USE flags descriptions closely and it would be clear to me that the preference order should probably be: xulrunner firefox seamonkey xulrunner, since that's what they really want instead of using firefox or seamonkey. When ff-3.0 is released no app will be able to build against ff, since ff will build against xulrunner. So, what i said, apps should use xulrunner as primary option, now that xulrunner is up-to-date and working fine. We should probably fix profiles/default-linux/x86/2007.0/desktop/make.defaults then (and possibly other profiles?), as it has only firefox in USE? - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGaVXwtbrAj05h3oQRAifRAKCmsFjAuyHUdBUgxCsAjjxd5ojfuACfcYF4 rx+vUQNY81RxzrfZCEvmxxQ= =sqC9 -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC]: gentoo-politics ML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kumba wrote: And maybe a dev who secretly dabbles in another OSlike Wind...err, Ubuntu! I thought this position has been already filled :) - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGZ7RLtbrAj05h3oQRAgicAKCnwCpAjx7F5YiDUsBWfwfBpNiGwACeM8ou ZBE6/M41qXeJ6ZUc68tvKGg= =KmFY -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New global use flag, xulrunner
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Raúl Porcel wrote: Agreed from mozilla. firefox and seamonkey already have the global use-flag Is there any guideline from mozilla team about what to do when there are more than one of these flags (firefox/seamonkey/xulrunner) supported by package AND enabled by user? Some of those local flag descriptions suggest that USE=firefox xulrunner results in using xulrunner (so it has higher priority). So is that recommended, and how about seamonkey? - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGZwt/tbrAj05h3oQRAsJkAJ99aXhbnYoqdtKuud77ZXcPS5MZMwCeNLuu N9/sEqDf7P3/f9v7CGxfy/0= =/OQC -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Deskzilla for Gentoo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 josé Alberto Suárez López wrote: El mar, 29-05-2007 a las 16:01 +0100, Steve Long escribió: Just to say thanks to the java devs for getting 1.4_beta in the tree so promptly, and to let you all know that it works fine now and is an Works fine means it now understands b.g.o timestamps :) But search by CC is still scheduled for next version... (so you have to use saved queries for that). excellent interface to bugs.g.o. I especially like how you can use saved queries from your acct, and the attachment handling (but then i'm just a usr ;) s/usr/user/ ! just one more letter to type and makes one not want to poke their eyes out... dev-util/deskzilla deskzilla is totally free for gentoo devs? No, but can be freely used with bugs.gentoo.org (by any user, the license key is installed by ebuild). Trialware otherwise. You can request such license for any FOSS project. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGXn/1tbrAj05h3oQRApMDAKCZoGxaTEEhPQusvIuGvI23ZcSydwCfahcU iPUW0knA2ZZ76hT5mkv98Cs= =8Sbs -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: new bugzilla resolution: NEEDPATCH
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson wrote: On Thu, May 31, 2007 at 02:32:22AM +0200, Marius Mauch wrote: I'm sure I'm not the only one who knows a number of (enhancement) bugs that are fixable, but the assignee doesn't have the motivation to come up with a solution, but would look at and eventually include a user-submitted patch for it. Currently those would either be left open forever or closed as WONTFIX which isn't compeltely accurate. Therefore I propose a new bugzilla resolution NEEDPATCH so we're not stuck with tons of open bugs that might never be closed (or get closed with a somewhat incorrect resolution). It might also give people who want to help a simpler target instead of browsing through all open bugs and trying to find one where a user can work on. I think a keyword might be more useful, as at least with my bugs, I'd like to keep them open myself - if the user doesn't provide a patch, it's still something that I'd get around to doing eventually. I specifically want my bugs to stay open, and be easily visible as to why I've kept them open. +1 Keyword is a good idea. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGX04htbrAj05h3oQRAp/0AJ9adU5tYreZ7FG2jTrMXMOeYebRDQCfd5bj LhneK0sZ4gQkrMSw0oUj0LM= =xVZ+ -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] STABLEREQ/KEYWORDREQ Keywords in bugzilla
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Ramsay wrote: Chris Gianelloni wrote: On Wed, 2007-04-18 at 07:39 -0600, Jim Ramsay wrote: Vlastimil Babka [EMAIL PROTECTED] wrote: Or maybe implement new bugzilla keywords, like STABLEREQ and KEYWORDREQ which would be added to the respective bugs. Then you (the maintainer) can easily create (and save) an advanced search that will filter them out, while still being able to check them in a different search. Might be also useful for arch teams to separate stabling and keywording bugs? I think that's a great idea. Who do we bug to get this in there? File a bug in the Bugzilla component. I hear and obey: http://bugs.gentoo.org/show_bug.cgi?id=175103 Bug was fixed yesterday, keywords added, so to let you know. I would of course love to go now and add these keywords to all my (java) current bugs but not wanna get wrath of arch teams for bugspam. So I'm asking if they would tolerate it (especially amd64, ia64, ppc, ppc64, x86 :) or not. Or arch teams could maybe temporarily turn off bugzilla notify on keyword change for some time (week?) so everyone interested can add these keywords without bugspam? Any better ideas? - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGWVw6tbrAj05h3oQRAkGRAKCKu+2COeN+iKkm6WVgbO3SCg6mIACgjFgj b+GTTH1Lpmz4PG3uiqiCn6I= =YSKc -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] STABLEREQ/KEYWORDREQ Keywords in bugzilla
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson wrote: On Sun, May 27, 2007 at 12:23:56PM +0200, Vlastimil Babka wrote: Bug was fixed yesterday, keywords added, so to let you know. I would of course love to go now and add these keywords to all my (java) current bugs but not wanna get wrath of arch teams for bugspam. So I'm asking if they would tolerate it (especially amd64, ia64, ppc, ppc64, x86 :) or not. Or arch teams could maybe temporarily turn off bugzilla notify on keyword change for some time (week?) so everyone interested can add these keywords without bugspam? Any better ideas? It will actually depend on how people have their Bugzilla email configured. I think a lot of people have bugzie set to not email when a keyword changes on a bug they are assigned/cc'd to. Arch team aliases (and some people who watch them) probably not: Email sent to: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Excluding: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGWWYqtbrAj05h3oQRAhMkAJ0RrZ+koXiLFEIIvq6gfONIP07qVACfUp3z ebSSqnoyevXEihGb13KqmhA= =ch2p -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Packages with same name was - Conversion of Emacs virtual packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Josh Sled wrote: On Thu, May 17, 2007 12:53 pm, Ciaran McCreesh wrote: 'Twas added to the tree at user request. Given that Java's basically a dead language and only being used for legacy applications now, it's I'm having a hard time trying to figure out how you justify calling Java a dead language. It's not C++ nor Ruby. Anyway, offtopic :) - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGTI0ztbrAj05h3oQRAiSHAJ9/3FzS1r+rnfxTXsqN0aOJh3fveQCfW2TV 4JREonUvieuIMHkFMcAFI5o= =JB4J -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: stabilizing expat 2.0.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rémi Cardona wrote: Chris Gianelloni wrote: It's simple. You mask expat-2.0.0 on all the current profiles, we mark it stable in the snapshot and don't have it masked in the 2007.1 profile. When we release (actually right before), we mark the package stable in the tree. We document the expat upgrade as part of the profile upgrade guide, and we're done. Users using a =2007.0 profile never see the upgrade. New users use the new expat. Users changing to the 2007.1 profile run revdep-rebuild. Now, how can we do this? Could we start changing the profiles right now? (I guess people on ~arch will need to unmask it to not downgrade). That can be avoided if you make an artifical revbump that won't change anything, just have stable keywords, and you mask that revision specifically. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGTKEqtbrAj05h3oQRAsKEAJ9Nwh6jww9Tut9VtXnHIPuLXHUnUQCcCoSQ T/34IkQDJqh6IOGX7rME1fw= =Bssx -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GLEP 42 news item for review: Radiant upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: My intention would be to show these right after 'emerge --sync' or 'emerge --pretend', not when the package is about to be merged. Then you want the non-existent pkg_pretend_post() feature, not GLEP 42. glep 42: Checks for new news messages should be displayed: * After an emerge sync * After an emerge --pretend * Before an emerge target (which may also include a red warning message) - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGPi/atbrAj05h3oQRAuueAKCjT25oLVyZ5BUpxoNUkcLeQXfDnQCcD+8L RILu6tBvDbEBNDa8c9YzztY= =PxQZ -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [news-item] Paludis 0.24
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Piotr Jaroszyński wrote: On Friday 04 of May 2007 23:46:39 Thomas Rösner wrote: You mean Display-If-Installed: sys-apps/paludis-0.24, right? No, I want it displayed only after installation of the new version. Isn't such use case just a replacement for elog? I thought news were supposed to be delivered before upgrading. Also You should update your configuration files after upgrading. sounds like something one would read before upgrade... - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGO6/3tbrAj05h3oQRArMcAKCTQIriSODoHFBCI+imBO0RJ/nqKACdEWH/ NOvynKL3uoRP9GXWXwLz0Yc= =Bxw0 -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [news-item] Paludis 0.24
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: On Sat, 05 May 2007 01:30:05 +0300 Petteri Räty [EMAIL PROTECTED] wrote: So let's say this was a message about package foobar. If it only affects users after they upgrade it would mean that new installs would get the news item too, wouldn't it?. Yep. This situation was discussed when designing GLEP 42. There isn't a better alternative because there's no reliable record of packages that used to be installed. Display-If-Installed: sys-apps/paludis-0.24 Pretty reliable for this case which affects only users upgrading from previous versions to =0.24. How likely is that someone has had such version previously, then uninstalled paludis completely leaving config files around, and now installs =0.24? So likely it's worth that future fresh installs of say 0.50 will display this news too? - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGO7oitbrAj05h3oQRAtshAKCCJeVQ2ksDuIvX8eLGjZsxAlDxFACeNea1 Iep1M7QGhWnSfHP4drZg3rw= =nabr -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] tests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Gryniewicz wrote: On Tue, 2007-05-01 at 15:08 +0200, Piotr Jaroszyński wrote: Hello, There was some discussion about forcing/not forcing tests in EAPI-1, but there was clearly no compromise. Imho, tests are very important and thus I want to discuss them a little more, but in more sensible fashion. Firstly each test can be(not all categories are mutually exclusive): - not existant - non-functional - not runnable from ebuild - useful but unreasonable resource-wise - useful and reasonable resource-wise - necessary - known to partially fail but with a way of skipping failing tests - known to partially fail but with no easy way of skipping failing tests Is that list comprehensive? Secondly we must answer the question how precisely we want to distinguish them, so users/dev can choose which categories of tests they want to run. What comes to mind is: - run all tests - run only necessary tests - run only reasonable tests - don't run tests at all Again, is that list comprehensive? Don't forget tests that have heavy requirements to run. Many gnome tests, for example, need a virtual X to run, which puts a new set of DEPENDS requirements on your system. Daniel And sometimes these extra deps can result in circular deps. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGN2mKtbrAj05h3oQRAsIPAJ40sOQV97jBCUFAIcKZFHJ1mRiu4QCggfz6 Toh/ZYYpU7lJfmVOqQclaWo= =ULIL -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites for dev-java/dbconnectionbroker-bin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +# Vlastimil Babka [EMAIL PROTECTED] (30 Apr 2007) +# Stale upstream (since 2002), -bin library that nothing in tree uses +# so it's not needed. Will be removed into java junkyard around 30 May. +dev-java/dbconnectionbroker-bin - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGNkJrtbrAj05h3oQRAgdcAJ9zfIc+QCYDuBDcF+8WYq868Z4cwQCfd7c4 3aZHjaXVscwsIRV3Nz9vyHk= =iAnA -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites for dev-java/dbconnectionbroker-bin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Vlastimil Babka [EMAIL PROTECTED] (30 Apr 2007) +# Fetch-restricted binary library that nothing in tree uses, upstream +# unsupported (EOL). Will be removed into java junkyard around 30 May. +dev-java/infobus-bin - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGNmF+tbrAj05h3oQRAn//AJ9fme1lYkxhM5NlR+ICWvHBw9dmMACgnQgu UQ0XLkoj3kJKGpCLIkAYQo4= =0OXK -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Last rites media-gfx/opcion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 William L. Thomson Jr. wrote: Last rites for media-gfx/opcion Last upstream release was 1.1.1, released April 24, 2004. The package has been masked, and will be moved to Java junkyard overlay after 30 days pass. Unless someone cares about this package, needs it, uses it, and/or is willing to updated it. Recalled and unmasked at user's request. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGNHrytbrAj05h3oQRAlazAJ9Q3BW5NyCwH8a1raeS5eNyzLclWgCdEEDl znlqWjgDr/4Sqsiv5jOT4M0= =Oalb -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites: dev-java/joscar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +# Vlastimil Babka [EMAIL PROTECTED] (28 Apr 2007) +# Still generation 1 and stale upstream, library that +# nothing in tree uses so it's not needed. Will be +# removed around 28 May. Generation 2 revision is in +# the java-overlay. +dev-java/joscar - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGM3d7tbrAj05h3oQRAiqjAJ0Sba40WJOjwdn1S22SIpwgkCrIeQCeOTAC OTwFmycBlYNwECyW6X98zko= =r4lG -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites: dev-java/jmbus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Vlastimil Babka [EMAIL PROTECTED] (28 Apr 2007) # Stale upstream, library that nothing in tree uses # so it's not needed. Will be removed around 28 May. # Generation 2 revision is in the java-overlay. dev-java/jmbus - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGM4+ktbrAj05h3oQRAhGXAJ9IXgQq1XoG9qsL0Wd8i/vIClUCWACdHTaW 0TsdamGqT1XlZYa9JB4VLuQ= =TXIJ -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites: dev-java/sun-{connector-bin,dsml-bin,ejb-spec}
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +# Vlastimil Babka [EMAIL PROTECTED] (28 Apr 2007) +# Unused generation-1 fetch restricted binary libraries. +# Will be moved to junkyard around 28 May. +dev-java/sun-connector-bin +dev-java/sun-dsml-bin +dev-java/sun-ejb-spec - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGM5RutbrAj05h3oQRAn9uAKCkYtsBya9zAh5vTP5qVTW+JnyS8wCdHO/z S6G2CryV0Oy+h2rFf52YJPA= =Ot1N -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
Thilo Bangert wrote: So I'd be in favour of getting rid of them, if we make sure that everybody always commits to the ChangeLog (Make it a repoman failure). Side benefit of removing the need to double-commit from the hashes changing. i have never understood why repoman doesn't automatically put the commit message into the ChangeLog (share your use case!) Yeah I would like at least a switch that would call echangelog first and then do its stuff, sunrise-commit which I use for overlays has -c for this. Hm well I can make myself a wrapper but if it was already there, it would be better :) taking this one more step ahead, the ChangeLog could perhaps be made a virtual file, which on demand is extracted from VCS metadata... now _that_ would save some bandwidth and space (no numbers, sorry). Interesting idea, if that's possible with CVS... but I don't see how it saves space and bandwith for rsync users. i am all for the removal of $Header:$, btw. the current double commits simply suck! I would leave it as long as we use CVS, for the reasons others already said (syncing changes to overlays which I myself used to do). But if we move to some other VCS, it would destroy the beauty of atomic commits... -- Vlastimil Babka (Caster) Gentoo/Java -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Deskzilla license for Gentoo Bugzilla for everyone
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ned Ludd wrote: You sent this to -dev vs -core.. Pretty sure they are going to need to revoke this license now. Nah, read closely: Feel free to share the license key with anyone interested or post it on the web. The license allows any number of users, and it is locked to Gentoo Linux Bugzilla URL. If in the future the URL changes, please So there it is. For now you can get the ebuild from java-experimental . java-experimental overlay is public anyway But it was already said that cross-posting -dev and -core is bad so let this be the last mail that goes to both, and any further only to -dev. - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGKTFItbrAj05h3oQRAjdKAJ9kkxOFJKC411v7CdnVzFuZh7n0eQCfW6t5 5s/o7bNPSkgVVprNzcR25xQ= =QHhb -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-core] [POLICY] Keywording/Stabilizing Bug Assignment Policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Schweizer wrote: It would be cool to implement a [EMAIL PROTECTED] alias just to assign those bugs to so that we maintainers do not need to see them. Or maybe implement new bugzilla keywords, like STABLEREQ and KEYWORDREQ which would be added to the respective bugs. Then you (the maintainer) can easily create (and save) an advanced search that will filter them out, while still being able to check them in a different search. Might be also useful for arch teams to separate stabling and keywording bugs? - -- Vlastimil Babka (Caster) Gentoo/Java -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJUv5tbrAj05h3oQRAl5fAJ9sLOJNaGPEklLkHewQbBTa9KWEfACfd0mT 8+D47kJEnL59PYCaM/vn3OQ= =DnHW -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
