Re: Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching
Just looking into the future here; would things like archivers or other helpers used by src_unpack move to FDEPEND as well? or would this be limited solely to tools that data transfer? We should keep the data transfer and the unpack phase clearly separated. So, this would best really be for data transfer only. -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI usage
rant [...] standards. So, we declare that gcc-4.5 has to be enough for everyone, we'll just keep it in tree forever and dont bother anymore with all these superfluous does not build with gcc-4.7 bugs. That is not an appropriate analogy, as I'm not suggesting that we refuse to support newer EAPIs. I'm just saying that packages shouldn't be bumped just for the sake of bumping them. Well I'm also not suggesting that we refuse to support newer gcc. Just, if a package does not build with newer, meh, why care. Take old one. /rant I might see some benefit for devs who routinely modify stuff that they don't maintain, but that should generally be kept to a minimum anyway. If unsure how how to edit any particular ebuild, just file a bug! And if the package isn't maintained, then nobody will be bumping its EAPI anyway. True but... we do have some fluctuation, and developers come and go. Who can update the ebuild better, someone who has maintained it for a while and is familiar with its details and the current eapis, or someone who has just picked up its pieces. What I dont actually understand at all is why bumping the EAPI should be so complicated or involved that it even deserves so much resistance... OK there may be miraculous eclasses (or one in particular) which change api radically from eapi to eapi, but I think we've already decided long time ago that this is a bad thing(tm) and should not be done. So let's hope it will not happen again. Other than that, I can not remember any ebuild where the EAPI bump alone took me more than 5min. Now take the frequency of new eapi's coming out, and compare it with the time that you need for a version bump of a package anyway (check upstream changelog, verify dependencies have not changed, do a test build, check for correct installation locations, ...) As an additional bonus this keeps your memory fresh about all the great new features... Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI usage
Bottom line is that what a developer MUST do is a matter of what people will bother to complain to Devrel about, and what Devrel will bother to enforce. For the most part this boils down to common sense. Err... if that's the part you worry about, I'm personally completely happy if we just all agree that it's common sense to stick to the newest council- approved development with fullest feature set. no need to put it in writing any more than as a strong recommendation. :) And since EAPIs aren't actually ordered, is the latest one whichever is actually last approved, or the one which is most functional? Suppose EAPI xml To be honest I personally consider that (eapis are not ordered) an abomination, and my personal wish would be to keep them large-scale ordered with (among one major version) unordered sub-versions (4-xxx) if needed. or at least keep all PMS-approved eapis ordered. Experimental eapis for use in third party software should not require any mentioning in pms anyway. :] However, that is a different discussion. Someday I'll start a separate flamewar^H^H^H^H^H^H^Hmailing list thread about it. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Future Trends
Am Samstag, 1. September 2012, 17:09:59 schrieb llemike...@aol.com: Colleagues, I have been considering the current push to replace init with systemd for all Linux systems. [snip] Comments? Mike Please ignore. We've had enough pointless systemd threads already. -- Andreas K. Huettel Gentoo Linux developer kde (team lead), sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI usage
Am Donnerstag, 30. August 2012, 12:57:25 schrieb Rich Freeman: On Thu, Aug 30, 2012 at 6:28 AM, Johannes Huber j...@gentoo.org wrote: scarabeus suggested the change dev should use latest eapi when bumping to dev must use latest eapi when bumping if not forbidden by eclasses. He was asked to bring it up on the mailing lists, to get a better definition of when what EAPI should be used. I raised the issue through scarabeus, as in my opinion there is no reason to not use latest EAPI. So please discuss. I can't say I'm a big fan of this. This requires forcing changes to ebuilds that offer no actual benefit to either the maintainer or the end-users (changes that actually have some benefit to either are likely to be made anyway). The PM maintainers have chimed in that there is no benefit to PM maintenance from this change. So, I can't really see what the upside of such a policy is. rant Let's say, we as in Gentoo decide that we're completely sick of keeping all that old code out there adjusted to newer and newer gcc versions that are more and more critical towards minor details of the c++ standards. So, we declare that gcc-4.5 has to be enough for everyone, we'll just keep it in tree forever and dont bother anymore with all these superfluous does not build with gcc-4.7 bugs. Well, newer gcc versions might have some very minor marginal advantages, but they require that we mess with code that has worked for ages. They require that we actually give some thought on the evolution of the language semantics or nag upstream, but we can't really be bothered with that because of limited time. Also, keeping gcc-4.5 will always (trivially) keep us backward compatibility... much more important than forward compatibility, should porting to a much never future version ever become necessary. For a real world analogy, serious quakes happen only once a century... why should we even bother with improving building codes? I mean, at some point in the future things will fall apart anyway. Better dont shake anything in between. /rant Sorry but I could not really resist... please take it with a grain of salt. However, seriously, ... Give me one non-trivial ebuild where you can absolutely guarantee that a bump from EAPI=0 to EAPI=4 will not enable any improvements (in readability, failsafe behaviour and code size for example). Last point, if someday the tree contains ebuilds with 7-8 different EAPI's, we'll have succeeded in generating an unmaintainable mess (tm). It will not be any fun to look up things in PMS anew everytime you edit something. (Was the prayer to Paludis only required in EAPI=7 in src_prepare or in EAPI=8 in pkg_preinst?) This problem could however also be solved by selectively phasing out in-between EAPIs (i.e. deprecate EAPIs 1 and 3 asap). Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer kde (team lead), sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI usage
Am Freitag, 31. August 2012, 11:11:37 schrieb Fabian Groffen: On 31-08-2012 11:03:06 +0200, Andreas K. Huettel wrote: any fun to look up things in PMS anew everytime you edit something. (Was the prayer to Paludis only required in EAPI=7 in src_prepare or in EAPI=8 in pkg_preinst?) This problem could however also be solved by selectively phasing out in-between EAPIs (i.e. deprecate EAPIs 1 and 3 asap). I guess you meant 1 and 2. Actually I dont care... but 2 could certainly go faster than 3, true. :) -- Andreas K. Huettel Gentoo Linux developer kde (team lead), sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI usage
Am Donnerstag, 30. August 2012, 12:59:07 schrieb hasufell: Could you elaborate what the reasons FOR it are (not that I don't know any, but you brought it up) since this will add work for every developer to check a) how the behavior of the new EAPI impacts the current ebuild and b) how the behvaior of inherited eclasses change depending on EAPI. a) Easier eclass maintenance. Restricting the kde4 eclasses to EAPI 3 and 4 made the code indeed simpler. We'll raise that to 4 only soon (after fixing the remaining ebuilds in the tree.) b) Easier overall tree maintenance. I've recently removed a useflag on poppler (xpdf-headers for those interested). Of course, this involved fixing all in-tree reverse dependencies first. Now I consider myself very lucky there, because all except two packages were EAPI 4 and I could use (+). One package was EAPI 3 and I unceremoniously bumped it to 4. One was EAPI 0. Having fun with || there. I dont consider this list complete, feel free to add. -- Andreas K. Huettel Gentoo Linux developer kde (team lead), sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.
Am Dienstag, 28. August 2012, 00:19:28 schrieb Michał Górny: Right now, it just contains the function Tiziano listed in his post[1]. I'd appreciate further ideas, feedback, and possibly an example from someone who will actually need it. How about a function that just outputs the entire required dependency string? Such that we can (similar to add_kdebase_dep) write DEPEND=$(add_boost_dep) (Probably we may want to pass parameters here for useflags and version, here's the doc for kdebase_dep from kde4-functions.eclass (and for boost we would not need a package name): # @FUNCTION: add_kdebase_dep # @DESCRIPTION: # Create proper dependency for kde-base/ dependencies. # This takes 1 to 3 arguments. The first being the package name, the optional # second is additional USE flags to append, and the optional third is the # version to use instead of the automatic version (use sparingly). # The output of this should be added directly to DEPEND/RDEPEND, and may be # wrapped in a USE conditional (but not an || conditional without an extra set # of parentheses). ) Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer kde (team lead), sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Maintainer needed: dev-python/pivy sci-libs/opencascade media-gfx/freecad
Dear all, once upon a time I thought it was a good idea to have FreeCAD (and its rdeps pivy and opencascade) in the Gentoo tree. However, this turned out to be painful, especially since I'm not really working with it anymore. (pivy is dead upstream and does not build with gcc-4.7, opencascade is a HUGE library set maintained by a company with a community fork by now, all is rather, err, interesting code and build systems. License situation is complicated.) If you're interested, please pick the packages up; otherwise I'll drop all three packages to maintainer-needed in a few days. Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer kde (team lead), sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: app-text/epdfview
# Andreas K. Huettel dilfri...@gentoo.org (7 Aug 2012) # Many display bugs and compatibility problems, does not build with cups-1.6. # Upstream is dead. There's no real way to support this anymore. Masked for # removal in 30 days. app-text/epdfview -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: app-text/epdfview
Am Dienstag 07 August 2012, 00:28:16 schrieb Andreas K. Huettel: # Andreas K. Huettel dilfri...@gentoo.org (7 Aug 2012) # Many display bugs and compatibility problems, does not build with cups-1.6. # Upstream is dead. There's no real way to support this anymore. Masked for # removal in 30 days. app-text/epdfview Improved message: # Andreas K. Huettel dilfri...@gentoo.org (7 Aug 2012) # Many display bugs and compatibility problems, does not build with cups-1.6. # Upstream is dead. There's no real way to support this anymore. Masked for # removal in 30 days. Unfortunately the best lightweight replacement I can # recommend is app-text/apvlv, otherwise you can go for app-text/acroread # (huge, closed source), kde-base/okular (KDE), or app-text/evince (Gnome). app-text/epdfview -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] UTF-8 locale by default
If it turns out that C or POSIX is the most common response, we should then default the locale to en_US.UTF-8 if we really want to default to a UTF-8 setting. The reason being it makes sense to have the default locale set to the country of origin, which in our case is the United States. Given the number of Gentoo devs (especially on the desktop side where this matters most) from other parts of the world, that's not really a valid argument. In particular in cases as e.g. Paper size setting, where basically US stubbornness stands against the rest of the planet. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: Re: [gentoo-dev] Fraunhofer FDK license
On Thu, 26 Jul 2012, Luca Barbato wrote: I'd add it, it is a gpl incompatible opensource license. No problem to add it. But IMHO the usage restriction in section 3 makes it non-free: You may use this FDK AAC Codec software or modifications thereto only for purposes that are authorized by appropriate patent licenses. Ulrich Indeed, and this opens another can of worms since (as far as I can see) there are no specific license clauses in the AAC patent license for applications that may be distributed without cost. I.e., licensing fees still apply as per unit fee. http://www.vialicensing.com/licensing/aac-overview.aspx Sometimes I have the feeling that Fraunhofer (which is after all funded 30% by German federal and state money) just does not get it. -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: Re: [gentoo-dev] epatch still no helper function? [from eutils.eclass]
On Wed, Jul 18, 2012 at 5:33 PM, hasufell hasuf...@gentoo.org wrote: epatch is so widely used and basic that I wonder why it's still not implemented as a real helper function. Because then its harder to change, it must be in PMS, otherwise you have to do things like test which version of epatch the package manager providessounds a lot like EAPI :) You know, that's actually a pretty good case *for* base.eclass, eutils.eclass and similar... we should probably move more functions there... :D -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing
Re: [gentoo-dev] rfc: old udev versions
I've looked at the kernel packages we have in /usr/portage, but have no guide there either. If I go by gentoo-sources, I could get rid of all but very recent versions of udev, but I have heard some things also about people using older kernels. Also, vanilla-sources goes all the way back to 2.6.16 (I have no idea why)? Well just for the record my vserver (xen domU) hoster is still going strong with 2.6.30 ... I'm trying to get that changed but with 10€/month I'm probably not the strongest financial incentive... a pity because otherwise I'm really very happy with the company... -a -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] base.eclass
Am Sonntag 08 Juli 2012, 22:10:02 schrieb Michał Górny: On Sun, 08 Jul 2012 19:49:25 +0200 René Neumann li...@necoro.eu wrote: Hi all, I'd like just to receive a short clarification about the 'status' of base.eclass: Is this eclass expected to be available everywhere, i.e. should each eclass make sure it imports and incorporates it. Or is it just an eclass like the others and ebuilds should make sure they inherit it if needed? No. It is unmaintained, has serious design flaws and it simply should not be used anywhere. At least in EAPI != [01]. Please clarify this. A lot of (inheriting eclasses and) packages depend on features provided by base.eclass (e.g., PATCHES), which are pretty neat and which I would sorely miss. So I would certainly object to deprecating base.eclass, unless its relevant functionality is only moving to a better place. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: Re: [gentoo-dev] RFC: Enable FEATURES=userpriv usersandbox by default?
I guess something like this might work in pkg_postinst of the portage ebuild: find $DISTDIR -maxdepth 1 -type d -uid 0 | xargs chown -R portage:portage I would only trigger something like this once, when upgrading from a version that doesn't have userpriv enabled by default. If you run ebuild as user (belonging to group portage), that won't help... better add a chmod -R g+w too... -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: Re: Re: [gentoo-dev] RFC: Enable FEATURES=userpriv usersandbox by default?
I guess something like this might work in pkg_postinst of the portage ebuild: find $DISTDIR -maxdepth 1 -type d -uid 0 | xargs chown -R portage:portage I would only trigger something like this once, when upgrading from a version that doesn't have userpriv enabled by default. If you run ebuild as user (belonging to group portage), that won't help... better add a chmod -R g+w too... Scratch that. It would not have worked before either, so the user has to do something him/herself either way. I guess we dont have to care for this case. -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage
Am Samstag 30 Juni 2012, 13:22:39 schrieb Zac Medico: On 06/30/2012 04:07 AM, Pacho Ramos wrote: I would like to discuss a bit more issues like: https://bugs.gentoo.org/show_bug.cgi?id=423087 Even if there are a lot of packages that can cause this breakage when downgraded, I think it should be prevented and package managers shouldn't try to downgrade this kind of packages as they will later cause a total breakage. People is not supposed to know that downgrading some package system will, for example, have an unusable gcc. It seems like a die in pkg_pretend would serve pretty well. As a comparatively simple, user-oriented workaround, since this only happens at downgrades and these should be pretty rare, I have the following suggestion: Make a portage feature that is **on by default**, which causes portage to generate a binpkg of the version to be unmerged, in the case of a downgrade. Rationale: * if you know what you are doing, you can switch this off easily * does not take much space since downgrades are rare * should help our users a lot, whenever someone accidentally or not-knowingly downgrades something critical. Thoughts? Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] euscan GSoC project - requesting feedback
Am Mittwoch, 27. Juni 2012, 09:51:06 schrieb Federico fox Scrinzi: The main question is: what would you like to have on this dashboard? Here's another suggestion for euscan: right now we already have rss feeds, but they are far too verbose for me and clutter up my news list. I dont really need an item whenever something enters portage How about a news feed that only contains upstream items? Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer kde (team lead), sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: euscan GSoC project - requesting feedback
I'd like to see the information regarding current tree state updated more regularly than the full upstream scan. Especially when looking at the herd view, it can be hard to keep track of which bumps have already been completed. Good idea- it should be much cheaper to do the tree update than to re-scan upstream... -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] euscan GSoC project - requesting feedback
The main question is: what would you like to have on this dashboard? Not only the information whether ~arch is outdated, but also whether stable is outdated... custom newsletter based on the packages you're watching, please also as rss feed... cheers, andreas -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] A friendly reminder: Ciaran McCreesh is not a Gentoo dev
Am Freitag 22 Juni 2012, 04:12:48 schrieb Sylvain Alain: Amen to that too, but can you post the actual comments that he said ? SMTP Error 552 Message too large -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/
[gentoo-dev] Authorship of app-doc/pms
Dear all,
according to git blame, this is the distribution of authorship across the
current git master of the pms tex source.
2 Pierre-Yves Aillet
5 Fernando J. Pereda
6 Mark Loeser
7 Richard Brown
8 Thomas Anderson
25 NotCommittedYet (???)
27 Bo Ørsted Andresen
28 Brian Harring
37 Michał Górny
197 David Leverton
557 Ulrich Müller
678 Stephen Bennett
694 Christian Faulhammer
1903Ciaran McCreesh
Given that and my usual subtlety, I think the current title page misrepresents
contributorship, and would like to request that the following patch is applied
to branches master and eapi-5.
Best, Andreas
From 3572b4cb400b2ff156e4f28d3dffe82c687a1dc9 Mon Sep 17 00:00:00 2001
From: Andreas K. Huettel andreas.huet...@physik.uni-r.de
Date: Thu, 21 Jun 2012 14:03:24 +0200
Subject: [PATCH] Update author information
---
pms.cls | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/pms.cls b/pms.cls
index db2fd48..b2faef1 100644
--- a/pms.cls
+++ b/pms.cls
@@ -114,7 +114,7 @@
citecolor=black,
linkcolor=black,
pdftitle={Package Manager Specification},
-pdfauthor={Stephen P. Bennett, Ciaran McCreesh},
+pdfauthor={Ulrich Mueller, Stephen P. Bennett, Christian Faulhammer,
Ciaran McCreesh},
pdfcreator={pdfLaTeX and hyperref},
pdfsubject={Defining a feature set for package managers in the
Gentoo world},
@@ -125,10 +125,19 @@
}
% Some metadata needed for the title page generation
\title{Package Manager Specification}
-\author{Stephen P. Bennett \\
-\href{mailto:s...@exherbo.org}{s...@exherbo.org} \and Ciaran
-McCreesh \\
-\href{mailto:ciaran.mccre...@googlemail.com}
{ciaran.mccre...@googlemail.com}}
+\author{
+Ulrich Müller \\
+\href{mailto:u...@gentoo.org}{u...@gentoo.org}
+\and
+Stephen P. Bennett \\
+\href{mailto:s...@exherbo.org}{s...@exherbo.org}
+\and
+Christian Faulhammer \\
+\href{mailto:fa...@gentoo.org}{fa...@gentoo.org}
+\and
+Ciaran McCreesh \\
+\href{mailto:ciaran.mccre...@googlemail.com}
{ciaran.mccre...@googlemail.com}
+}
% Reads the last commit date from the Git repository and even succeeds
% when none is available
\ifthenelse{\equal{\VCDateISO}{}}
--
1.7.9.4
--
Andreas K. Huettel
Gentoo Linux developer
kde, sci, arm, tex, printing
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: Re: [gentoo-pms] Authorship of app-doc/pms
Dear all, according to git blame, this is the distribution of authorship across the current git master of the pms tex source. Not that I particularly mind either way, but your stats are way off due to reformatting. If you just use git blame, someone who changes a \t to a \em in a paragraph gets measured as writing that line and every line in the paragraph following it. If you're looking to change the authors list, I recommend doing so based upon asking people whether they think they should be on there, and adding anyone who says yes, rather than on bogus stats. Well at least I added some data to undermine my request. Your turn now. -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
[gentoo-dev] monthly Gentoo KDE team meeting
Howdy all, just for general information the Gentoo KDE team has its monthly public meeting again next week, to be precise, #gentoo-meetings on freenode, thursday, 21 June 2012 19:00 utc Agenda can be found here (work in progress): http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/maintainers/meetings/meeting-2012-06;hb=HEAD Cheers! Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: Re: [gentoo-dev] Git braindump: 1 of N: merging git signing
A signed commit is a signing of the git metadata; tree hash (literally, the state of the tree), committer, author, message, and parent sha1. Each git commit includes it's parent sha1 in it; this gives a locked history for a given commit sha1 (unless someone preimages sha1). What matters is that the leaf node, the final point in the graph, is signed- that's a dev sign off on effectively that they created that particular locked history. Realistically signing of each node is preferable, but the leaf is the minimal required. No. What is signed is the new data plus the parent hash(es). No such thing as a tree hash. -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)
Am Sonntag 03 Juni 2012, 11:46:16 schrieb Robin H. Johnson: If there are enough Alice developers, is it a possibility that Bob will never have a chance to get his commit in? All this requires, is that in the time it takes Bob to do 'git pull', Alice manages to do 'git push' again. We definitely have to take care of this somehow. However, it would be nice to have some numbers to estimate how acute the problem will be. As I'm definitely not a CVS guru, what's the best way to extract commit times to the gentoo-x86 tree? ( What I'd ask for is as raw data - take all commits (say, for the last year), filter out Manifest-only stuff, make a text file with only the timestamps for each commit, ideally one per line and already in seconds in epoch format... This, being pretty similar to whatever comes out in our labs, could then be postprocessed and visualized... :) ) Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Git braindump: 1 of N: merging git signing
Am Sonntag 03 Juni 2012, 10:18:24 schrieb Robin H. Johnson: I propose: - merges are explicitly allowed, even non-fast-forwards - all commits MUST be signed - if you include a commit from a user: author := non-@gentoo committer := @gentoo signer := $committer Sounds reasonable given the current state of git. Let's just be clear about the following consequence (I hope I understand this correctly): * User makes signed improvements in gentoo-x86 clone * Developer pulls from user and merges * Developer's history contains commits by user, which cannot be pushed to gentoo-x86 Which means in the end all merges are explicitly allowed, as long as they only contain developer commits; commits pulled from users must be rebased. This is something that (IMHO) we could certainly live with; the only thing I am worried about is, how do we automatize it so a developer who is not end-of- the-line git guru and ends up with some user-signed commits in his history can clean up his local tree again. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Git braindump: 1 of N: merging git signing
Am Sonntag 03 Juni 2012, 18:01:04 schrieb Dirkjan Ochtman: On Sun, Jun 3, 2012 at 12:39 PM, Andreas K. Huettel dilfri...@gentoo.org wrote: Sounds reasonable given the current state of git. Let's just be clear about the following consequence (I hope I understand this correctly): * User makes signed improvements in gentoo-x86 clone * Developer pulls from user and merges * Developer's history contains commits by user, which cannot be pushed to gentoo-x86 Which means in the end all merges are explicitly allowed, as long as they only contain developer commits; commits pulled from users must be rebased. I don't think so. IMO pushing commits by a user should be a fine, as long as they're merged in a non-fast-forward, signed merge commit. Can probably be done, but this must be finetuned in whatever script enforces the rule upon push to the developer. However, then the committer of the contributed commits before the merge is then the user, I guess? (The rule meaning as suggested by Robin - if you include a commit from a user: author := non-@gentoo committer := @gentoo signer := $committer ) Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: net-misc/mDNSResponder
For removal in 30 days. # Andreas K. Hüttel dilfri...@gentoo.org (03 Jun 2012) # Not maintained well in Gentoo for a long time. Better support # for zeroconf is available via net-dns/avahi[mdnsresponder-compat] # - please use that instead. mDNSResponder will be removed soon. net-misc/mDNSResponder -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
The purpose of overlays is to have ebuilds maintained outside of the official Gentoo portage. Importing a ebuild from an overlay whether it uses Git or not means importing the ebuild(s). In the Git context, it means the Gentoo maintainer has to make an import commit the same way it would be done to start a project with somthing like: cp 'files to be commited' . git add . git commit -m 'initial import' So, like explained before your concern is clearly out of the current discussion. Importing commit history from Overlays is not supported and will probably never be. Which does not mean that it's not desirable. The KDE ebuilds are mainly evolving inside the KDE overlay, where KDE betas and live ebuilds live. Being able (in the future) to see the history of an ebuild before it was imported into the main tree would certainly help in some cases. -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
git cat-file -p $sha is as close as you can get to commit objects without needing to write your own decompressing wrapper. But it gives the same results. Now, does the signed data also contain the parent sha? If yes, our discussion about rebasing is moot, because a rebase will in every case destroy previous signatures. -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: Re: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver
On 2 June 2012 03:12, Andreas K. Huettel dilfri...@gentoo.org wrote: git cat-file -p $sha is as close as you can get to commit objects without needing to write your own decompressing wrapper. But it gives the same results. Now, does the signed data also contain the parent sha? If yes, our discussion about rebasing is moot, because a rebase will in every case destroy previous signatures. Yes. Which basically means, you *cannot* have both a) rebase only merges and b) every commit must be signed as policies. I would say that this is a very strong argument in favour of allowing merge commits. -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
[gentoo-dev] net-print/foomatic-filters-ppds
Hi everyone, while I was looking at various printing bugs, I came across the package net- print/foomatic-filters-ppds. It claims to provide the non-ps-printer ppd's for foomatic, but the last version is from 2008. * foomatic-db (current) contains the same printers unprocessed * there is no upstream tarball for foomatic-filters-ppds * I cannot find any documentation how to update one from the other * Debian only has a metapackage for foomatic-filters-ppds, which leads to an installation of foomatic-db and foomatic-db-engine (both current) Does anyone of you know what is going on here? * is foomatic-filters-ppds obsoleted by foomatic-db and foomatic-db-engine? * or should we make an updated tarball? how? Any advice would be enormously appreciated. Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Enable FEATURES=userpriv usersandbox by default?
Am Montag 28 Mai 2012, 23:34:22 schrieb Zac Medico: I've been using FEATURES=userpriv usersandbox for years, and I don't remember experiencing any problems because of it, so I think that it would be reasonable to have it enabled by default. Objections? No objections. Excellent idea. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: KOffice
For removal in 30days... # Andreas K. Hüttel dilfri...@gentoo.org (27 May 2012) # The successor of KOffice, Calligra, has now become stable # and we are removing KOffice soon from the portage tree. # Please upgrade; you can do that with the following commands: # emerge --deselect karbon kexi koffice-data koffice-l10n koffice-libs koffice-meta kplato kpresenter krita kspread kword # emerge app-office/calligra app-office/calligra-l10n app-office/karbon app-office/kexi app-office/koffice-data app-office/koffice-l10n app-office/koffice-libs app-office/koffice-meta app-office/kplato app-office/kpresenter app-office/krita app-office/kspread app-office/kword -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] So...
... since the bugs seem to be stalled and noone has recently posted on gentoo- scm, what's the real status of the infamous git migration? :) Cheers, A -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Please discuss my arguments and come to the conclusions to RESO/WONT-FIX testing git-cvsserver, make a clean cut and remove this bug from the blockers of [TRACKER] portage migration to git. +1 Please cut cvs support once and for all. -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, 23 May 2012 14:42:37 +0200 Kill it! And while we're at it, kill ChangeLogs as well! /me hides... +1 +1 +1 +1 ... -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Remove eclass/ChangeLog (was: Re: [gentoo-commits] gentoo-x86 commit in eclass: autotools.eclass)
Am Sonntag 20 Mai 2012, 15:30:45 schrieb Nirbheek Chauhan: On Sun, May 20, 2012 at 6:55 PM, Michał Górny mgo...@gentoo.org wrote: On Sun, 20 May 2012 15:33:11 +0300 Samuli Suominen ssuomi...@gentoo.org wrote: ChangeLog entries missing for every autotools.eclass modification today. I will repeat once again: autogenerate them. +1 for this, seriously. Yes please. And forget about the difference between user-oriented and dev-oriented. That's only an issue for people with too much time (also for debating). -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: Enable FEATURES=config-protect-if-modified by default?
make.conf(5) man page: This causes the CONFIG_PROTECT behavior to be skipped for files that have not been modified since they were installed. +1 very good idea The best thing about it is not having to worry about missing an important change in a file I DO change, due to all the noise from files I don't touch. exactly!!! -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] pushing fixes to stable before closing bugs
I noticed a general tendency to close bugs affecting stable before pushing the fix to stable. One recent example is https://bugs.gentoo.org/show_bug.cgi?id=399291, but there are more. Not about the general question, but about this specific bug... I never really expected the Calligra release to take so long. KOffice is basically dead code, and will be removed as soon as Calligra goes stable (and I intend to file the stablerequest tomorrow). -- Andreas K. Huettel Gentoo Linux developer kde (team lead), sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] pushing fixes to stable before closing bugs
I noticed a general tendency to close bugs affecting stable before pushing the fix to stable. Right. The idea is that if you only fix in ~arch, you risk a serious and _known_ regression in stable, which could be easily avoided. As already detailed by others, most of the time these bugs involve problems that existed in stable all the time and were fixed in a newer ~arch version. So, no regression. While I understand and applaud your intentions, I dont really intend to keep gazillions of bugs open until the last arch has closed the last stablerequest. Just for the simple reason that this is dead wood in bugzilla, and blocking the view to bugs that actually still need fixing. Also, we dont necessarily know from the beginning which revision will go stable. (BTW, x86 is a bit behind at the moment. :) We might think about a dedicated application for tracking stabilizations, instead of using bugzilla. Alternatively, one could extend bugzilla in a way that each closed bug report MUST contain an affected package version *range*. -- Andreas K. Huettel Gentoo Linux developer kde (team lead), sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] New category for (libre)office extensions: app-officeext
I've collected information and the extensions (should) work with any office variant, openoffice and libreoffice. To be more precise, they should work with anything that uses the so-called uno bridge. This is why I like the new category office-plugins best... and would like to implement that one. Is there any chance that there will be more than one or two office-* categories in future? If not, I think that we shouldn't introduce a new category prefix for this. The category should be named app-* instead. After some discussion with Ulrich on IRC, we settled on the name app-officeext, which we'll be able to fill with a couple of hundred (open|libre)office extensions then... :) I guess this is a compromise that we all can live with. So, I'll implement that tonight. Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New category for (libre)office extensions: app-officeext
Am Dienstag 08 Mai 2012, 12:30:04 schrieb Andreas K. Huettel: After some discussion with Ulrich on IRC, we settled on the name app-officeext, which we'll be able to fill with a couple of hundred (open|libre)office extensions then... :) I guess this is a compromise that we all can live with. So, I'll implement that tonight. And committed. There's already a first package in there, app-officeext/texmaths - a LaTeX replacement for the LO formula editor, generating embedded svg. Give it a try, it's really cool! -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: Re: [gentoo-dev] New category for (libre)office extensions: office-ext?
On Sun, 6 May 2012, Andreas K Huettel wrote: I've collected information and the extensions (should) work with any office variant, openoffice and libreoffice. To be more precise, they should work with anything that uses the so-called uno bridge. This is why I like the new category office-plugins best... and would like to implement that one. Is there any chance that there will be more than one or two office-* categories in future? If not, I think that we shouldn't introduce a new category prefix for this. The category should be named app-* instead. How about app-ooo, following the naming of the virtual? Ulrich Well... we're already breaking that rule by having lxde-base, perl-core, sec- policy... and kde-*, rox-*, xfce-* exist only twice. So I would not handle this requirement too strongly. (I could e.g. imagine categories office-templates, office-filters, but that's right now pure speculation.) app-ooo kind of minimizes the ah yes I know what goes there effect. -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New category for (libre)office extensions: office-ext?
Am Samstag, 5. Mai 2012, 23:15:46 schrieb Markos Chandras:
On 05/05/2012 08:04 PM, Michał Górny wrote:
On Sat, 5 May 2012 20:40:47 +0200 Andreas K. Huettel
dilfri...@gentoo.org wrote:
there's a growing culture of libreoffice extensions, and (with
the help of an eclass prepared by scarabeus) it would be nice to
get some of them into the portage tree. Now we have to decide
where to put them.
Suggestion: new category office-ext
What do you think?
office-plugins, to follow suit.
This may be confusing as people would expect these plugins to work
with both {open,libre}office packages. If these plugins are just for
libreoffice then I would prefer app-libreoffice like other people have
already suggested
I've collected information and the extensions (should) work with any office
variant, openoffice and libreoffice. To be more precise, they should work with
anything that uses the so-called uno bridge.
This is why I like the new category office-plugins best... and would like to
implement that one.
Any additional objections?
Cheers, Andreas
--
Andreas K. Huettel
Gentoo Linux developer
kde (team lead), sci, tex, arm, printing
dilfri...@gentoo.org
http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: libtool.eclass
Am Sonntag, 6. Mai 2012, 14:03:02 schrieb Pacho Ramos: El dom, 06-05-2012 a las 14:41 +0300, Samuli Suominen escribió: eclass/ has a ChangeLog (and this is getting old that everyone keeps ignoring it, I've proposed punting the ChangeLog from eclass/ directory once, and repeating it now) Maybe we could punt ChangeLog from eclass/ and generate it automatically from commit messages Maybe we could punt ChangeLogs generally and generate them from commit messages... err... hasn't this been discussed before? :o( -- Andreas K. Huettel Gentoo Linux developer kde (team lead), sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] cmake-utils.eclass: set default of CMAKE_VERBOSE=1
Am Samstag 05 Mai 2012, 20:54:09 schrieb Andreas K. Huettel:
Am Freitag, 4. Mai 2012, 18:30:10 schrieb hasufell:
# @ECLASS-VARIABLE: CMAKE_VERBOSE
# @DESCRIPTION:
# Set to enable verbose messages during compilation.
By default this is deactivated which is inconvenient imo and results in
pastes having minimum information.
I have to tell users every time to recompile with CMAKE_VERBOSE=1 so
that I have proper information on what is going on.
Are there any arguments against this being default?
I think the resistance against this more has to do with the output being
more esthetically pleasing (yes I know this is not really a good point for
us, but in general the cmake output is quite nice) than with writing to
stdout is expensive (which was a joke in the previous thread).
That being said, it probably makes sense to change the default to =1, as it
definitely helps debugging to see the build commands.
I've taken the liberty to change the default in the kde overlay. We'll likely
move this to the main tree with other changes after some testing. Semantics
needed to change a bit; the description now reads:
# @ECLASS-VARIABLE: CMAKE_VERBOSE
# @DESCRIPTION:
# Set to OFF to disable verbose messages during compilation
: ${CMAKE_VERBOSE:=ON}
--
Andreas K. Huettel
Gentoo Linux developer
dilfri...@gentoo.org
http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] skel.ebuild cosmetics (move RESTRICT after DEPEND)
Am Montag 07 Mai 2012, 01:24:39 schrieb Ulrich Mueller: On Mon, 07 May 2012, Samuli Suominen wrote: On 05/07/2012 01:27 AM, Ulrich Mueller wrote: Are we now using behaviour of editors as a reference? With Emacs or XEmacs, the template includes RESTRICT and places it before DEPEND and RDEPEND. I would rather see RESTRICT dropped from the template included for emacs, because it's not expected for majority of ebuilds to have need for it (a fact). So what? Then you just leave the variable empty. The template (or rather skeleton in Emacs' terms) knows that the RESTRICT variable is optional and will automatically remove the line. The template for emacs should be kept in sync with the example for vim (or whichever way around). The skeleton for Emacs is kept in sync with skel.ebuild and the devmanual, of course. I don't use vim and therefore I don't know what its template does. Therefore I suggest we move this example a bit down in skel.ebuild as it's more logical to continue with new lines instead of applying in-between Any objections? Yes. Please leave it as it is. Yeah, I will if someone has a (good) argument for doing so. RESTRICT and PROPERTIES are on a single line and it's natural to add them to the second group of such variables, namely LICENSE, SLOT, KEYWORDS, and IUSE. Whereas DEPEND and RDEPEND typically extend over several lines; sometimes they are quite long. So, a RESTRICT line placed after *DEPEND will be much more easily missed than in its current place. This entire ridiculous discussion just makes me convinced that it's best to * use neither vi nor emacs * and stick to my own personal preference of variable order, which is not identical to either. Eat this! -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] New category for (libre)office extensions: office-ext ?
Hiya, there's a growing culture of libreoffice extensions, and (with the help of an eclass prepared by scarabeus) it would be nice to get some of them into the portage tree. Now we have to decide where to put them. Suggestion: new category office-ext What do you think? Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer kde (team lead), sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] cmake-utils.eclass: set default of CMAKE_VERBOSE=1
Am Freitag, 4. Mai 2012, 18:30:10 schrieb hasufell: # @ECLASS-VARIABLE: CMAKE_VERBOSE # @DESCRIPTION: # Set to enable verbose messages during compilation. By default this is deactivated which is inconvenient imo and results in pastes having minimum information. I have to tell users every time to recompile with CMAKE_VERBOSE=1 so that I have proper information on what is going on. Are there any arguments against this being default? I think the resistance against this more has to do with the output being more esthetically pleasing (yes I know this is not really a good point for us, but in general the cmake output is quite nice) than with writing to stdout is expensive (which was a joke in the previous thread). That being said, it probably makes sense to change the default to =1, as it definitely helps debugging to see the build commands. @infra: However, please raise the file size limit for bugzilla then, and if possible, please fix the use of compressed build logs. Right now, I would not recommend uploading a compressed log to bugzilla, because: * I have not found a way to have firefox uncompress and display it correctly with one click (always have to download, save, ...) * and often files end up double-compressed, i.e. save log.gz, gunzip, rename log to log.gz, gunzip :( Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer kde (team lead), sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force
Am Freitag 27 April 2012, 17:26:48 schrieb Zac Medico:
Maybe I'm missing something, but what would happen when the newest
version of a package is marked stable? The masked USE flags would
become unavailable for everyone?
In order to be practical, I guess we'd have to add a constraint which
says that if KEYWORDS contains the stable variant of a particular
keyword, then it should also be considered to implicitly contain the
unstable variant when the package manager is deciding whether or not to
apply package.use.{mask,force}.
So, here's a description of the whole algorithm that I'd use:
1) Let EFFECTIVE_KEYWORDS equal the set of values contained in KEYWORDS,
plus ** and all the unstable variants of the stable values contained in
KEYWORDS. For example:
KEYWORDS=~amd64 x86 - EFFECTIVE_KEYWORDS=~amd64 x86 ** ~x86
2) Intersect EFFECTIVE_KEYWORDS with effective ACCEPT_KEYWORDS, where
effective ACCEPT_KEYWORDS includes any relevant values from
package.accept_keywords. For example, here is a table of intersections
of EFFECTIVE_KEYWORDS=~amd64 x86 ** ~x86 with various effective
ACCEPT_KEYWORDS values:
ACCEPT_KEYWORDS | INTERSECTION | package.stable
-
x86 | x86 | yes
x86 ~x86 | x86 ~x86 | no
** | **| no
amd64 ~amd64 | ~amd64| no
3) Apply package.stable settings if INTERSECTION contains only stable
keywords. For example, see the package.stable column in the table above.
That is the best description I've seen so far, which exactly describes the use
case that I had in mind. +1 :)
--
Andreas K. Huettel
Gentoo Linux developer
dilfri...@gentoo.org
http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force
Am Freitag 27 April 2012, 13:35:21 schrieb Chí-Thanh Christopher Nguyễn: Ciaran McCreesh schrieb: * two new files in profile directories supported, package.use.stable.mask and package.use.stable.force * syntax is identical to package.use.mask and package.use.force * meaning is identical to package.use.mask and package.use.force, except that the resulting rules are ONLY applied iff a stable keyword is in use This means that an ebuild will effectively change when moved from ~arch to arch. The point of ~arch is to test ebuilds before they're moved to arch. I agree that the ~arch ebuilds should be tested in the same configuration in which they will end up in arch. However in this case, the possible configurations for arch are a subset of those in ~arch, so the testing covers those too. Right now, it's more likely that just before filing the stablerequest an ebuild is modified such that the useflag disappears and all the conditional codeblocks are set to a fixed value. (Compare cups-1.5.2-r3 and -r4) That includes a much larger danger of mistakes creeping in. Just forcing an useflag on or off poses a fairly minimal intrusion. I see a problem where a significant proportion of ~arch users will have this flag enabled (which is obviously the point of package.use.stable.mask) so the arch configurations will see fewer testers. This issue may need to be addressed, e.g. by extending stabilization period or disallowing package.use.stable.mask in default or desktop profile. Well, at least in some use cases the useflag will have an obvious disadvantage (remember the many libusb-backend bugs in cups-1.4). Then the consensus would have been you can use this but it's not as bug-free, there may have been even an ewarn about it, ... Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force
Am Freitag 27 April 2012, 16:31:10 schrieb Ian Stakenvicius: Where this would (have been|be) useful: * we had for a long time different revisions of subversion with/without kde useflag * cups-1.4 had the infamous libusb backend triggered by USE=usb * cups-1.5 has optional systemd support via a systemd useflag, which pulls in non-stabilized systemd as dependency... I'm not sure that I'm following the cups examples here. For cups-1.5 even if it were stable, if someone actually wanted to use systemd on their system and unmasked/keyworded it (while running stable everything else) I don't see why this would be an issue that would need this new masking feature (unless IUSE=+systemd, which probably shouldn't be the case anyways). The point is that as it is now cups(-1.5.2-r20) could not be stabilized without a stable systemd, because systemd is a dependency (optional on useflag systemd). -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force
Am Freitag 27 April 2012, 11:30:57 schrieb Michael Haubenwallner: On 04/27/12 00:03, Andreas K. Huettel wrote: as soon as possible (which likely means in the next EAPI?): * two new files in profile directories supported, package.use.stable.mask and package.use.stable.force * syntax is identical to package.use.mask and package.use.force * meaning is identical to package.use.mask and package.use.force, except that the resulting rules are ONLY applied iff a stable keyword is in use Wouldn't it be more obvious/simple to have an extra profile subdirectory containing package.use.mask and package.use.force? While this works (kind of), it is like running globally stable or globally testing. So, if you run stable but add one package with ~arch keyword, you are restricted to the stable useflag set there as well... -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force
Dear all, I'd like to suggest we introduce the following very useful feature, as soon as possible (which likely means in the next EAPI?): * two new files in profile directories supported, package.use.stable.mask and package.use.stable.force * syntax is identical to package.use.mask and package.use.force * meaning is identical to package.use.mask and package.use.force, except that the resulting rules are ONLY applied iff a stable keyword is in use Rationale: Often single features are not ready for production yet, but the remaining package with that feature disabled would be a perfect candidate for stabilization. Right now this can be solved by * masking the useflag, which then makes the feature inaccessible even for ~arch * masking the useflag for exactly one package revision, which is hell to maintain * or introducing different package revisions with/without the useflag, which is also a mess. Where this would (have been|be) useful: * we had for a long time different revisions of subversion with/without kde useflag * cups-1.4 had the infamous libusb backend triggered by USE=usb * cups-1.5 has optional systemd support via a systemd useflag, which pulls in non-stabilized systemd as dependency... Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Making user patches globally available
Right now we have support in some packages for user patches - those being patches dropped into /etc/portage/patches/pkgname/ - which are automatically applied. Because this feature is implemented by epatch_user() in eutils.eclass, it is only available for ebuilds that inherit eutils and explicitly call epatch_user or inherit another eclass that calls it in an exported phase (eg. base). The end result is a very inconsistent experience, where user patches may or may not work not only on a package-by-package basis, but ebuild-by-ebuild. Is there any reason why this couldn't just be done in the package manager, making user patches available for all ebuilds without code changes? Well as people have already pointed out, the problem is where to place it: * before src_prepare is bad because of gentoo-patches * after src_prepare is bad because of eautoreconf calls in src_prepare I would even suggest a more radical approach, namely (for an upcoming EAPI) to migrate some of the features of base.eclass into the package manager. Applying patches is a universal problem which should be handled as central as possible. As example, (in that future EAPI) * have patches from the PATCHES array be applied automatically _before_ src_prepare (the same way as done currently in base_src_prepare) * have user patches applied afterwards (either if a FEATURE is set, or generally) * disallow or deprecate at least direct calls to epatch, to ensure ordering * (and adapt the functions in base and eutils accordingly for that EAPI) Opinions? Best, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] lurking *.ebuild'less packages
Am Donnerstag, 15. März 2012, 21:59:44 schrieb Sergei Trofimovich:
ls: cannot access
/gentoo/portage/metadata/cache/kde-base/kdebindings-perl-*: No such file
or directory ls: cannot access
/gentoo/portage/metadata/cache/kde-base/kdebindings-ruby-*: No such file
or directory ...
In the case of kde ebuilds it's a slip-up, a side effect of kde-4.6 removal...
some code got refactored and moved to different package names. E.g.
kdebindings-ruby is now partly in korundum and krossruby... When one of us
then runs
find kde-base -name *4.6.5*ebuild -exec cvs rm -f {} +
and commits, oops, suddenly we have an empty dir kdebindings-ruby... :|
Obviously undesired but can happen, and repoman does not complain (yet).
(It makes no sense to do any last-riting here, in effect this is more like a
package move and we try to make it as transparent to the users as possible.)
Cheers, A
--
Andreas K. Huettel
Gentoo Linux developer
kde, sci, tex, arm, printing
dilfri...@gentoo.org
http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] New eclass for Python
Am Mittwoch 29 Februar 2012, 21:24:49 schrieb Krzysztof Pawlik: Second, there doesn't seem to be any support for packages that do not install in python's site-packages and do not allow multiple python ABIs. If I have, for example, a package that installs python modules in /usr/lib/appname or /usr/share/appname, how can I specify that PYTHON_TARGETS=python2.6 or python2.7 or python3.2 is allowed, but something like PYTHON_TARGETS=python2.7 python3.2 is not? You're correct, note that I've stressed that this eclass is mainly for distutils-based packages. I'm not using Gnome, so can you provide some package examples that I can look at? personal opinion If package decides to use given language then please, please play by the rules set by the rest of world (Ruby - gems, Python - distutils, Perl - CPAN, PHP - PEAR). I don't like installing Python code outside of site-packages, the only exception to that rule is portage (at least for now). /personal opinion We will hit the same problem with KDE (actually we already hit it): it has various types of scripting support, and each installs a KDE library linked to whatever language interpreter. (Now, that library- is it a Python/Ruby library or a KDE library? Because it is at the proper place for KDE stuff :) It's not just about calling an external language but also about embedding the interpreter for in-app scripting... and KDE rather heavily relies on python. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] color management in gentoo (kde expecially) proposal for help
Hi Francesco, certainly help is always welcome! ( thanks for all your upstream work with digikam and its database!) I'd love to offer my help on the Gentoo side, but unfortunately I'm just about to leave in a couple of days for a long (4weeks) business+vacation trip. While I'll take my laptop and occasionally do Gentoo stuff, I wont be able to dedicate much time... Best thing is probably to talk to the guys on #gentoo-kde, and if you have questions about other software they can help you find the right people. Cheers, Andreas Hi, my name is Francesco Riosa, I would be interested in a more complete support of the oyranos color managment programs in ::gentoo. Oyranos is intended to be multy platform and in some sense multy os, but in the current incarnation has good support for kde. In case there is interest I can apply to return as a developer in gentoo, will respond to emails this week end (25/26 Feb) I'm _not_ offering support for digikam, for which I develop, because I would like to mantain a two step verification process (developer/packager) Regards, Francesco -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
Re: Re: [gentoo-dev] About gcc-4.6 unmasking
Bleh, looks like grub is blocking this :(, will need to wait then (or maybe move to grub2 ;)) Yeah... anyone helping to debug this tricky thingy [*] is likely welcome. Would like to help, but cant do much atm because of real-life work load... [*] https://bugs.gentoo.org/show_bug.cgi?id=360513 -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Maintainer needed: app-office/libreoffice, app-office/libreoffice-bin, app-office/libreoffice-l10n
Dear all, Right now, noone is taking care of named packages and/or their bugs, after the most active dev left the herd. I've asked on the herd alias some days ago if anyone is willing to step in, however there was no positive reply (and barely a reply at all). For this reason I've assigned app-office/libreoffice app-office/libreoffice-bin app-office/libreoffice-l10n to maintainer-needed, and would like to ask anyone interested and willing to help to step in and revive the openoffice team. Cheers, Andreas [PS. If anyone wonders why I'm taking care of this, the openoffice team was about to become the office team some time ago, and I'm taking care of koffice / calligra and occasionally other kde-related office apps as kmymoney...] [PPS. However fitting, this only coincides with Chithanh's mail by accident...] -- Andreas K. Huettel Gentoo Linux developer kde, sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] app-laptop/thinkpad needs a new maintainer
Am Sonntag 29 Januar 2012, 14:22:59 schrieb Ian Stakenvicius: On 29/01/12 05:19 AM, Pacho Ramos wrote: As seen in: https://bugs.gentoo.org/show_bug.cgi?id=381263#c1 Current maintainer can no longer maintain this one actively and mobile herd seems to not care about it. Feel free to pick it up :) Thanks a lot I'll take this one, at least until i have to replace my laptop. Are you sure this is actually still needed? The download link leads to the page of tp_smapi, which is a separate Gentoo package... -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: app-text/xpdf
# Andreas K. Hüttel dilfri...@gentoo.org (27 Jan 2012) # Has developed into an unmaintainable mess, and everyone who # knows about it is either retired or missing in action. # Several minor bugs and one ugly security issues (#386271). # Masked for removal because of lack of maintainer. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: media-fonts/gnu-gs-fonts-*
+ 24 Jan 2012; Andreas K. Huettel dilfri...@gentoo.org package.mask: + Finally mask media-fonts/gnu-gs-fonts-* for last-riting, ending + year-long annoyance in bug 247657. Replaced by media-fonts/urw-fonts. + Removal in 30 days. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Large ChangeLogs now split
Hiya everyone, just for your information, as discussed and agreed some time ago [*], all ChangeLog files in gentoo-x86 have now been manually split following an algorithm similar to logrotate (size 100K, yearly). For details see the thread linked below. Cheers, Andreas [*] http://archives.gentoo.org/gentoo- dev/msg_c3436497e445eaf86deea08772e5.xml -- Andreas K. Huettel Gentoo Linux developer kde, sci, tex, arm, printing dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: Re: [gentoo-dev] making the stable tree more up-to-date
That said, there is probably room for debate over the length of time we leave the bug open. Maybe a week isn't quite long enough - maybe two weeks is better. I'd like to support that suggestion. The new process is a great thing, just give us a little bit more time to respond please... :) (Not everyone who is busy immediately makes a devaway entry, but things may delay anyway...) Cheers, A -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing
Re: [gentoo-dev] News item for KDEPIM-4.7 stabilization
Attached is the latest version of the news item after feedback. @pr: could one of you commit this please? Thanks, Andreas Am Sonntag 04 Dezember 2011, 18:16:03 schrieb Andreas K. Huettel: Hi everyone, we're about to stabilize KDEPIM-4.7 for the first time (last stable KDEPIM suite is 4.4.11.1). Below is a news item for that, which I'd like to get out in 48hours as long as there are no major problems. The news item can also be found (in possibly updated form) at http://dev.gentoo.org/~dilfridge/2011-12-06-kde473-kdepim.en.txt Please send your feedback and improvements! -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ Title: Stabilization of KDE 4.7.3 including KDEPIM Author: Andreas K. Huettel dilfri...@gentoo.org Content-Type: text/plain Posted: 2011-12-06 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: kde-base/libkdepim-4.5 Display-If-Installed: kde-base/blogilo-4.5 Display-If-Installed: kde-base/kabcclient-4.5 Display-If-Installed: kde-base/kdepim-strigi-analyzer-4.5 Display-If-Installed: kde-base/konsolekalendar-4.5 Display-If-Installed: kde-base/libkleo-4.5 Display-If-Installed: kde-base/libkpgp-4.5 We are pleased to announce the upcoming stabilization of KDE 4.7.3. In general the upgrade of KDE from 4.6.5 to 4.7.3 should be unproblematic. However, if you are using the KDEPIM application suite (i.e., akregator, blogilo, kmail, knode, kontact, korganizer, and others) where the stable version so far was 4.4.11.1, please be aware of the following: The stable upgrade from KDEPIM 4.4.11.1 to KDEPIM 4.7.3 is a MAJOR upgrade with potential for major breakage. Therefore we will *try* to keep and support the old, so-far stable KDEPIM 4.4.11.1 as long as possible. If you *dont* want to upgrade your KDEPIM yet but keep the old version, please download the following file and add it into your /etc/portage/package.mask: http://www.gentoo.org/proj/en/desktop/kde/kdepim-4.7-mask.txt If you decide to upgrade, please have a look at the upgrade guide first: http://wiki.gentoo.org/wiki/KDEPIM-4.7_upgrade signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] sources.gentoo.org instability
Seriously, what do we gain from crawlers accessing sources.gentoo.org? I cant really remember seeing it once in a google query result... Possibly it would not even be required to deny all requests, but just deny everything related to ancient history... Hello, For a while sources.gentoo.org has been puttering along and its health has slowly declined. We migrated it to some newer shiny hardware in an attempt to mitigate the problem but that did not pan out. 90% (or more) of sources.gentoo.org traffic is crawler bots and not actual humans. That being said; if we cannot serve requests to the bots within our timeouts we serve 500's instead which is never really what we want (particularly when we spent 20s of CPU to calculate 80% of the response only to see the client timeout :/.) The majority of the expensive requests are related to package.mask and use.local.desc queries by crawlers. Like crawling the entire 13000 rev history for package.mask (or similar.) While it is likely we will monkey patch viewvc to be less wasteful; in the meantime I have removed use.local.desc from sources.gentoo.org (and also anoncvs, because they share the same repo.) I hope this is a short term (order of weeks) hack. -A -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing
[gentoo-dev] News item for KDEPIM-4.7 stabilization
Hi everyone, we're about to stabilize KDEPIM-4.7 for the first time (last stable KDEPIM suite is 4.4.11.1). Below is a news item for that, which I'd like to get out in 48hours as long as there are no major problems. The news item can also be found (in possibly updated form) at http://dev.gentoo.org/~dilfridge/2011-12-06-kde473-kdepim.en.txt Please send your feedback and improvements! @KDE: please also help me doublecheck if the Display-If-Installed: kde- base/akonadi-4.5 is correct (basically I want to display the news item only if someone has kdepim-4.4 installed). --- Title: Stabilization of KDE 4.7.3 including KDEPIM Author: Andreas K. Huettel dilfri...@gentoo.org Content-Type: text/plain Posted: 2011-12-06 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: kde-base/akonadi-4.5 We are pleased to announce the upcoming stabilization of KDE 4.7.3. In general the upgrade of KDE from 4.6.5 to 4.7.2 should be unproblematic. However, if you are using the KDEPIM application suite (i.e., akregator, blogilo, kmail, knode, kontact, korganizer, and others) where the stable version so far was 4.4.11.1, please be aware of the following: The stable upgrade from KDEPIM 4.4.11.1 to KDEPIM 4.7.2 is a MAJOR upgrade with potential for major breakage. Therefore we will *try* to keep and support the old, so-far stable KDEPIM 4.4.11.1 as long as possible. If you *dont* want to upgrade your KDEPIM yet but keep the old version, please download the following file and add it into your /etc/portage/package.mask: http://dev.gentoo.org/~dilfridge/kdepim-4.7-mask If you decide to upgrade, please have a look at the upgrade guide first: http://wiki.gentoo.org/wiki/KDEPIM-4.7_upgrade -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] making the stable tree more up-to-date
Pawel, while I appreciate very much what you are doing, there is one obvious problem: usually, as a maintainer, one does not file a stablereq for a single arch, but for all stable arches of a package. Are the cited advances relevant for all stable arches, for the major ones, or only for one of them? I would like to avoid the situation that we all file stable requests like mad and end up with all-but-one swamped arch teams and a neverending list of open stabilization bugs waiting for the last arch. Cheers, Andreas Am Montag 21 November 2011, 09:41:07 schrieb Paweł Hajdan, Jr.: I think that with recent advancements in batch-stabilization we're able to process a much higher amount of stabilization bugs, and keep the bug queue low. It used to be longer than 100 bugs, but now it's closer to 20-30 bugs for which regressions or other problems have been detected. This allows us to do better testing of the stabilization candidates, but also I think we should start bringing even more updates to the stable tree. When doing stable testing I frequently notice bugs fixed in ~arch but not stabilized, so stable is frequently affected by problems that could be easily fixed by stabilizing a more recent version. I wrote a script, http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=blob;f=stabilization-candidates.py;hb=HEAD, that scans the tree for packages that could be easily stabilized (all deps stable, no bugs). I'm attaching a list of packages that are sitting in the tree for at least 6 months (180 days, way more than 30 days required for stabilization) and should be ready for stabilization. Please review the list, it's 800+ packages so I thought about asking for feedback before filing stabilization bugs (I plan to do that in stages of course). Paweł -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Lastrite: x11-themes/polyester
# Andreas K. Huettel dilfri...@gentoo.org (8 Nov 2011) # Dead project, and has started crashing KDE apps, see bug 388261 and # the comments on its homepage. Masked for lastriting x11-themes/polyester -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Rotating oversized ChangeLog files
Sounds good. So, we have a spec... and the portage team has two months to get it into emerge --changelog. :) For whoever is interested, I've just filed a portage feature request in bug 389611. https://bugs.gentoo.org/show_bug.cgi?id=389611 Please support rotated ChangeLog files in emerge --changelog -- Andreas K. Huettel (dilfridge) Gentoo Linux developer kde, sci, arm, tex
Re: [gentoo-dev] Rotating oversized ChangeLog files
On Donnerstag 03 November 2011 09:24:07 Ulrich Mueller wrote: On Thu, 3 Nov 2011, Andreas K Huettel wrote: The old entries file ChangeLog-2010 will be identical to the current ChangeLog file except for skipping at the start all entries added later than 31/12/2010. Just to make sure that I understand it: Does this imply that the old entries file will have a proper header? Yes. 774821 profiles/ChangeLog Maybe you could split this one on a yearly basis, to keep the chunks close to 100 kB? Makes sense, yes. (With the earliest splitting when the file exceeds 100k for the first time.) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Rotating oversized ChangeLog files
On Donnerstag 03 November 2011 10:16:53 Michael Haubenwallner wrote: Again for 'emerge --changelog': As we do have the $delay before breaking old period, usually with $delay=1 year: Should we also apply this $delay to the output of above command? If yes, what I can think of ATM is: * Do that first splitting in January 2012 (in less than 2 months). * Have PM search in the old ChangeLogs if necessary. The latter would also allow for completely emptying current ChangeLog each January by moving that to ChangeLog-$lastyear. Makes all perfect sense... however I suggest to agree on a general scheme and go ahead manually first if implementation and/or discussion of its details or planned features is lingering... As opposed to EAPI features, this here is one of the cases where availability of an implementation means I'm here and can do it quickly. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Rotating oversized ChangeLog files (was: Old changelogs / eclass dir)
On Donnerstag 03 November 2011 09:09:19 Michał Górny wrote: Maybe we should keep old changelogs in a separate directory to decrease ebuilddir pollution? Not sure about that. The new ChangeLog file will be identical to the current ChangeLog file except for being truncated at 1/1/2011. Maybe it'd be a good idea to add some kind of footer saying 'for further entries, please inquiry ChangeLog-2010 file'. Yes, makes sense and is easily done. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] ChangeLog in eclass dir (was: Old changelogs / eclass dir)
1) Why is there no ChangeLog in the eclass directory? In my personal opinion this is missing there, if only for historical reasons... Should we still start one? as there was only positive feedback to this suggestion, I'll create a ChangeLog file in the eclass directory during the next days. (Last chance to protest!) And done. :) huettel@pinacolada ~/Gentoo/gentoo-x86/eclass $ cvs commit /var/cvsroot/gentoo-x86/eclass/ChangeLog,v -- ChangeLog initial revision: 1.1 huettel@pinacolada ~/Gentoo/gentoo-x86/eclass $ -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Rotating oversized ChangeLog files
On Donnerstag 03 November 2011 11:59:55 Ulrich Mueller wrote: On Thu, 3 Nov 2011, Andreas K Huettel wrote: On Donnerstag 03 November 2011 10:16:53 Michael Haubenwallner wrote: As we do have the $delay before breaking old period, usually with $delay=1 year: Should we also apply this $delay to the output of above command? Makes all perfect sense... however I suggest to agree on a general scheme and go ahead manually first if implementation and/or discussion of its details or planned features is lingering... How about this: - Possible split points are only at the end of years. - Start at the end of the file and go backwards. - Split it whenever the piece after the split point is larger than $size. - Stop if the next split point is less than $delay ago. Reasonable values are 50 or 100 KiB for $size and 1 year for $delay, IMHO. Sounds good. So, we have a spec... and the portage team has two months to get it into emerge --changelog. :) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] ChangeLog in eclass dir (was: Old changelogs / eclass dir)
Dear all, 1) Why is there no ChangeLog in the eclass directory? In my personal opinion this is missing there, if only for historical reasons... Should we still start one? as there was only positive feedback to this suggestion, I'll create a ChangeLog file in the eclass directory during the next days. (Last chance to protest!) Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Rotating oversized ChangeLog files (was: Old changelogs / eclass dir)
Dear all, 2) I'd like to suggest that for changelogs that grow beyond a certain size (e.g. profiles/ChangeLog) the file is rotated similar to /var/log logfiles. I.e. the current file is renamed with a date extension and a new file is started. This has the benefit that the archived file is static and will never be retransmitted by rsync. to prevent that this becomes a victim of general ChangeLog bikeshedding (we must rotate at a logical point, how could it be automatized even if it is relevant for only a few files, then how do we prevent epmty files...) I suggest the following procedure: In a week's time I personally, manually, will rotate all ChangeLog files larger than 100k in the tree, by splitting them at 31/12/2010-1/1/2011. The old entries file will in each case be named ChangeLog-2010 in the same directory. (PMS: A package directory may contain other files or directories, whose purpose is not covered by this specification.) The old entries file ChangeLog-2010 will be identical to the current ChangeLog file except for skipping at the start all entries added later than 31/12/2010. The new ChangeLog file will be identical to the current ChangeLog file except for being truncated at 1/1/2011. I currently count 19 relevant files. If we keep the 100k limit and rotate yearly, this will be doable by hand in the foreseeable future and any attempt at automating is a complete waste of time. Opinions, flames, ...? Cheers, Andreas PS. 774821 profiles/ChangeLog 166798 sys-kernel/gentoo-sources/ChangeLog 145004 sys-devel/gcc/ChangeLog 141505 sys-libs/glibc/ChangeLog 141397 media-video/mplayer/ChangeLog 133790 kde-base/kdelibs/ChangeLog 133257 www-client/firefox/ChangeLog 131385 x11-base/xorg-server/ChangeLog 130355 x11-base/xorg-x11/ChangeLog 124531 www-client/opera/ChangeLog 123722 sys-fs/udev/ChangeLog 115914 www-servers/apache/ChangeLog 112672 dev-db/mysql/ChangeLog 110957 media-video/vlc/ChangeLog 107961 sys-apps/baselayout/ChangeLog 107492 sys-kernel/git-sources/ChangeLog 105182 sys-kernel/hardened-sources/ChangeLog 104646 www-client/chromium/ChangeLog 100383 sys-kernel/vanilla-sources/ChangeLog -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: ChangeLog in eclass dir (was: Old changelogs / eclass dir)
On Donnerstag 03 November 2011 01:42:44 Ryan Hill wrote: On Thu, 3 Nov 2011 01:11:46 +0100 Andreas K. Huettel dilfri...@gentoo.org wrote: Dear all, 1) Why is there no ChangeLog in the eclass directory? In my personal opinion this is missing there, if only for historical reasons... Should we still start one? as there was only positive feedback to this suggestion, I'll create a ChangeLog file in the eclass directory during the next days. (Last chance to protest!) First get echangelog to work in eclass/. It works fine once there is a ChangeLog. (It refuses to create a new one outside ebuild dirs though...) Proof: # ChangeLog for eclass # Copyright 1999-2011 Gentoo Foundation; Distributed under the GPL v2 # $Header: $ 03 Nov 2011; Andreas K. Huettel dilfri...@gentoo.org kde4-base.eclass: Added empty line -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/
[gentoo-dev] Old changelogs / eclass dir
Dear all, two small suggestions regarding ChangeLogs: 1) Why is there no ChangeLog in the eclass directory? In my personal opinion this is missing there, if only for historical reasons... Should we still start one? 2) I'd like to suggest that for changelogs that grow beyond a certain size (e.g. profiles/ChangeLog) the file is rotated similar to /var/log logfiles. I.e. the current file is renamed with a date extension and a new file is started. This has the benefit that the archived file is static and will never be retransmitted by rsync. Opinions? Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Old changelogs / eclass dir
As for codifying this, applying software to automate splitting changelogs in this manner could be initially challenging as I've seen a few Changelogs with really inconsistent style at the bottom of them. How many really long changelogs do we have now? Maybe we should just split them by hand. Below is the list of changelogs with more than 5 bytes. Let's just say, if we apply the rule for files bigger than 100k, we can easily do it by hand and will still see an improvement- also because the biggest files are updated most often (naturally). Later, the new files will have a regular format and can be processed automatically anyway. 774821 profiles/ChangeLog 166798 sys-kernel/gentoo-sources/ChangeLog 145004 sys-devel/gcc/ChangeLog 141505 sys-libs/glibc/ChangeLog 141397 media-video/mplayer/ChangeLog 133790 kde-base/kdelibs/ChangeLog 133257 www-client/firefox/ChangeLog 131385 x11-base/xorg-server/ChangeLog 130355 x11-base/xorg-x11/ChangeLog 124531 www-client/opera/ChangeLog 123722 sys-fs/udev/ChangeLog 115914 www-servers/apache/ChangeLog 112672 dev-db/mysql/ChangeLog 110957 media-video/vlc/ChangeLog 107961 sys-apps/baselayout/ChangeLog 107492 sys-kernel/git-sources/ChangeLog 105182 sys-kernel/hardened-sources/ChangeLog 104646 www-client/chromium/ChangeLog 100383 sys-kernel/vanilla-sources/ChangeLog 98137 dev-lang/python/ChangeLog 89614 net-misc/asterisk/ChangeLog 87568 dev-lang/php/ChangeLog 83915 profiles/prefix/ChangeLog 82583 net-fs/samba/ChangeLog 82558 dev-vcs/git/ChangeLog 81787 x11-libs/gtk+/ChangeLog 81691 dev-vcs/subversion/ChangeLog 79141 mail-client/evolution/ChangeLog 78127 dev-lang/ruby/ChangeLog 77357 app-emulation/wine/ChangeLog 75159 media-libs/xine-lib/ChangeLog 72634 dev-lang/perl/ChangeLog 72187 x11-drivers/ati-drivers/ChangeLog 72158 sys-devel/binutils/ChangeLog 70403 media-sound/amarok/ChangeLog 70003 mail-mta/postfix/ChangeLog 69801 net-proxy/squid/ChangeLog 68654 media-video/ffmpeg/ChangeLog 68183 sys-kernel/mm-sources/ChangeLog 67484 net-misc/openssh/ChangeLog 66380 media-gfx/imagemagick/ChangeLog 66175 media-tv/mythtv/ChangeLog 66055 www-servers/tomcat/ChangeLog 66045 mail-client/thunderbird/ChangeLog 66003 net-nds/openldap/ChangeLog 65668 net-print/cups/ChangeLog 65665 app-portage/gentoolkit/ChangeLog 65102 dev-libs/glib/ChangeLog 65073 x11-drivers/nvidia-drivers/ChangeLog 63758 app-crypt/gnupg/ChangeLog 62406 app-editors/emacs/ChangeLog 61747 dev-db/phpmyadmin/ChangeLog 61413 net-libs/xulrunner/ChangeLog 61141 dev-libs/openssl/ChangeLog 60826 media-libs/mesa/ChangeLog 60410 net-dns/bind/ChangeLog 60261 app-editors/emacs-vcs/ChangeLog 60117 gnome-extra/evolution-data-server/ChangeLog 59996 sys-apps/portage/ChangeLog 59966 app-antivirus/clamav/ChangeLog 57709 gnome-base/gnome/ChangeLog 57130 gnome-base/nautilus/ChangeLog 56294 dev-java/sun-jdk/ChangeLog 56243 net-news/liferea/ChangeLog 55883 www-servers/lighttpd/ChangeLog 55540 sys-kernel/tuxonice-sources/ChangeLog 54764 sys-kernel/mips-sources/ChangeLog 54436 sys-kernel/linux-headers/ChangeLog 54167 x11-wm/fluxbox/ChangeLog 54141 dev-db/sqlite/ChangeLog 54109 sys-apps/util-linux/ChangeLog 53644 www-client/epiphany/ChangeLog 53641 media-sound/alsa-driver/ChangeLog 53194 gnome-base/gnome-control-center/ChangeLog 52699 app-editors/vim/ChangeLog 52676 x11-libs/qt/ChangeLog 51030 app-editors/vim-core/ChangeLog 50058 sys-libs/db/ChangeLog 50042 www-client/firefox-bin/ChangeLog -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-sound/cdparanoia: ChangeLog cdparanoia-3.10.2-r3.ebuild
On Sonntag 23 Oktober 2011 15:34:30 Samuli Suominen wrote: If you only wanted to remove these files, you are free to use INSTALL_MASK locally instead of downgrading the quality of tree. Do you have any idea how much time me, and aballier spent to make cdparanoia's build system as clean as it is now? And then to coordinate them with upstream xiph.org? Then I see this... Not acceptable by any standards. I'd like to get my standards up to speed, so may I respectfully ask- what is, apart from link time, the Gentoo-user-visible difference between * removing the .a files in the ebuild * and not building them in the first place? (A clean build system is of course desirable, and it's great that you have been helping upstream with that. I just dont understand how this affects the quality of the tree, compared to the quality of upstream sources.) TIA, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Lastrite: media-gfx/pngcrush
On Dienstag 11 Oktober 2011 20:23:13 Markos Chandras wrote: On 10/11/11 18:34, Rich Freeman wrote: On Tue, Oct 11, 2011 at 12:52 PM, Markos Chandras hwoar...@gentoo.org wrote: I understand your points but given the fact that we have no active QA team to pick up the mess whenever needed (Diego can't do eveyrything on his own) I will keep doing what I think it is best for Gentoo. If you or others don't like that please take this to devrel, to QA, to the president or to master Yoda. Before you(not your in particular) do that though, make sure you double checked that I indeed violated the official policy. Now it's getting slightly ridiculous. We don't have an active QA team anymore because some people thought it detrimental that they even tried to enforce rules (which we gave ourselves, just as a reminder). Taking the resulting vacuum as a reason to just keep ignoring rules (which, by the way, every new recruit has to learn) is somehow taking the argument full circle. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] zlib breakage
It's a mess right now and it just doesn't look right. The bug that deals with it was locked from public view: https://bugs.gentoo.org/show_bug.cgi?id=383179 Is there any good reason why this bug is dev-only? Going over the contents I dont see any. (And we've been bickering in far worse ways on public bugs.) snip We will not hide problems We will keep our bug report database open for public view at all times; reports that users file online will immediately become visible to others. Exceptions are made when we receive security-related or developer relations information with the request not to publicize before a certain deadline. /snip http://www.gentoo.org/main/en/contract.xml -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] zlib breakage
On Freitag 23 September 2011 23:54:09 Markos Chandras wrote: Why are you discussing this in the -dev ML since there is already an open bug about this? This is clearly a problem(if any) with the zlib packages + maintainer. We ( as individual devs ) can't do much. If you want to push this further, I'd suggest you to CC qa@ on the bug or contact them directly. Because he cannot do this; the bug is dev-only now and Mike un-cc'ed him after setting the group restriction. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] git-2: a bunch of patches to review
Am Donnerstag 22 September 2011, 13:27:47 schrieb Michał Górny: The style change was approved by Donnie already. You mean that Donnie agreed with the style change. It's not up to any individual developer to approve such a change for the entire tree. What kind of 'entire tree'? It is just a single eclass, and its maintainer approves coding style change. Where do you see a problem with that? As Scarabeus wrote 99% of the eclass it's probably not obvious to everyone that Donnie is listed as its maintainer. -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] Gentoostats, SoC 2011
Am Mittwoch 24 August 2011, 12:48:35 schrieb Patrick Lauer: If you sneakily add something to cron.daily by default you can get pretty nice coverage. But I guess anyone trying that in Gentooland will meet some rather unpleasant resistance :) Of course, we could place it in some blatantly obvious way into a default configuration, together with a big fat message what it does and how to quickly disable it. We'd get better coverage in an opt-out system than in an opt-in system. (First idea- package is pulled in by a default-on useflag and installs itself into cron.daily. BEFORE it runs the first time it outputs said message and asks for permission to proceed (which cannot be done in the cron job obviously but we'd find a way).) -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] Gentoostats, SoC 2011
Hi Vikram, there is one important aspect of your program that really needs to be documented (and comments in the code are not enough): What data exactly is the client sending to the server?! What you need is basically an easy-to-find file / web page / ... where this is explained concise and in simple words. As long as that does not exist, your program will not find much acceptance. Apart from that, I like the entire project, and am curious about its results. Best, Andreas Am Montag 22 August 2011, 23:20:30 schrieb Vikraman: Hi all, Gentoostats[0] is a GSoC 2011 project to collect package statistics from gentoo machines. Please check it out. Bug reports and feature suggestions are welcome. To submit your stats, use the app-portage/gentoostats ebuild from betagarden overlay[1]. [0] https://soc.dev.gentoo.org/gentoostats/ [1] https://soc.dev.gentoo.org/gentoostats/about -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/
[gentoo-dev] Last rites: net-libs/libfwbuilder
# Andreas K. Hüttel dilfri...@gentoo.org (21 Aug 2011) # Starting with version 4.2, net-libs/libfwbuilder is integrated # into net-firewall/fwbuilder (its only reverse dep). Mask # libfwbuilder and the old fwbuilder version for removal. net-libs/libfwbuilder =net-firewall/fwbuilder-3.0.7 -- Andreas K. Huettel (dilfridge) Gentoo Linux developer kde, sci, arm, tex
Re: [gentoo-dev] gcc: dropping cld workaround
so... is this something where I should suddenly in a moment of clarity shout ah, that cld workaround ?! On Samstag 20 August 2011 20:03:04 Mike Frysinger wrote: we added the cld workaround to gcc-4.3.0+ in early 2008 until packages sorted themselves out. i think they have at this point. in terms of kernels, we're talking about ones around 2.6.25 and earlier. i'll be dropping it from our gcc builds, so now is the time to make noise if this affects you. -mike -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] [RFC] gentoo-x86 migration to repo-per-package
Am Samstag 06 August 2011, 23:57:13 schrieb Fabio Erculiani: I really love the idea of being able to atomically push updates across multiple CPVs. This is also what KDE, GNOME, and many other teams are waiting for. Having multiple repos means no atomicity and at this point, I would rather prefer CVS (omg!). Exactly. This is why I would also vote for a single tree and single modern vcs. In addition, I would like to propose that we keep the number of required home-made addons and scripts to a minimum. As long as we have straight cvs or straight git, every tool developed for these systems just works. As soon as we start assembling our tree with a huge self-made infrastructure, we're all confined to our own tools for every operation that steps over the newly created repository limits. -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] The Python problem
Am Mittwoch, 29. Juni 2011, 06:34:52 schrieb Michał Górny: As I said it already, we could start doing things simpler in the current python.eclass and maybe that would attract some devs to help out with it, as they find it more comfortable to work with. I think it would be better to simply start from scratch with a clean python-2.eclass. Instead of adding new features and another lot of conditionals for EAPI=4, just make that code a part of new eclass. Ack. The cleanest way would definitely be to start from scratch, and provide a long transition period. Please please make things similar compared to the other language eclasses, though... -- Andreas K. Huettel (dilfridge) Gentoo Linux developer kde, sci, arm, tex
Re: [gentoo-dev] RFC Remove USE=fortran in default profile
Am Mittwoch 22 Juni 2011, 16:35:07 schrieb Matthew Summers: Hey Justin, One thing to note is that a few various python modules, like numpy, really benefit from fortran. While many people using numpy are scientists, many are not and further there are various modules that depend on numpy that non-science folks use. I, for one, care little about where that flag is set, since I have manually set that USE for years now in make.conf. I am simply hoping to make you aware of the fact that there are potential cases that could be easily overlooked. Thanks! Matt ... and there are also typical end user software packages like digikam and kipi-plugins for photo processing, which rely e.g on opencv for face recognition, red eye removal, ... -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Formal Adopt a Package Program
Create a formal Gentoo project with its own herd and alias. Whenever a packages has a proxy-maintainer, instead of having 2 maintainer entries (one for the user, one for the dev), have the users contact information, and put the package in the herd associated with the project. (Say proxy-maintained with the alias proxy-maintained@g.o.) From there, users that want to have something committed can use the alias, and any dev that's helping with that project can review it quickly and commit it for them. Good idea! I do realize there is a small amount of overlap with the already existent Sunrise package, however, given that usually Sunrise serves as a home for m-w packages, I think this can help fill the gap left for the m-n packages. (And help provide a logical transition from Sunrise to Portage). Given the rather, err, stringent (for lack of a better word) quality control on sunrise, whoever has been committing to sunrise regularly should have no problem in getting his ebuilds into this program as well. It's just an additional way to graduate... :) Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Packages up for grabs
Hi Anthoine gang, I'm kind of interested in fakeroot and fakechroot, so I can proxy you. Talk to me on IRC sometime... (but I'll be away 26/6 - 24/7). Cheers, Andreas Am Montag 13 Juni 2011, 00:46:31 schrieb Anthoine Bourgeois: 2011/6/12 Michal Januszewski sp...@gentoo.org Hi, I have a number of packages in which I have lost interest and which I no longer want to maintain: (...) sys-apps/fakechroot sys-apps/fakeroot-ng (...) I will reassign them to maintainer-needed in about a week. If you want to take them, please just add yourself to metadata.xml directly. Hi, I'd like to help on some packages above. I use fakeroot and fakechroot daily and memtest are very useful to me. I'm not a gentoo developer but I play with ebuild on my overlay since few month : http://git.overlays.gentoo.org/gitweb/?p=user/aluco.git;a=summary I think my main contribution in my overlay is the phoronix-test-suite. I'd like to go forward and I wish to help the sunrise projet (if those packages fall on the overlay). I'd like to make sure if my ebuilds follow gentoo's standards and collaborate closer to the developers. I'm not sure I'm aware of all gentoo's procedures, do you think all of this will be faisable and am I on the right way? Thanks, Anthoine Thanks, -- Michal Januszewski http://people.gentoo.org/spock -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Last rites: net-wireless/kbluetooth
Am Sonntag 12 Juni 2011, 21:34:54 schrieb Francisco Blas Izquierdo Riera (klondike): El 03/06/11 23:48, Andreas K. Huettel escribió: # Andreas K. Huettel dilfri...@gentoo.org (3 Jun 2011) # Requires KDE 4.4, which is not in the portage tree anymore. # Please unmerge before upgrading KDE, and emerge afterwards # net-wireless/bluedevil for bluetooth support in KDE 4.6. # Masked for removal in 15 days net-wireless/kbluetoot Andreas, maybe increase the removal to 30 days? Desktop users tend to be less aware of these things and take longer to upgrade. Well, the question is whether that helps... :) with an updated portage tree, you cannot install KDE 4.4 (and thereby kbluetooth) anymore. So this would be for the use-case alone when someone still has KDE 4.4 installd and wants to add bluetooth support without upgrading. Anyway, why not... I'll just leave it in for a while longer. Cheers, Andreas -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/
