Re: [gentoo-dev] Sets in the tree
On 15 August 2013 00:42, Patrick Lauer patr...@gentoo.org wrote: On 08/15/2013 04:21 AM, Markos Chandras wrote: On 14 August 2013 21:17, Ulrich Mueller u...@gentoo.org wrote: On Wed, 14 Aug 2013, hasufell wrote: And their lack of time (to be polite) should not block general progress in gentoo. Perhaps these basic notions of how Gentoo development works You certainly are not an authority when it comes to that question... Well no exactly Stop it. Now. gentoo-dev is a list for technical topics, so please take your personal quarrels elsewhere. Ulrich Last warning for both hasufell and Ciaran. Keep the discussion on acceptable technical and polite levels or go away I'm quite surprised that you attack hasufell now for his valid opinion that PMS is not well maintained and does not reflect reality adequately. I you want to complain about something, do it properly by stating your opinion in a professional manner and respect the other participants. And I really do not appreciate this weirdness of LAST WARNING!!11 ... it doesn't work on 6-year-olds, so don't expect it to work on a group of strongly individualist nerds. Makes me want to tell you Last warning! Don't warn people again, OR ELSE! just to see what happens. If you can't behave, this is not my problem. Learn to behave properly in the public mailing list or don't be in it. You might be surprised but warnings work. And if they don't, there are others ways to keep the mailing list clean. And to be fair, I don't see a group of strongly individualist nerds here. I see a group of respectful developers trying to have a discussion and then there are 2-3 of others devs trying to cause the usual mess in the mailing list. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Sets in the tree
El jue, 15-08-2013 a las 07:42 +0800, Patrick Lauer escribió: On 08/15/2013 04:21 AM, Markos Chandras wrote: On 14 August 2013 21:17, Ulrich Mueller u...@gentoo.org wrote: On Wed, 14 Aug 2013, hasufell wrote: And their lack of time (to be polite) should not block general progress in gentoo. Perhaps these basic notions of how Gentoo development works You certainly are not an authority when it comes to that question... Well no exactly Stop it. Now. gentoo-dev is a list for technical topics, so please take your personal quarrels elsewhere. Ulrich Last warning for both hasufell and Ciaran. Keep the discussion on acceptable technical and polite levels or go away I'm quite surprised that you attack hasufell now for his valid opinion that PMS is not well maintained and does not reflect reality adequately. Wouldn't be much easy to try to get sets support approved for the next eapi? (eapi6 I think). Once we get the usual problems, we can complain but, who knows, maybe (as it's already implemented in a PM) it doesn't take so long to get approved (or maybe I am being too optimistic :( ) (not well maintained: simple patches take months to get applied, and even then often need council interference to be applied. Does not reflect reality: Multiple cases like mandating bash 3.2 that we don't even have in tree anymore, so no compliance testing possible. Maybe a quick new eapi bump (5.1?) including this and other small changes that are quick to implement could help :/ Not documenting package.mask as a directory for EAPI0 even when that feature existed in portage before the initial release of PMS. Etc. etc.) I wasn't aware of this issue at all, does it have a bug report tracking it? (for knowing its status, why it is being ignored or bringing the problem to the council if needed) Please take care that not all people are aware of the PMS related issues :) Thanks!
Re: [gentoo-dev] Sets in the tree
El mié, 14-08-2013 a las 23:53 +0800, Patrick Lauer escribió: [...] Well, it should reflect reality. PMS is still broken as much as it does not reflect the state of portage before PMS was written, and we've had to patch it up a few times to make it coherent, plus it is still lacking half the things that would make it useful as a standard. Your academic interpretation of standard as a platonic ideal disconnected from reality serves no purpose. On this topic I agree with Patrick: I don't fully understand why things (like in_iuse from eutils.eclass) are missing from PMS. If that applies to more features that were forgotten when writing PMS, we have a problem :(
Re: [gentoo-dev] Sets in the tree
El mié, 14-08-2013 a las 15:17 +0100, Ciaran McCreesh escribió: On Wed, 14 Aug 2013 17:07:32 +0400 Sergey Popov pinkb...@gentoo.org wrote: I am all for the standarts, but as we did not brought sets to PMS yet(when we updated it for EAPI changes), my question is: 'why?'. It is one of the long-standing feature of quite experimental 2.2_alpha branch, that should finally come to release(Thanks to portage team, by the way :-)). Why it was not added as a part of the PMS? Some implementation flaws? Or maybe, architecture problems? Because the Portage format involves executing arbitrary Python code that can depend in arbitrary ways upon undocumented Portage internals that can change between versions. Ah, looks like I was too optimistic and we are (again) with the usual blocking (and blocker) issues -_- (PMS refusing to include something because of lack of documentation :S)
Re: [gentoo-dev] Sets in the tree
On Thu, 15 Aug 2013 10:10:02 +0200 Pacho Ramos pa...@gentoo.org wrote: El mié, 14-08-2013 a las 23:53 +0800, Patrick Lauer escribió: [...] Well, it should reflect reality. PMS is still broken as much as it does not reflect the state of portage before PMS was written, and we've had to patch it up a few times to make it coherent, plus it is still lacking half the things that would make it useful as a standard. Your academic interpretation of standard as a platonic ideal disconnected from reality serves no purpose. On this topic I agree with Patrick: I don't fully understand why things (like in_iuse from eutils.eclass) are missing from PMS. Why do things that can be in an eclass need to be in the PMS? Or more specifically, why would you like to see in_iuse in the PMS? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Sets in the tree
On Thu, 15 Aug 2013, Pacho Ramos wrote: I don't fully understand why things (like in_iuse from eutils.eclass) are missing from PMS. How should this feature have made it into PMS by now? AFAICS, you've first proposed it in the following posting, two days after EAPI 5 was approved: http://www.gossamer-threads.com/lists/gentoo/dev/260662 It's on the list of features for EAPI 6, so it will be included if the council approves it. Also it would certainly help if you would attach a wording for the specification to bug 449862. If that applies to more features that were forgotten when writing PMS, we have a problem :( Sorry, but the PMS team's crystal ball is broken. So we cannot include things before someone proposes them. ;) Ulrich
Re: [gentoo-dev] Sets in the tree
On Thu, Aug 15, 2013 at 4:10 AM, Pacho Ramos pa...@gentoo.org wrote: El mié, 14-08-2013 a las 23:53 +0800, Patrick Lauer escribió: [...] Well, it should reflect reality. PMS is still broken as much as it does not reflect the state of portage before PMS was written, and we've had to patch it up a few times to make it coherent, plus it is still lacking half the things that would make it useful as a standard. Your academic interpretation of standard as a platonic ideal disconnected from reality serves no purpose. On this topic I agree with Patrick: I don't fully understand why things (like in_iuse from eutils.eclass) are missing from PMS. If that applies to more features that were forgotten when writing PMS, we have a problem :( Just picking a random spot to reply in this mess, but it could apply to many other posts. If somebody proposes a change and the PMS team is holding it up for an inappropriate reason, escalate it - don't stew over it and blow up on the mailing lists twice a year. However, from what I've seen in the past most problems with PMS are like most problems with Gentoo - they're things that people wish were different but which nobody bothers to fix. Nobody is getting paid to make PMS better, just as nobody is being paid to work on the dozen security GLEPs that came up 47 posts ago. When things don't happen in Gentoo 9 times out of 10 it is because nobody has put in the time to make them happen. In the 1 time out of 10 where some kind of bickering actually holds things up, that is the time to bring issues to the project lead or to the Council to get resolved. I won't speak for anybody but from my observations in the past in most cases where somebody rushes to defend portage against the evil forces of PMS we have a 75 post flamewar and then one of the portage maintainers steps up and basically explains that there is nothing wrong and things with PMS are going fine. I'm all for the Council being more proactive, but that doesn't mean asking infra to BCC us on every email sent through gentoo so that we can find and act on every one-off issue that two devs have a disagreement on. If there is a problem bring it up. We call for agenda items every month, and we already agreed that if issues are more critical that we would act on them in-between meetings if appropriate (just file a bug and/or ping the alias). However, if your request is going to be that we scrap PMS, honestly, I wouldn't waste your (and our) time - mine is only one vote but frankly I don't see it happening. By all means complain if the PMS team unfairly rejects a proposal, or make suggestions as to ways to improve how PMS is run. However, your suggested improvements need to come along with people willing to implement them. You can't just say I wish this team that I have no interest in helping out worked differently unless you can persuade them to go along with it. Oh, and as far as devrel leads treating people like children go - my sense is that most devs would like to see devrel taking a more active lead in dealing with nonsense on the lists, not less. If things get out of hand they can be dealt with, but frankly the main thing that seems to be out of hand here are personal attacks on the list. After that huge thread on -core a few months ago I think that we need to have more direct intervention when inappropriate behavior on the lists takes place - otherwise we just have an atmosphere where everybody feels like they have PTS. A wrist slap on the lists is better than rage-quit or bans. Rich
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-java/httpunit: httpunit-1.6.2-r3.ebuild ChangeLog
On Thu, 15 Aug 2013 03:28:49 + (UTC)
Patrick Lauer (patrick) patr...@gentoo.org wrote:
patrick 13/08/15 03:28:49
Modified: httpunit-1.6.2-r3.ebuild ChangeLog
Log:
Fix src_unpack/src_prepare
(Portage version: 2.2.0/cvs/Linux x86_64, unsigned Manifest commit)
Revision ChangesPath
1.4 dev-java/httpunit/httpunit-1.6.2-r3.ebuild
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-java/httpunit/httpunit-1.6.2-r3.ebuild?rev=1.4view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-java/httpunit/httpunit-1.6.2-r3.ebuild?rev=1.4content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-java/httpunit/httpunit-1.6.2-r3.ebuild?r1=1.3r2=1.4
Index: httpunit-1.6.2-r3.ebuild
===
RCS
file: /var/cvsroot/gentoo-x86/dev-java/httpunit/httpunit-1.6.2-r3.ebuild,v
retrieving revision 1.3 retrieving revision 1.4
diff -u -r1.3 -r1.4
--- httpunit-1.6.2-r3.ebuild 27 Nov 2012 19:50:16 -
1.3 +++ httpunit-1.6.2-r3.ebuild 15 Aug 2013 03:28:48
- 1.4 @@ -1,6 +1,6 @@
-# Copyright 1999-2012 Gentoo Foundation
+# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-#
$Header: /var/cvsroot/gentoo-x86/dev-java/httpunit/httpunit-1.6.2-r3.ebuild,v
1.3 2012/11/27 19:50:16 sera Exp $ +#
$Header: /var/cvsroot/gentoo-x86/dev-java/httpunit/httpunit-1.6.2-r3.ebuild,v
1.4 2013/08/15 03:28:48 patrick Exp $ EAPI=2 inherit java-pkg-2
java-ant-2 @@ -28,8 +28,7 @@
DEPEND==virtual/jdk-1.5
${CDEPEND}
-src_unpack() {
- unpack ${A}
+src_prepare() {
find ${S} -name *.jar | xargs rm -v
cd ${S}
epatch ${FILESDIR}/rhino-fix-${PV}.diff
Reverted. Please check eclasses when you replace things like this;
because of that, this change would cause a difference in behavior.
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
Re: [gentoo-dev] Sets in the tree
On 08/15/2013 03:15 PM, Markos Chandras wrote: On 15 August 2013 00:42, Patrick Lauer patr...@gentoo.org wrote: On 08/15/2013 04:21 AM, Markos Chandras wrote: On 14 August 2013 21:17, Ulrich Mueller u...@gentoo.org wrote: On Wed, 14 Aug 2013, hasufell wrote: And their lack of time (to be polite) should not block general progress in gentoo. Perhaps these basic notions of how Gentoo development works You certainly are not an authority when it comes to that question... Well no exactly Stop it. Now. gentoo-dev is a list for technical topics, so please take your personal quarrels elsewhere. Ulrich Last warning for both hasufell and Ciaran. Keep the discussion on acceptable technical and polite levels or go away I'm quite surprised that you attack hasufell now for his valid opinion that PMS is not well maintained and does not reflect reality adequately. I you want to complain about something, do it properly by stating your opinion in a professional manner and respect the other participants. Stop violently agreeing with me!
Re: [gentoo-dev] Sets in the tree
Dnia 2013-08-15, o godz. 11:09:50 Tom Wijsman tom...@gentoo.org napisał(a): On Thu, 15 Aug 2013 10:10:02 +0200 Pacho Ramos pa...@gentoo.org wrote: El mié, 14-08-2013 a las 23:53 +0800, Patrick Lauer escribió: [...] Well, it should reflect reality. PMS is still broken as much as it does not reflect the state of portage before PMS was written, and we've had to patch it up a few times to make it coherent, plus it is still lacking half the things that would make it useful as a standard. Your academic interpretation of standard as a platonic ideal disconnected from reality serves no purpose. On this topic I agree with Patrick: I don't fully understand why things (like in_iuse from eutils.eclass) are missing from PMS. Why do things that can be in an eclass need to be in the PMS? Or more specifically, why would you like to see in_iuse in the PMS? in_iuse() is a cheap hack that does not confirm to the PMS. The problem is that PMS provided us with no way to query incremental variables like $IUSE. It makes the value of such variables 'undefined'. Which, shortly saying, means something like 'you can't query it'. Therefore, in_iuse() is broken and unsupported and you will be damned for using it. The only reason I added it to eutils.eclass was because people did it in even a more broken way. It's mostly like 'we know it's broken, so better keep it confined'. What future EAPI could do is to provide a legitimate way of querying it. Not that I really agree with doing that but it's not my call how people mis-design eclasses, and that's out-of-topic here. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Sets in the tree
Dnia 2013-08-15, o godz. 11:10:31
Ulrich Mueller u...@gentoo.org napisał(a):
On Thu, 15 Aug 2013, Pacho Ramos wrote:
I don't fully understand why things (like in_iuse from
eutils.eclass) are missing from PMS.
How should this feature have made it into PMS by now? AFAICS, you've
first proposed it in the following posting, two days after EAPI 5 was
approved:
http://www.gossamer-threads.com/lists/gentoo/dev/260662
I don't know who's at fault here. I committed it due to some earlier
thread where Ciaran pointed out how querying ${IUSE} is invalid. And I
suspect that wasn't the first time when he replied to developers using
such hacks.
Why nobody bothered to fix it the first time it was noticed broken?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Sets in the tree
Dnia 2013-08-15, o godz. 10:04:47
Pacho Ramos pa...@gentoo.org napisał(a):
El jue, 15-08-2013 a las 07:42 +0800, Patrick Lauer escribió:
I'm quite surprised that you attack hasufell now for his valid opinion
that PMS is not well maintained and does not reflect reality adequately.
Wouldn't be much easy to try to get sets support approved for the next
eapi? (eapi6 I think). Once we get the usual problems, we can complain
but, who knows, maybe (as it's already implemented in a PM) it doesn't
take so long to get approved (or maybe I am being too optimistic :( )
But what for? So far there is a lot of noise but I don't think anybody
really decided what he wants from the PMS. Sets are wide
and dynamic feature in portage, and it can't go straight to PMS.
We need to choose a subset of sets to support, and then define it. But
what subset do people really want? Open a separate thread, preferably
on gentoo-pms, and start harvesting data. Crystal balls won't work
in Gentoo.
(not well maintained: simple patches take months to get applied, and
even then often need council interference to be applied. Does not
reflect reality: Multiple cases like mandating bash 3.2 that we don't
even have in tree anymore, so no compliance testing possible.
Maybe a quick new eapi bump (5.1?) including this and other small
changes that are quick to implement could help :/
Please not. We have enough mess with all the current EAPIs, sub-EAPIs
are only going to make it worse.
Also, please remember that adding bash-4 in a new EAPI is far from
a helpful solution. The main source of complex bash code are eclasses.
If you want bash-4 in the eclasses, you can't rely on it while
the eclass supports older EAPIs. So you end up using conditionals,
and I really prefer ${BASH_VERSINFO[@]} check for this over $EAPI
checks.
So, yes, get it for EAPI 6 and near EAPI 7 or 8 we may have first *new*
eclasses that could be able to be pure-bash4 (see python-r1 problems).
But EAPI 5.1 sounds like a tiny creep that isn't going to do much
except for giving us more work to support it.
Not
documenting package.mask as a directory for EAPI0 even when that feature
existed in portage before the initial release of PMS. Etc. etc.)
I wasn't aware of this issue at all, does it have a bug report tracking
it? (for knowing its status, why it is being ignored or bringing the
problem to the council if needed) Please take care that not all people
are aware of the PMS related issues :)
And when was it used in the ebuild tree? You shouldn't really expect
people to document hidden features of portage that weren't really used
at the time. And I still don't see a real reason to have those in gx86.
This sounds like a good way to make committing to profiles even messier
than it was.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
2013/8/14 heroxbd hero...@gentoo.org: Daniel Campbell li...@sporkbox.us writes: I'm not a developer but this project's existence would motivate me to get a compatible smartphone and test this new Gentoo version on it, assuming it's also capable of standard phone calls and texts, etc. This assumption certainly holds firm. It is firstly a phone and then a computer. My rooted Samsung Galaxy S2 is also ready to receive and to test this kind of Gentoo. Will be important the version of Android installed? -- Regards, Alex
Re: [gentoo-dev] Sets in the tree
On Thu, 15 Aug 2013 10:12:31 +0200 Pacho Ramos pa...@gentoo.org wrote: El mié, 14-08-2013 a las 15:17 +0100, Ciaran McCreesh escribió: On Wed, 14 Aug 2013 17:07:32 +0400 Sergey Popov pinkb...@gentoo.org wrote: I am all for the standarts, but as we did not brought sets to PMS yet(when we updated it for EAPI changes), my question is: 'why?'. It is one of the long-standing feature of quite experimental 2.2_alpha branch, that should finally come to release(Thanks to portage team, by the way :-)). Why it was not added as a part of the PMS? Some implementation flaws? Or maybe, architecture problems? Because the Portage format involves executing arbitrary Python code that can depend in arbitrary ways upon undocumented Portage internals that can change between versions. Ah, looks like I was too optimistic and we are (again) with the usual blocking (and blocker) issues -_- (PMS refusing to include something because of lack of documentation :S) That's a very selective misinterpretation of the facts. If you want to reduce it to a few simple words, try terrible format. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Sets in the tree
On Thu, 15 Aug 2013 10:04:47 +0200 Pacho Ramos pa...@gentoo.org wrote: Wouldn't be much easy to try to get sets support approved for the next eapi? (eapi6 I think). Once we get the usual problems, we can complain but, who knows, maybe (as it's already implemented in a PM) it doesn't take so long to get approved (or maybe I am being too optimistic :( ) Of course. All you have to do is propose a sane format for them -- this has been the blocker the last few times this issue has come up. The big question the Council will probably want answered is whether or not sets are allowed in package.mask and the like. If the answer is no, you're removing a large part of their usefulness. If the answer is yes, how are you controlling backwards compatibility? (not well maintained: simple patches take months to get applied, and even then often need council interference to be applied. Does not reflect reality: Multiple cases like mandating bash 3.2 that we don't even have in tree anymore, so no compliance testing possible. Maybe a quick new eapi bump (5.1?) including this and other small changes that are quick to implement could help :/ People seem to be opposed to lots of EAPIs or too many new EAPIs. There's a fairly long delay between them because that's what developers have been asking for. Not documenting package.mask as a directory for EAPI0 even when that feature existed in portage before the initial release of PMS. Etc. etc.) I wasn't aware of this issue at all, does it have a bug report tracking it? (for knowing its status, why it is being ignored or bringing the problem to the council if needed) Please take care that not all people are aware of the PMS related issues :) It's not an issue at all. PMS followed the Portage documentation at the time (and unless it's changed recently, what the Portage documentation still says). It's just that Portage reuses code in such a way that there are accidental undocumented features every now and again, and this is one of them that someone spotted and started using. Directories for package.mask were introduced as a user config feature, not a tree feature (read the commit message that added the feature to Portage). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Sets in the tree
On Wednesday 14 of August 2013 21:42:35 Michael Palimaka wrote:
| Now that portage-2.2 is in ~arch, we should now be able to add sets to
| the tree.
|
| How should we go about doing this? In some overlays, the repository root
| has sets/{foo,bar,etc} and sets.conf which might look like this:
|
| [gentoo sets]
| class = portage.sets.files.StaticFileSet
| multiset = true
| directory = ${repository:gentoo}/sets/
| world-candidate = True
|
| It might be useful to have a standard header for each set:
|
| # Maintainer: f...@example.com
| # Description: The complete set of all Foo packages
|
| Should everyone be free to add sets at will, or should each addition be
| discussed first, similar to adding new global USE flags?
|
| Anything else to consider?
Discussion about current portage sets was sure to get hot.
I strongly disagree with adding current portage sets to gentoo-x86.
Not because they're not PMS compliant (which is a reason alone) but because
they can be
considered interim solution.
Please refer to Zac's email on why portage-2.2_ was kept masked for that long.
For live rebuilds, there's already proposal:
https://bugs.gentoo.org/show_bug.cgi?id=272488
For proper 'metapackage' replacement (USE flags support, etc), actually there's
also some
idea (Zac's 'PROPERTIES=set'):
https://bugs.gentoo.org/show_bug.cgi?id=182028
In my opinion, we need to _have_ proper sets before we include them in
gentoo-x86.
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] systemd team consensus?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/11/2013 04:30 PM, Michał Górny wrote: Dnia 2013-08-11, o godz. 20:59:01 Tom Wijsman tom...@gentoo.org napisał(a): On Sun, 11 Aug 2013 13:29:16 -0500 William Hubbs willi...@gentoo.org wrote: I am splitting this to a separate thread, because it could become a long thread pretty easily. On Sun, Aug 11, 2013 at 07:14:00AM -0400, Rich Freeman wrote: On Sun, Aug 11, 2013 at 3:51 AM, Samuli Suominen ssuomi...@gentoo.org wrote: I've been considering packaging systemd in sys-fs/udev with USE=systemd and use of 'if' and 'else' plus creating virtual/systemd for proper / installation and some other minor, but bad design choices done in the systemd packaging What is the consensus of the systemd team regarding those choices? Would it make more sense to just fix the packaging rather than forking it? I'm not sure what all the issues are, or how widespread the disagreement is. I am a member of the systemd team, and I know what needs to be done. I have offered patches multiple times the last few months to fix the packaging, only to have them refused, Why were they refused? Because it introduced QA violations and unnecessary backwards migration for our users. I'm not really into moving files every second month, and so far the main argument was 'I have the citation here'. even though I have presented, multiple times, strong recommendations from systemd upstream that I am correct, as well as making it clear that I would take responsibility for breakages the change would cause. Originally, we did install systemd correctly, but that was changed some time back, Why was it changed? Because systemd executables linked to a number of libraries in /usr and moving those libraries to rootfs is not really an option. systemd officially doesn't support running with separate /usr not mounted at boot, and there's no point to pollute rootfs with a dozen of late-use libraries. before I joined the team. All Samuli and I have asked is that the change we made that puts everything in /usr be undone. Why is the change refused to be undone? Why should it be undone? Changing things back to a broken state is called a regression. If upstream doesn't support something it's not a regression. This upstream removes features all the time in the name of progress. Either get on the train or get run over by it. If /usr isn't mounted at boot then systemd team doesn't what your system to boot, so either don't run systemd or catch up with the rest of the world and learn what an initramfs is. - -Zero You may ask why I have offered patches instead of just fixing the ebuild since I am a team member. That is because even team members aren't allowed to touch bugs assigned to syst...@gentoo.org [1], Well, if there are conflicts within a team then I can agree that no member is allowed to touch the bug without a collaborative decision; but from what it appears this bug has been handed in a way that one member appears to take all decisions and the other member has nothing to say. In particular, comments 5 and 11 change the state of the bug without giving any reasoning about why that change in state was made; this is unacceptable, it gives us no reason to believe the state change. For what reason did these specific state changes happen to this bug? Because I am *really* tired of replying to the same request over and over again. WilliamH is continuously bombarding me with the same request on mail, IRC, bugzilla and mailing lists. And almost every time he pretends that I hadn't given him any arguments. my personal efforts to advocate for this specific change got me this comment as well [2]. This bug, and others like it, would never have come up if we were installing systemd the way upstream recommends. Why was the / - /usr change so necessary that it causes bugs like this? Installation in a different prefix doesn't *cause* bugs. In the worst case, it triggers them. Bug was reported upstream and fixed. Upstream didn't doubt this is their fault. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSDa7YAAoJEKXdFCfdEflKVjAQAKcSbuo6aG4zk83tyOE80t80 woin3mxHIuN8x7smp7/qa8mXEeTHMnnlROIr8VbZDwz3S9e2ewfS34MM9R7ZrjLX VKFNGNfcTmwdqREIpuqthq309DP0NUjf3j3GnzQvyukVjbmshoZbd6pvVwxFfQJq OiGmL9e2v2IUnjrZvnytMIKHvdPCrYjhvRKu8afUUPgNAbd6PasO8jM0Hwo/n46V egOt6KpAnC5dS35mKWp32NKdKMQm4eMuwWlbRXWolX/9RheJnw9cKYPkqE0JiRPR 17SKq8NBXnuTaJ++MbOh5JTLr8BOaBaxo0I8kjnsjDIbR84/wEkomCXv9YK5EO35 f4Pz3iMxbXVW4LrKHRRikD7IYCaekPnZz0adISPRqdrfJbnY7WYIt2CDPD+dolLc HEyo2+11hq8XrbmYB96dObF4jmW4fSV5NUBsP3d0RZyHpD8snGy3XgVJQWmXJ+LO CGq4WQk6ZMnNKb8jjNn5e79aC5YUL9Z9u+sDHz1ku8LQZaNiqRAN10QPIENcLH7S 6Ox5j5j7XtuPFKFe8rd+uFCyoqbq0zXpiPg39k/lxvd+RkGSJuVuSCD0/9aHCCI5 tyFLUiAk0pNQVTiXJbBbGTrTiAj4YC5MRreyVCC8j0o4FnEyHi692ozH3rchRQwM ou3LocIAOfycJm2nd1O2 =WA4U -END PGP
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/13/2013 01:21 AM, heroxbd wrote: Dear Fellows, Canonical is raising money by pushing their concept of Ubuntu for Android[1][2]. The idea is to put GNU environment (esp. Ubuntu userland) in parallel to Android to drive the external HDMI output with X11 protocal, so that desktop applications can run on the smartphone. The idea is cool, but not new. The idea is general to all android devices, while Canonical is binding the concept with its own new device. The project is developed underground by Canonical, so far nothing, not to say repository, is available except advertisements and the call for people to donate. As a natual consequence of the on-going Google Summer of Code project, Gentoo on Android[3], we can run native Gentoo on *all* the Android devices. Compiling out an Xorg and output to HDMI has no theoretical difficulty. Furthermore, sharing of graphic output with Android (instead of a separate HDMI output) can be explored with wayland x11[4]. I feel sorry to the behavior of Canonical. We, people from the Gentoo community, can show the general public what is the cooperative way to develop desktop/smartphone hybrid to benefit all. I would like to kick out a sub-project of Gentoo targeting smartphone and tablets. It would be nice to find out a solution based on Gentoo for desktop/smartphone hybrid *before* Canonical's release. Comments welcome. You know what I've done with this kind of thing already. I am at your disposal. If you want to publicly embarass canonical by releasing something awesome (either first or better) I can find the time to help. You know where to find me ;-) - -Zero Cheers, Benda 1. http://www.ubuntu.com/phone/ubuntu-for-android 2. http://www.indiegogo.com/projects/ubuntu-edge 3. http://www.awa.tohoku.ac.jp/~benda/projects/android.html 4. http://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSDbFuAAoJEKXdFCfdEflKiJMQAKlQtLQUBsWeCqI4YgYOsmX0 x9laSSQARdmfLC7Gt57ab4GBveZmwPAVjKi3KkIHZ3rUDrC2UehMYM/x8OMygLbJ tc8yec60KzG0AZ2GKcdvb7pZu1fM+gzw6qpFItqZ89YL/KN5ECdyNeTQz14QGuLY SzckuuDI8KO3WlFw8sQHic3gTd+r2+WSMNTvj1ln9M91sYjKy40Um6c6z/rpjJsm osHfKYKpiuGNEwAa/ptRwcxPmLWWyp0m38zl43vrBli+esHQYbS+zK1tX/xh4dxY Sj7CZc5DgUTfEmRL50U+gGx9wcQ5oMrVT7r4WK8I1O42tnoTQuRSqbNhYbrCHUCr ionaFAE4oKjJEOnjBwC9zA7p2OBJmtO9aXkQ5Wr51TtWN8xMC3wYCPCJgsy1Vo0H fjECKuoB1zNrhlYeDFAD13f5+2nYsxK3Y0qp1w4/KHsaZkqgg4acsF3hjGE8cMFR 3Z+72bebAi0QbgmFp1pY3BurptypvNuHpU+ErYEO8uI5+TwUrc4d6k6kvm353D/3 u6Xk5h74Xex/H4N33pytnYBxV6sNoMQiE3I3GCwe0y7LeZuWbe1Yz1PBjZULwW0u Uw8WAkPxPMHGDhB/78BLoO6Oc2JTjFA6ps5MKz/AaBjgv7u/HQ+tlPt9lHGhRCYm bmEznQB+UdpH9mI6DKTk =ZPJo -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH 2/3] Send output of ```emerge --version``` as User-Agent HTTP-header
On 08/14/2013 01:10 PM, Mark Kubacki wrote:
@@ -892,8 +893,13 @@ class binarytree(object):
# Don't use urlopen for https, since it doesn't
support
# certificate/hostname verification (bug
#469888).
if parsed_url.scheme not in ('https',):
+ trees = load_emerge_config().trees
+ user_agent = Gentoo
+getportageversion(self.settings[PORTDIR], None,
+
self.settings.profile_path, self.settings[CHOST],
+
trees[self.settings['EROOT']][vartree].dbapi)
Generally, your patches look reasonable. However, it's a waste to call
load_emerge_config() here, since the caller has certainly loaded the
config already. I guess we could have the caller pass the result of
getportageversion() as an argument to the binarytree.populate() method.
--
Thanks,
Zac
Re: [gentoo-portage-dev] [PATCH 3/3] Add CPU model name to output of getportageversion as fifth element
On 14-08-2013 22:10:40 +0200, Mark Kubacki wrote: From: W-Mark Kubacki wm...@hurrikane.de It will read like this: Portage 2.1.13.7 (default/linux/amd64/13.0, gcc-4.6.2, glibc-2.18, 3.9.0-rc8-mark-signed+ x86_64, Intel(R) Core(TM) i7-3770T CPU @ 2.50GHz) That new fifth element will be the CPU model name of the host running Portage. It is not the target architecture! FYI: % python3 Python 3.3.2 (default, Jul 24 2013, 11:14:02) [GCC 4.2.1 (Gentoo 4.2.1_p5666-r1, Apple Inc. build 5666) (dot 3)] on darwin Type help, copyright, credits or license for more information. import platform platform.release() '12.4.0' platform.machine() 'x86_64' platform.processor() 'i386' % python Python 3.2.3 (default, May 6 2013, 21:19:05) [GCC 4.7.2] on sunos5 Type help, copyright, credits or license for more information. import platform platform.release() '5.11' platform.machine() 'i86pc' platform.processor() 'i386' % python Python 3.3.2 (default, Jul 15 2013, 13:51:24) [GCC 4.7.2] on sunos5 Type help, copyright, credits or license for more information. import platform platform.release() '5.10' platform.machine() 'sun4u' platform.processor() 'sparc' % python Python 3.2.5 (default, Jul 15 2013, 11:37:08) [GCC 4.6.3] on linux2 Type help, copyright, credits or license for more information. import platform platform.release() '3.8.13-gentoo' platform.machine() 'x86_64' platform.processor() 'AMD Athlon(tm) 64 X2 Dual Core Processor 3800+' e.g. it seems to me only on Linux it gives fancy model output. Note that the first and second system were running a 64-bit Python as well as kernel. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-portage-dev] [PATCH 3/3] Add CPU model name to output of getportageversion as fifth element
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 (This holds for all patches) Please surround '+' with spaces[0]. Please ensure 79 width[1]. Please indent continuation lines properly[2]. [0] http://www.python.org/dev/peps/pep-0008/#id19 [1] http://www.python.org/dev/peps/pep-0008/#id13 [2] http://www.python.org/dev/peps/pep-0008/#id11, look at foo = long_function_name(). - -- Alexander alexan...@plaimi.net http://plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlIMtFAACgkQRtClrXBQc7UFFgD/dhU6OgwtRqF7fZ81QbC6l//V b+qNKFwGkiv8uyqzzUUBAK9Xc/w4iR40R61YXEySV+ybQ5GbrlvyjgHMzUCyobAs =nYLt -END PGP SIGNATURE-
