[gentoo-dev] Last rites: app-dicts/fantasdic and its ruby-gnome2 components
# Hans de Graaff gra...@gentoo.org (14 Aug 2013) # Last release in 2009. ruby18-only. Uses deprecated # ruby-gnome2 components that have been removed upstream # quite some time ago. No maintainer. # Also remove the deprecated ruby-gnome2 components. # Masked for removal in 30 days. app-dicts/fantasdic dev-ruby/ruby-gconf2 dev-ruby/ruby-gnomecanvas2 dev-ruby/ruby-libart2 dev-ruby/ruby-libglade2
Re: [gentoo-dev] Changes in libreoffice ebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz schrieb: On 14:37 Tue 13 Aug , Rich Freeman wrote: If a maintainer is holding something up for months by all means escalate it if you think it is justified, but if a maintainer just wants a few days to look into things, that isn't asking too much. If this were a security patch I might feel differently, or a stable regression (though as has been pointed out that shouldn't happen with reverse dep testing). Turns out we already wrote this down. See Touching other developers ebuilds: http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html Otherwise a soft limit of 2 to 4 weeks depending on the severity of the bug is an acceptable time frame before you go ahead and fix it yourself. This is only if the maintainer does not respond. In this case the maintainer made it clear that he didn't want those patches before they were submitted (not necessarily accepted) upstream. Best regards, Chí-Thanh Christopher Nguyễn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlILXMIACgkQ+gvH2voEPRDVGACeIHPGBf0/HZthRw8q5ID1VV/r Ga8An1NUeyG1MjfNfuMLLTF+5x8S7zzJ =/ud4 -END PGP SIGNATURE-
[gentoo-dev] Sets in the tree
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?
Re: [gentoo-dev] Sets in the tree
On Wed, Aug 14, 2013 at 7:42 AM, Michael Palimaka kensing...@gentoo.org wrote: Should everyone be free to add sets at will, or should each addition be discussed first, similar to adding new global USE flags? While I don't want to deter people from creating them, it probably wouldn't hurt to at least do a little bikeshedding here until we get comfortable with them. The issues aren't the same as USE flags, since adding a package to a set really has no impact to that package, so perhaps long-term discussion won't be necessary. Right now, however, it might be useful if only to get a sense for how they're being used, trade ideas, etc. Rich
Re: [gentoo-dev] Sets in the tree
14.08.2013 16:05, Rich Freeman пишет: On Wed, Aug 14, 2013 at 7:42 AM, Michael Palimaka kensing...@gentoo.org wrote: Right now, however, it might be useful if only to get a sense for how they're being used, trade ideas, etc. Well, we can use sets as replacement for metapackages(for example, qt-meta, leechcraft-meta). Well, as for leechcraft-meta, we can not simply replace metapackage with set, cause we have unstable USE-flag there. Any thoughts, leechcraft guys ;-)? -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Sets in the tree
Dnia 2013-08-14, o godz. 16:53:17 Sergey Popov pinkb...@gentoo.org napisał(a): 14.08.2013 16:05, Rich Freeman пишет: On Wed, Aug 14, 2013 at 7:42 AM, Michael Palimaka kensing...@gentoo.org wrote: Right now, however, it might be useful if only to get a sense for how they're being used, trade ideas, etc. Well, we can use sets as replacement for metapackages(for example, qt-meta, leechcraft-meta). Well, as for leechcraft-meta, we can not simply replace metapackage with set, cause we have unstable USE-flag there. No, we can't. Sets are portage-specific, the tree needs to follow PMS. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Sets in the tree
14.08.2013 17:02, Michał Górny пишет: Dnia 2013-08-14, o godz. 16:53:17 Sergey Popov pinkb...@gentoo.org napisał(a): 14.08.2013 16:05, Rich Freeman пишет: On Wed, Aug 14, 2013 at 7:42 AM, Michael Palimaka kensing...@gentoo.org wrote: Right now, however, it might be useful if only to get a sense for how they're being used, trade ideas, etc. Well, we can use sets as replacement for metapackages(for example, qt-meta, leechcraft-meta). Well, as for leechcraft-meta, we can not simply replace metapackage with set, cause we have unstable USE-flag there. No, we can't. Sets are portage-specific, the tree needs to follow PMS. 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? -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Sets in the tree
On 14/08/2013 23:02, Michał Górny wrote: No, we can't. Sets are portage-specific, the tree needs to follow PMS. Are you saying we can't use sets at all in the tree, or we can't use them to replace existing meta packages?
Re: [gentoo-dev] Re: Sets in the tree
Dnia 2013-08-14, o godz. 23:12:08 Michael Palimaka kensing...@gentoo.org napisał(a): On 14/08/2013 23:02, Michał Górny wrote: No, we can't. Sets are portage-specific, the tree needs to follow PMS. Are you saying we can't use sets at all in the tree, or we can't use them to replace existing meta packages? We can't use them to replace meta-packages. Otherwise, some of the users will lose ability to use those == regression. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: GLEP rap (Prefix/libc)
Dear Duncan, Duncan 1i5t5.dun...@cox.net writes: heroxbd posted on Mon, 12 Aug 2013 16:45:56 +0900 as excerpted: I have made a GLEP draft to standardize our recent effort on using our own libc from portage inside Prefix. At present only glibc on linux is supported. The rst text are included inline. Hi. I know nothing about prefix so won't attempt a comment on that. There were, however, just a few sentences that did not read very smoothly to me as a native English speaker, so here are some (relatively minor) suggested changes. Mostly, I'm simply adding a few thes and changing verb tense in a few spots, but there's a couple sentence splitting/ combining/rewording suggestions as well. Your linguistic suggestion is very much appreciated! I could never find out these natural rephasing by myself. I have applied all and tracked it with a git repo: http://git.heroxbd.z.tuna.tsinghua.edu.cn/?p=doc.git;a=commitdiff;h=aa51133 Motivation == ... RAP Literally means *Rap Ain't Prefix*. It serves as an acronym of *Prefix with libc* and is used interchangeably in this GLEP. Userspace of RAP is identical to Gentoo Linux, therefore more uniform and robust. RAP helps the ongoing effort of merging prefix and gx86 portage trees [#pgx86]_. THE userspace of RAP is ... (Insert The. I'll use ALL CAPS to denote most of my changes.) Applied. Kudos for the self-referential name, BTW! =:^) Thanks :D Thanks to the completely independent userspace, RAP can run on any kernel that glibc was ported to ... that glibc HAS BEEN ported to ... (not was) Applied. Rationale = Gentoo Linux, though often cited as *metadistribution*, originates from a Linux distribution. Linux is supported better in Gentoo. In Prefix community, the merging of prefix and gx86 portage trees [#pgx86]_ is brought back by non-Linux systems such as Mac OS X and Solaris. This paragraph read really rough for me, likely even more so as I'm not familiar enough with prefix to be sure what you're actually trying to say. However, this is my best guess (again, changes in ALL CAPS): ... originatED AS a Linux distribution, AND Linux REMAINS BEST supported. In THE Prefix community, ... (Put originated in past tense. Replace from with as. Merge the two sentences using and and reword slightly since the second is so closely related to the first. The prefix community...) Applied I /believe/ there's a further problem later in that sentence (... is brought back...), but I'm simply not familiar enough with prefix to have a clue what the intended meaning was or to suggest better wording. Hopefully someone else with better knowledge of the domain can suggest something... or confirm that it's fine as-is and I simply didn't know what I was talking about. non-Linux platforms like Mac OS X requires larger maintenance love than its Linux conterparts. The same is true for porting non-Linux back to gx86. The present effort merging Prefix overlay treats non-Linux and Linux equally, with the developers' time most spent on non-Linux. In the sense Linux is much easier to be merged, it is brought back by non-Linux ones. Backwards Compatibility === RAP cannot be mixed with present Prefix Linux implementation based on rpath if version of the host glibc is too low. ... cannot be mixed with THE present ... based on rpath if THE version of... Applied. Specification = Present Prefix Linux uses *rpath mechanism* [#rpath]_, namely encode a prefixed library path into RPATH and RUNPATH in dynamic section of ELF. PresentLY, Prefix Linux uses THE *rpath mechanism* [#rpath]_. Namely, encode a prefixed library path into RPATH and RUNPATH in THE dynamic... (PresentLY, comma. Add a couple thes. If you keep namely, split the sentence in half.) Another alternative (the way I'd likely word it myself) would change the tense to encoding and skip namely: Presently, Prefix Linux uses the *rpath mechanism* [#rpath]_, encoding a prefixed library path into RPATH and RUNPATH in the dynamic... Adopted the second. RAP, on the other hand, encode a prefixed dynamic loader into INTERP in the program header of ELF. RAP, on the other hand, ENCODES a prefixed dynamic loader into INTERP in the ELF program header. (Change the tense of encode, reorder to ELF program header and omit of.) Applied. RAP is different with present Prefix Linux in toolchain, while identical in portage tree and portage itself. RAP's toolchain differs from that of present Prefix Linux but uses the same portage and portage tree. Alternatively, reorder/reword and combine that paragraph with the next one: RAP uses the same portage and portage tree as present Prefix Linux but differs in toolchain, which includes kernel headers(trivial), libc(glibc), compiler(gcc) and linker(binutils). We focus our discussion on the last three parts as well
Re: [gentoo-dev] Sets in the tree
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. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
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.
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
Paweł Hajdan, Jr. phajdan...@gentoo.org writes: Sounds good. Note that it doesn't need to be set up as against Canonical. Just do the best thing for the users. Thanks. I'd take your advice. 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. Everybody can create a sub-project, and I'm happy to see this kind of project appearing in Gentoo. I'd recommend focusing on creating a good, compelling experience, not just pushing out something before Canonical. :) Yes, I agree. pgpVnDXtIHVc5.pgp Description: PGP signature
Re: [gentoo-dev] news item: Language of compiler messages etc. in build logs
On Tue, 13 Aug 2013 22:59:49 +0200 Andreas K. Huettel dilfri...@gentoo.org wrote: anymore but default to English. The intention behind this is to intention behind this is = rationale is have a hard time analyzing localized builds. analyzing localized builds = reading build logs in foreign languages This change only affects the emerge build logs, nothing else. the = the language of messages printed in jer
[gentoo-dev] Re: Sets in the tree
Sergey Popov posted on Wed, 14 Aug 2013 17:07:32 +0400 as excerpted: Why [were sets] not added as a part of the PMS? Some implementation flaws? Or maybe, architecture problems? [TL;DR folks, skip to last paragraph summary.] (As a user who has been using sets as they appear in the kde overlay and portage 2.2 for quite some time... This is obviously my opinion based on what I've seen from my vantage-point, and is thus open to correction from those closer to the action.) AFAIK, it's several things. I believe the first sets implementation was in paludis, with the kde- overlay an early user back when it was first setup and it required paludis. When portage implemented sets (and the kde-overlay stopped requiring paludis and began using portage sets as an OPTION to the meta-packages that were also setup there and in the main tree), its implementation was somewhat different, which ended up being a bit awkward, because paludis had implemented them first and so had first-mover default, but portage remains gentoo default PM, but the implementations weren't (fully?) compatible, so it was a bit of a battle of the defaults. I believe that's actually one of the big things that kept portage's sets implementation in experimental-masked 2.2 for so long -- at least at first, there was an intention to try to settle on a sets standard that both (plus pkgcore) could implement. But over time it became more and more apparent that simply wasn't going to happen, and for quite some time I at least, thought the feature was doomed to be forever masked. Meanwhile, the role of PMS itself became clearer and somewhat more strictly limited, over time. Ciaranm or someone else can probably give a more precise and accurate definition, but as I understand it, basically, PMS is limited to defining the format of ebuilds and the files necessary to support them and package-manager interoperability in-tree, including eclasses, profiles, EAPIs, etc. It does NOT cover individual PM configuration, etc. AFAIK, the metadata cache format isn't actually covered by PMS either, as to some extent that's considered private to the PM implementation (and in the absolute, it could almost certainly be improved upon by individual PMs), altho in practice, particularly since it's shipped with the tree, that too must be standardized at least for any PM that doesn't wish to force regeneration of all that data into its own format at every update, when it's already shipped with the tree. As it became clear a fully compatible implementation simply wasn't happening, sets ended up in this gap as well. Like the metadata cache, from a certain viewpoint they're arguably a private implementation detail, not subject to interoperability standardization, and I guess this is how things were finally finessed. Of course in practice it would be very nice to have inter-operable compatibility, but for various probably both technical and political reasons, it simply hasn't happened, and I guess the decision finally was to quit letting the impossibly perfect be the enemy of the better-than-what-we-had. So while portage-style sets are now (it seems, this is the first I read of it) allowed in-tree, from the PMS angle they remain outside the spec as a PM private implementation detail, and thus cannot fully take the place of meta-packages. But as it turns out, meta-packages end up being more flexible and powerful anyway, as (AFAIK, maybe it was added and I missed it) at least portage's sets implementation doesn't have a parallel to a meta-package's USE flags, possible slot deps, etc. OTOH, as I've found out here, sets are GREAT for users as a method of subdividing and organizing the formerly monolithic world file. Several years ago now, as it happens when I was working on setting up my netbook and needed to organize my existing world list into categories to better decide what bits of it I wanted on the netbook and what bits not, I split my world file into about a dozen sets by category (using the kde sets as my starting point and pattern), with each former world-file package atom placed into one set or another, and all the sets in turn listed in my world_sets file. That makes managing my world list FAR easier, as everything's now categorized. =:^) Posting a set file then becomes a simple way of sharing a list of what packages I have installed in a particular category (which may or may not correspond exactly to a tree-package category, in the kde overlay several kde sets compose the larger kde-base package category, for instance). Another practical use (extended from the above) I've discovered by actual usage of the kde sets, is that I copy and rename the kde sets to /etc/ portage/sets/, and list my renamed versions in my world_sets file. Then I #-comment out individual packages I don't need (as well as libraries, so they're just pulled in as deps), while leaving the line otherwise intact in the file. Then
Re: [gentoo-dev] Re: Sets in the tree
On Wed, 14 Aug 2013 15:29:00 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Sergey Popov posted on Wed, 14 Aug 2013 17:07:32 +0400 as excerpted: Why [were sets] not added as a part of the PMS? Some implementation flaws? Or maybe, architecture problems? [TL;DR folks, skip to last paragraph summary.] Most of this is wrong. I'd recommend skipping the whole thing. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Sets in the tree
On 08/14/2013 10:17 PM, Ciaran McCreesh wrote: 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. You keep repeating that. That doesn't make it more true.
Re: [gentoo-dev] Sets in the tree
On 08/14/2013 09:02 PM, Michał Górny wrote: On Wed, Aug 14, 2013 at 7:42 AM, Michael Palimaka kensing...@gentoo.org wrote: Right now, however, it might be useful if only to get a sense for how they're being used, trade ideas, etc. No, we can't. Sets are portage-specific, the tree needs to follow PMS. So fix PMS to reflect reality. Again.
Re: [gentoo-dev] Sets in the tree
On Wed, 14 Aug 2013 23:41:03 +0800 Patrick Lauer patr...@gentoo.org wrote: On 08/14/2013 10:17 PM, Ciaran McCreesh wrote: 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. You keep repeating that. That doesn't make it more true. It's not a question of more true, it simply is true. Look at the class line. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Sets in the tree
On Wed, 14 Aug 2013 23:41:56 +0800 Patrick Lauer patr...@gentoo.org wrote: On 08/14/2013 09:02 PM, Michał Górny wrote: On Wed, Aug 14, 2013 at 7:42 AM, Michael Palimaka kensing...@gentoo.org wrote: Right now, however, it might be useful if only to get a sense for how they're being used, trade ideas, etc. No, we can't. Sets are portage-specific, the tree needs to follow PMS. So fix PMS to reflect reality. Again. I think you're misunderstanding the point of a standard here. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Sets in the tree
On 08/14/2013 11:43 PM, Ciaran McCreesh wrote: On Wed, 14 Aug 2013 23:41:03 +0800 Patrick Lauer patr...@gentoo.org wrote: On 08/14/2013 10:17 PM, Ciaran McCreesh wrote: 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. You keep repeating that. That doesn't make it more true. It's not a question of more true, it simply is true. Look at the class line. Looking at, for example, kde overlay: https://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=tree;f=sets;h=0e7389b34215915696d99fdb19e03c6d5ce1902f;hb=HEAD All the sets I've had a look at are a list of package atoms. No python code involved. None of your conspiracy theories supported. (Maybe it'd be easier to discuss this if there were a design document for it, but ain't no one got time for dat) So ... what was your claim again?
Re: [gentoo-dev] Changes in libreoffice ebuild
On 13/08/13 10:10, Tomáš Chvátal wrote: [3] https://wiki.documentfoundation.org/Development/gerrit And all boils down to the fact gerrit needs to be fixed to take patches from a mailing list or provide some sane alias to cope with it's specific ways... lu
Re: [gentoo-dev] Sets in the tree
On 08/14/2013 11:44 PM, Ciaran McCreesh wrote: On Wed, 14 Aug 2013 23:41:56 +0800 Patrick Lauer patr...@gentoo.org wrote: On 08/14/2013 09:02 PM, Michał Górny wrote: On Wed, Aug 14, 2013 at 7:42 AM, Michael Palimaka kensing...@gentoo.org wrote: Right now, however, it might be useful if only to get a sense for how they're being used, trade ideas, etc. No, we can't. Sets are portage-specific, the tree needs to follow PMS. So fix PMS to reflect reality. Again. I think you're misunderstanding the point of a standard here. 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.
Re: [gentoo-dev] Sets in the tree
On Wed, 14 Aug 2013 23:50:36 +0800 Patrick Lauer patr...@gentoo.org wrote: On 08/14/2013 11:43 PM, Ciaran McCreesh wrote: On Wed, 14 Aug 2013 23:41:03 +0800 Patrick Lauer patr...@gentoo.org wrote: On 08/14/2013 10:17 PM, Ciaran McCreesh wrote: 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. You keep repeating that. That doesn't make it more true. It's not a question of more true, it simply is true. Look at the class line. Looking at, for example, kde overlay: https://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=tree;f=sets;h=0e7389b34215915696d99fdb19e03c6d5ce1902f;hb=HEAD All the sets I've had a look at are a list of package atoms. No python code involved. None of your conspiracy theories supported. (Maybe it'd be easier to discuss this if there were a design document for it, but ain't no one got time for dat) So ... what was your claim again? Uhm. Look at the class line. https://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=sets.conf;h=1f4c4263f48e5360606c1acc97fbab64b03541b7;hb=HEAD -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Changes in libreoffice ebuild
On 08/13/2013 04:10 PM, Tomáš Chvátal wrote: As per my comment in bugzilla [1] I said that the patch should be submitted upstream prior having it in cvs. Yet you decided to completely ignore my statement and just smash in the patch anyway [2]. Please don't do this ever again. We had shitload of distro patches before and it is hell to strip away later on. I left the bug open so it doesn't get forgotten. It'll not take you more time to handle that bug ... For your statement of lacking documentation, when I google gerrit libreoffice first two links lead directly to the instance and 3rd to wiki [3], which no suprise is guide how to set it up and submit request, so stop lying. I have no interest in spending some hours to figure out an arcane interface that doesn't work by default. Since you already know how it works it's a more efficient use of your two minutes than wasting hours listening to my frustrated ranting As you like to ignore maintainer requests I now expect you to submit it to the gerit, since now you have the guide and you can proceed without an issue right? Note that I have nothing against other devs submitting fixes to ebuilds maintained by me, but directly ignoring what I said on a bug and doing whatever you see fit does not match that at all. Then don't leave such simple bugs open for a long time. It was broken, now it builds again: User experience has been improved. Your work for further triaging this bug has not been affected. Everyone profits.
Re: [gentoo-dev] Re: GCC 4.8 unmasking
On 14/08/13 01:40, Ryan Hill wrote: On Tue, 13 Aug 2013 07:13:13 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 13/08/13 03:41, Ryan Hill wrote: I don't see any reason to keep this masked other than bug #416069, which needs to be fixed anyways. How does Friday sound? https://bugs.gentoo.org/416069 xorg-2.eclass: add --disable-selective-werror to configure https://bugs.gentoo.org/461954 GCC 4.8 porting gcc-4.8 can miscompile libc http://gcc.gnu.org/bugzilla//show_bug.cgi?id=56888 We should make sure we do not get bitten by this. We don't build glibc with -O3. Other libc's should either not use -O3 or use -fno-tree-loop-distribute-patterns where applicable. On certain arches the memcpy tranformation happens even on lower optimization levels or so I saw reported. lu
Re: [gentoo-dev] Sets in the tree
On Wed, 14 Aug 2013 11:50:56 -0400 Anthony G. Basile bluen...@gentoo.org wrote: On 08/14/2013 11:41 AM, Patrick Lauer wrote: On 08/14/2013 10:17 PM, Ciaran McCreesh wrote: 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. You keep repeating that. That doesn't make it more true. Even if it were true, this does not stop pms from providing an abstraction layer which provides the needed support despite the details of the underlying implementation. The argument that implementation details limit such possibilities is spurious and should be ignored. Why would we design a spec around arbitrary list of class names that happen to be present in some particular version of Portage? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Sets in the tree
On Wed, 14 Aug 2013 23:53:09 +0800 Patrick Lauer patr...@gentoo.org wrote: On 08/14/2013 11:44 PM, Ciaran McCreesh wrote: On Wed, 14 Aug 2013 23:41:56 +0800 Patrick Lauer patr...@gentoo.org wrote: On 08/14/2013 09:02 PM, Michał Górny wrote: On Wed, Aug 14, 2013 at 7:42 AM, Michael Palimaka kensing...@gentoo.org wrote: Right now, however, it might be useful if only to get a sense for how they're being used, trade ideas, etc. No, we can't. Sets are portage-specific, the tree needs to follow PMS. So fix PMS to reflect reality. Again. I think you're misunderstanding the point of a standard here. Well, it should reflect reality. No, the standard defines reality. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Sets in the tree
On 08/14/2013 11:54 PM, Ciaran McCreesh wrote: On Wed, 14 Aug 2013 23:50:36 +0800 Patrick Lauer patr...@gentoo.org wrote: On 08/14/2013 11:43 PM, Ciaran McCreesh wrote: On Wed, 14 Aug 2013 23:41:03 +0800 Patrick Lauer patr...@gentoo.org wrote: On 08/14/2013 10:17 PM, Ciaran McCreesh wrote: 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. You keep repeating that. That doesn't make it more true. It's not a question of more true, it simply is true. Look at the class line. Looking at, for example, kde overlay: https://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=tree;f=sets;h=0e7389b34215915696d99fdb19e03c6d5ce1902f;hb=HEAD All the sets I've had a look at are a list of package atoms. No python code involved. None of your conspiracy theories supported. (Maybe it'd be easier to discuss this if there were a design document for it, but ain't no one got time for dat) So ... what was your claim again? Uhm. Look at the class line. https://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=sets.conf;h=1f4c4263f48e5360606c1acc97fbab64b03541b7;hb=HEAD ... a static identifier. I would usually call that a constant. Now I get bored with your trolling. Goodbye.
Re: [gentoo-dev] Sets in the tree
On 08/14/2013 11:41 AM, Patrick Lauer wrote: On 08/14/2013 10:17 PM, Ciaran McCreesh wrote: 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. You keep repeating that. That doesn't make it more true. Even if it were true, this does not stop pms from providing an abstraction layer which provides the needed support despite the details of the underlying implementation. The argument that implementation details limit such possibilities is spurious and should be ignored. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Sets in the tree
On 14 August 2013 16:59, Patrick Lauer patr...@gentoo.org wrote: On 08/14/2013 11:54 PM, Ciaran McCreesh wrote: On Wed, 14 Aug 2013 23:50:36 +0800 Patrick Lauer patr...@gentoo.org wrote: On 08/14/2013 11:43 PM, Ciaran McCreesh wrote: On Wed, 14 Aug 2013 23:41:03 +0800 Patrick Lauer patr...@gentoo.org wrote: On 08/14/2013 10:17 PM, Ciaran McCreesh wrote: 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. You keep repeating that. That doesn't make it more true. It's not a question of more true, it simply is true. Look at the class line. Looking at, for example, kde overlay: https://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=tree;f=sets;h=0e7389b34215915696d99fdb19e03c6d5ce1902f;hb=HEAD All the sets I've had a look at are a list of package atoms. No python code involved. None of your conspiracy theories supported. (Maybe it'd be easier to discuss this if there were a design document for it, but ain't no one got time for dat) So ... what was your claim again? Uhm. Look at the class line. https://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=sets.conf;h=1f4c4263f48e5360606c1acc97fbab64b03541b7;hb=HEAD ... a static identifier. I would usually call that a constant. Now I get bored with your trolling. Goodbye. Lets stop this offtopic discussion pretty please. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
[gentoo-dev] Package up for grab: app-laptop/prey
The original maintainers of the package app-laptop/prey have decided[1] they do no longer want to maintain this package; therefore it has been assigned to maintainer-needed@g.o, if anyone is interested in maintaining this package then feel free to pick it up. It only has two bugs open at the moment; bug #451882[1] and bug #443728[2]. [1]: app-laptop/prey-0.5.10 - Version bump. https://bugs.gentoo.org/show_bug.cgi?id=451882 [2]: app-laptop/prey-0.5.4-r1: /etc/init.d/prey-trigger is installed as invalid symlink, first run attempts to locate an rc3.d directory, system module error https://bugs.gentoo.org/show_bug.cgi?id=443728 app-laptop/prey -- 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] Changes in libreoffice ebuild
Luca Barbato wrote: [3] https://wiki.documentfoundation.org/Development/gerrit And all boils down to the fact gerrit needs to be fixed to take patches from a mailing list Usually Gerrit just needs an OpenID in order to accept git push via SSH. That seems significantly better to me than parsing emails. //Peter
Re: [gentoo-dev] Sets in the tree
On Wed, 14 Aug 2013 23:59:28 +0800 Patrick Lauer patr...@gentoo.org wrote: Uhm. Look at the class line. https://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=sets.conf;h=1f4c4263f48e5360606c1acc97fbab64b03541b7;hb=HEAD ... a static identifier. I would usually call that a constant. Now I get bored with your trolling. Goodbye. Please explain, for the benefit of everyone who posts to this list, why my claim that the line class = portage.sets.files.StaticFileSet in sets.conf corresponds to a class in Portage is trolling. Your claim that this is a constant is contradicted not just by common sense and the Portage code, but also by the Portage documentation: http://dev.gentoo.org/~zmedico/portage/doc/portage.html#config-set The configuration of a single set can be very simple as in most cases it only requires a single option class to be complete [1]. That option defines which handler class should be used to create the set. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Sets in the tree
On Wed, 14 Aug 2013 16:56:09 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On 08/14/2013 10:17 PM, Ciaran McCreesh wrote: On Wed, 14 Aug 2013 17:07:32 +0400 Sergey Popov pinkb...@gentoo.org wrote: 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. Why would we design a spec around arbitrary list of class names that happen to be present in some particular version of Portage? Yes, why would we? Consider that you can make the same statement without naming a PM... Nobody here has yet said that the spec has to be around that. What the Portage format is and what Portage implements doesn't matter yet; what really matters in this thread is, why it is not in the PMS yet. We know that you don't want it that way; so, you don't need to repeat it. What people interest more is why this is not the PMS yet; that, on its own, is a request to consider the feature, not the specification. How the specification should be, that is for people involved with the PMS to discuss; but as stated before, I believe that is off-topic here. The discussion at stake here is Can we add sets to the tree? If so, should everyone be able to do that free or by prior discussion? and I don't think that any reply to this whole sub thread benefits anyone. Thank you for your understanding. -- 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 Wed, 14 Aug 2013 16:58:01 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 14 Aug 2013 23:53:09 +0800 Patrick Lauer patr...@gentoo.org wrote: On 08/14/2013 11:44 PM, Ciaran McCreesh wrote: On Wed, 14 Aug 2013 23:41:56 +0800 Patrick Lauer patr...@gentoo.org wrote: So fix PMS to reflect reality. Again. I think you're misunderstanding the point of a standard here. Well, it should reflect reality. No, the standard defines reality. Come on guys; a standard / spec is a norm, convention of requirement. You don't want to reflect reality because if reality were broken you would be defining broken behavior in the standard; so, yes, you would kind of define reality depending on how you define defining reality. Let's just agree that we need to discuss whether we want it in the PMS and how, not necessarily in this thread as it could be perceived as off-topic by most here; I don't see why we need to fight over a word's meaning, especially when that word is not relevant to this discussion. -- 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 Wed, Aug 14, 2013 at 12:54 PM, Tom Wijsman tom...@gentoo.org wrote: The discussion at stake here is Can we add sets to the tree? If so, should everyone be able to do that free or by prior discussion? and I don't think that any reply to this whole sub thread benefits anyone. So, I already added my two cents as far as those questions go. However, the issue that was subsequently brought up basically amounts to why would we bother adding sets to the tree in the first place? If you can't use them to replace meta-packages, what else would you even use them for? Rich
Re: [gentoo-dev] Sets in the tree
On Wed, 14 Aug 2013 18:54:40 +0200 Tom Wijsman tom...@gentoo.org wrote: On Wed, 14 Aug 2013 16:56:09 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On 08/14/2013 10:17 PM, Ciaran McCreesh wrote: On Wed, 14 Aug 2013 17:07:32 +0400 Sergey Popov pinkb...@gentoo.org wrote: 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. Why would we design a spec around arbitrary list of class names that happen to be present in some particular version of Portage? Yes, why would we? Consider that you can make the same statement without naming a PM... Nobody here has yet said that the spec has to be around that. What the Portage format is and what Portage implements doesn't matter yet; what really matters in this thread is, why it is not in the PMS yet. Er, look at the first post in the thread: Now that portage-2.2 is in ~arch, we should now be able to add sets to the tree. class = portage.sets.files.StaticFileSet Please explain to me how this is not a thread about using Portage's internal-class-based sets format in the tree. The discussion at stake here is Can we add sets to the tree? If so, should everyone be able to do that free or by prior discussion? and I don't think that any reply to this whole sub thread benefits anyone. The answer to that is the same as it's always been, and hasn't been changed by portage-2.2 being ~arch. In order for sets to be added to the tree, we need a spec, we need to decide where sets are allowed (package.mask?), and we need an implementation. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Sets in the tree
On Wed, 14 Aug 2013 19:09:40 +0100
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
Er, look at the first post in the thread:
That was about the repository, not about the PMS; the question was
whether we need to respect the PMS and why it misses this _feature_,
for which no proposed specification exists afaik, so I don't see why
you quote that implementation as a reason for it not being in the PMS.
The answer to that is the same as it's always been, and hasn't been
changed by portage-2.2 being ~arch.
It hasn't changed _yet_, this wakes some sleeping dogs that will want
to see this happen; so, it might change as part of this discussion.
In order for sets to be added to the tree, we need a spec, we need
to decide where sets are allowed (package.mask?), and we need an
implementation.
Sets in package.mask sounds unreliable as that would prohibit the set
from being changed as long as it masked; unless of course, the
specification would allow for a concept like mask sets to exist
where a particular set is denoted as masked. Otherwise, you would have
people add / remove things from a normal set and break the mask intent.
On a side note, it also makes it a bit harder to run the typical tools:
find ${PORTDIR} -name 'package.mask' -exec awk -vRS= '/avidemux/' {} \;
So, I would rather like to not see sets in package.mask or mask sets.
--
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 Wed, 14 Aug 2013 20:57:57 +0200 Tom Wijsman tom...@gentoo.org wrote: On Wed, 14 Aug 2013 19:09:40 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Er, look at the first post in the thread: That was about the repository, not about the PMS; the question was whether we need to respect the PMS Ask yourself this: if it were a Paludis-specific feature not covered by PMS instead of a Portage-specific feature not covered by PMS, would you be happy with it being put in the main tree? If the answer is no, then it shouldn't be in the tree. and why it misses this _feature_, for which no proposed specification exists afaik, so I don't see why you quote that implementation as a reason for it not being in the PMS. It's not in PMS because no-one's finished the usual process for getting it into PMS. In order for sets to be added to the tree, we need a spec, we need to decide where sets are allowed (package.mask?), and we need an implementation. Sets in package.mask sounds unreliable as that would prohibit the set from being changed as long as it masked; unless of course, the specification would allow for a concept like mask sets to exist where a particular set is denoted as masked. Otherwise, you would have people add / remove things from a normal set and break the mask intent. Using the conventional view of what a set is, the point is to allow you to mask, say, kde7 using a single line, and then define what kde7 is using a set. Then the user can unmask kde7 without having to copy a big, potentially changing list of packages out of package.mask. Now, if you're viewing a set as being a metapackage rather than a list of specs, this doesn't apply. But then why have sets at all if they're just a metapackage? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Sets in the tree
On 08/14/2013 03:02 PM, Michał Górny wrote: Dnia 2013-08-14, o godz. 16:53:17 Sergey Popov pinkb...@gentoo.org napisał(a): 14.08.2013 16:05, Rich Freeman пишет: On Wed, Aug 14, 2013 at 7:42 AM, Michael Palimaka kensing...@gentoo.org wrote: Right now, however, it might be useful if only to get a sense for how they're being used, trade ideas, etc. Well, we can use sets as replacement for metapackages(for example, qt-meta, leechcraft-meta). Well, as for leechcraft-meta, we can not simply replace metapackage with set, cause we have unstable USE-flag there. No, we can't. Sets are portage-specific, the tree needs to follow PMS. PMS is a waste of time, we should drop it until people are able to maintain it properly. They are obviously not. And their lack of time (to be polite) should not block general progress in gentoo.
Re: [gentoo-dev] Sets in the tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/14/2013 09:28 PM, Ciaran McCreesh wrote: Using the conventional view of what a set is, the point is to allow you to mask, say, kde7 using a single line, and then define what kde7 is using a set. Then the user can unmask kde7 without having to copy a big, potentially changing list of packages out of package.mask. That is the first interesting paragraph in this thread, thanks for bringing it up. sidenote: see `emerge --list-sets` for inspirations, esp. plug-ins like smart-live-rebuild. - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlIL39sACgkQknrdDGLu8JDZaAD/c8fN2NqdrwyTvlmF2NrB4DUz uqOeFDvy8tnJIh2RLf4A/io5s42YsoznXnz91tcBUQGz4uh+HmRBbbB+SczaRsFA =rGrM -END PGP SIGNATURE-
Re: [gentoo-dev] Sets in the tree
On Wed, 14 Aug 2013 21:34:51 +0200 hasufell hasuf...@gentoo.org wrote: On 08/14/2013 03:02 PM, Michał Górny wrote: Dnia 2013-08-14, o godz. 16:53:17 Sergey Popov pinkb...@gentoo.org napisał(a): 14.08.2013 16:05, Rich Freeman пишет: On Wed, Aug 14, 2013 at 7:42 AM, Michael Palimaka kensing...@gentoo.org wrote: Right now, however, it might be useful if only to get a sense for how they're being used, trade ideas, etc. Well, we can use sets as replacement for metapackages(for example, qt-meta, leechcraft-meta). Well, as for leechcraft-meta, we can not simply replace metapackage with set, cause we have unstable USE-flag there. No, we can't. Sets are portage-specific, the tree needs to follow PMS. PMS is a waste of time, we should drop it until people are able to maintain it properly. They are obviously not. You're fundamentally misunderstanding how PMS and Gentoo development works. No-one has (recently) proposed supporting sets in the tree to either the PMS team or the Council, so it's not in PMS. The point of having a spec isn't to document recent changes in Portage behaviour. The Council has decided that to be able to use something in the tree, it has to be in their most recently approved version of PMS. If you want to use sets in the tree, submit a proposal to the Council, and if they like then it a new version of PMS will be approved. And their lack of time (to be polite) should not block general progress in gentoo. Lack of time has got nothing to do with this not being in PMS. It's not in PMS because no-one's submitted a proposal for it that's gained Council approval. Perhaps these basic notions of how Gentoo development works should be added to the new developer quiz, so we can be sure people understand the appropriate ways of making changes and where the power lies. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Sets in the tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/14/2013 09:51 PM, Ciaran McCreesh wrote: Perhaps these basic notions of how Gentoo development works should be added to the new developer quiz, so we can be sure people understand the appropriate ways of making changes and where the power lies. If it lies at the PMS guys, we should just drop it. - -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlIL4DYACgkQknrdDGLu8JAMNAD+J8Bqr6cvt9PrjRBShI6NbIlW wfz4OoeI56DlTKd2TWUA/Rsi3SstMk7MyE1wmQ+Ac+pnytImfZZD4VBATeJeymYY =p0ok -END PGP SIGNATURE-
Re: [gentoo-dev] Sets in the tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 14 Aug 2013 21:53:26 +0200 Michael Weber x...@gentoo.org wrote: On 08/14/2013 09:51 PM, Ciaran McCreesh wrote: Perhaps these basic notions of how Gentoo development works should be added to the new developer quiz, so we can be sure people understand the appropriate ways of making changes and where the power lies. If it lies at the PMS guys, we should just drop it. Well that's the point: the PMS team has no powers. All PMS does is document Council decisions on what's allowed in the tree. This really needs to be in the new developer quiz. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iEYEARECAAYFAlIL4VsACgkQ96zL6DUtXhEuqQCgv35OAwXlJt1/oC3uhFGsNzwV qKUAn0C2kqCSrVThc8c39/04WiQzi5tC =6R4A -END PGP SIGNATURE-
Re: [gentoo-dev] Sets in the tree
On 08/14/2013 09:51 PM, Ciaran McCreesh wrote: On Wed, 14 Aug 2013 21:34:51 +0200 hasufell hasuf...@gentoo.org wrote: On 08/14/2013 03:02 PM, Michał Górny wrote: Dnia 2013-08-14, o godz. 16:53:17 Sergey Popov pinkb...@gentoo.org napisał(a): 14.08.2013 16:05, Rich Freeman пишет: On Wed, Aug 14, 2013 at 7:42 AM, Michael Palimaka kensing...@gentoo.org wrote: Right now, however, it might be useful if only to get a sense for how they're being used, trade ideas, etc. Well, we can use sets as replacement for metapackages(for example, qt-meta, leechcraft-meta). Well, as for leechcraft-meta, we can not simply replace metapackage with set, cause we have unstable USE-flag there. No, we can't. Sets are portage-specific, the tree needs to follow PMS. PMS is a waste of time, we should drop it until people are able to maintain it properly. They are obviously not. You're fundamentally misunderstanding how PMS and Gentoo development works. I think you are fundamentally misunderstanding. I think gentoo should stop supporting downstreams IF supporting them means blocking progress. 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...
Re: [gentoo-dev] Sets in the tree
On Wed, Aug 14, 2013 at 12:51 PM, Michael Weber x...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/14/2013 09:28 PM, Ciaran McCreesh wrote: Using the conventional view of what a set is, the point is to allow you to mask, say, kde7 using a single line, and then define what kde7 is using a set. Then the user can unmask kde7 without having to copy a big, potentially changing list of packages out of package.mask. That is the first interesting paragraph in this thread, thanks for bringing it up. sidenote: see `emerge --list-sets` for inspirations, esp. plug-ins like smart-live-rebuild. A major reason that I kept portage-2.2 masked for so long was to avoid misuse of sets for rebuilds (like @x11-module-rebuild and @preserved-rebuild). Since slot-operator and sub-slots are available in EAPI 5, the danger of this form of abuse has lessened. I think that in the long run it would be best if we replaced the smart-live-rebuild set with an EAPI-based solution [1]. [1] https://bugs.gentoo.org/show_bug.cgi?id=182028
Re: [gentoo-dev] Sets in the tree
On Wed, 14 Aug 2013 20:28:02 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: [.. SNIP ..] Thank you. In order for sets to be added to the tree, we need a spec, we need to decide where sets are allowed (package.mask?), and we need an implementation. Sets in package.mask sounds unreliable as that would prohibit the set from being changed as long as it masked; unless of course, the specification would allow for a concept like mask sets to exist where a particular set is denoted as masked. Otherwise, you would have people add / remove things from a normal set and break the mask intent. Using the conventional view of what a set is, But what kind of view would that be, a mathematical set, a set from a prior discussion or a completely different set? I assume the first one. the point is to allow you to mask, say, kde7 using a single line, and then define what kde7 is using a set. Then the user can unmask kde7 without having to copy a big, potentially changing list of packages out of package.mask. Thank you for clarifying this possibility, that's a good feature; though my wonder here is whether that set will unintentionally change, this could happen if the set is used for other purposes. (emerge @set) See my previous mail for that concern. Now, if you're viewing a set as being a metapackage rather than a list of specs, this doesn't apply. But then why have sets at all if they're just a metapackage? You can also ask the opposite: But why have meta packages if they can be sets? Sets are placed together; which as a result, give you a better overview of the existing sets. How does one for example query all the meta packages that are in the tree? It also keeps you from defining package specific matters that a meta package doesn't really need (EAPI, KEYWORDS, S, ...). On the other hand, meta packages have IUSE; that might not fit in sets. (I'm not choosing for a particular side, just enumerating thoughts.) -- 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 Wed, 14 Aug 2013 21:59:37 +0200 hasufell hasuf...@gentoo.org wrote: You're fundamentally misunderstanding how PMS and Gentoo development works. I think you are fundamentally misunderstanding. I think gentoo should stop supporting downstreams IF supporting them means blocking progress. What's this got to do with anything we're discussing? PMS isn't a downstream. It's what the Council decided is allowed in the tree. Or are you suggesting the Council is somehow a downstream that is blocking progress? I don't follow what you're implying here. 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, but I did create and write large parts of the devmanual, and I proposed and wrote the original developer quiz, and was involved in the original decision to move to a documented package format, and wrote part of the GLEP governing how the Council operates, and wrote a large part of PMS, and designed or codesigned a fair number of the new features that have been introduced to the format since then, and have a few GLEPS with my name on them. So I'd hope I can safely claim that I'm not prone to some of basic misunderstandings about how Gentoo works that have been exhibited in this thread. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Sets in the tree
On 08/14/2013 10:07 PM, Ciaran McCreesh wrote: On Wed, 14 Aug 2013 21:59:37 +0200 hasufell hasuf...@gentoo.org wrote: You're fundamentally misunderstanding how PMS and Gentoo development works. I think you are fundamentally misunderstanding. I think gentoo should stop supporting downstreams IF supporting them means blocking progress. What's this got to do with anything we're discussing? PMS isn't a downstream. It's what the Council decided is allowed in the tree. Or are you suggesting the Council is somehow a downstream that is blocking progress? I don't follow what you're implying here. I can't help you with that. I'm just saying what my opinion as a developer is and that I will vote/push into that direction. 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
Re: [gentoo-dev] Sets in the tree
On Wed, 14 Aug 2013 22:03:38 +0200 Tom Wijsman tom...@gentoo.org wrote: Using the conventional view of what a set is, But what kind of view would that be, a mathematical set, a set from a prior discussion or a completely different set? I assume the first one. The rather outdated GLEP 21 says they're a mere groups of packages, grouped together to allow easier updating and handling of them. I would use the term spec rather than package there for consistency with PMS, since package implies you can't specify slots or version restrictions. This is bad, because a KDE 7 set is a useful idea. So using more modern terminology: A set is a collection of dependency specifications, grouped together and given a name for convenience. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Sets in the tree
On 14 August 2013 21:13, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Wed, 14 Aug 2013 22:03:38 +0200 Tom Wijsman tom...@gentoo.org wrote: Using the conventional view of what a set is, But what kind of view would that be, a mathematical set, a set from a prior discussion or a completely different set? I assume the first one. The rather outdated GLEP 21 says they're a mere groups of packages, grouped together to allow easier updating and handling of them. I would use the term spec rather than package there for consistency with PMS, since package implies you can't specify slots or version restrictions. This is bad, because a KDE 7 set is a useful idea. So using more modern terminology: A set is a collection of dependency specifications, grouped together and given a name for convenience. -- Ciaran McCreesh My understanding is that the cvs tree should be PMS compatible and since 'sets' are not part of PMS that means that it would be wise not to use them yet. It is unfortunate that nobody seems to have realized that all these years that 2.2.X was masked :-/ -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Sets in the tree
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
Re: [gentoo-dev] Sets in the tree
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 -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Sets in the tree
On Wed, 14 Aug 2013 21:16:18 +0100 Markos Chandras hwoar...@gentoo.org wrote: My understanding is that the cvs tree should be PMS compatible and since 'sets' are not part of PMS that means that it would be wise not to use them yet. It is unfortunate that nobody seems to have realized that all these years that 2.2.X was masked :-/ I don't think it's a question of not realising it. As I understand it, no-one's proposed Portage-format sets to the Council because we all agree it's not suitable for the tree in its current form. The sets in Portage 2.2 are fine as a user feature, but not as a tree feature. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Sets in the tree
I've always found those class = something.that.is.clearly.portage.specific lines a bit of a bummer, since they're very tied to the internal functioning of portage and not a generic standard for how things should be defined. Before we add sets to the tree, maybe there should be some discussion about standardizing the set formats.
Re: [gentoo-dev] Sets in the tree
On 08/14/2013 10:17 PM, Ulrich Mueller 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 Why don't you respond to my technical points then? PMS is blocking progress, again, because it does not reflect reality. I don't even see a reason why we should keep up that effort.
Re: [gentoo-dev] Sets in the tree
On Wed, 14 Aug 2013 22:41:02 +0200 hasufell hasuf...@gentoo.org wrote: Why don't you respond to my technical points then? PMS is blocking progress, again, because it does not reflect reality. I don't even see a reason why we should keep up that effort. PMS reflects the most recent Council vote on what's allowed in the tree. The PMS team has no authority to add in new features without Council approval. The only way PMS could be blocking progress is if it failed to keep up to date with a Council vote, and this hasn't happened here and hasn't ever happened previously. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Sets in the tree
On 14 August 2013 21:41, hasufell hasuf...@gentoo.org wrote: On 08/14/2013 10:17 PM, Ulrich Mueller 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 Why don't you respond to my technical points then? PMS is blocking progress, again, because it does not reflect reality. I don't even see a reason why we should keep up that effort. Because if you want to allow multiple package managers as an option, then you need to have a clearly defined spec for them. The fact that portage implemented something that is not part of PMS, is not a PMS problem. So unless it becomes part of PMS, it can't be used in places where you expect PMS compliance. If you want PMS to go away, and call portage the one-and-true PM for Gentoo, then it's probably something for the Council to decide. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Sets in the tree
Dnia 2013-08-14, o godz. 16:56:09 Ciaran McCreesh ciaran.mccre...@googlemail.com napisał(a): On Wed, 14 Aug 2013 11:50:56 -0400 Anthony G. Basile bluen...@gentoo.org wrote: On 08/14/2013 11:41 AM, Patrick Lauer wrote: On 08/14/2013 10:17 PM, Ciaran McCreesh wrote: 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. You keep repeating that. That doesn't make it more true. Even if it were true, this does not stop pms from providing an abstraction layer which provides the needed support despite the details of the underlying implementation. The argument that implementation details limit such possibilities is spurious and should be ignored. Why would we design a spec around arbitrary list of class names that happen to be present in some particular version of Portage? Well, I'm pretty sure I *asked* at some point to have the thing formalized, and therefore replacing portage class names with some official abstract package set classes. As far as I remember, it ended up like 'we don't want anything except plain simple package lists'. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] punt PMS (was: Sets in the tree)
On 08/14/2013 10:56 PM, Markos Chandras wrote: If you want PMS to go away, and call portage the one-and-true PM for Gentoo, then it's probably something for the Council to decide. I think that would make sense. We don't have enough resources for such fun and overcoming PMS burdens has been a major concern for everyone who is looking to improve basic functionality. In the end, people rather go for eclass solutions or just give up. That has brought us to the current discussion, to base.eclass and to the multilib eclasses with a very painful way of migration. Mind that I am an author of one of those eclasses as well, so I'm not generally objecting. But it's a fact that portage multilib was held back basically by useless PMS politics, so that we can support alternative PMs like paludis. And that's not the only thing that is annoying about PMS and the politics behind it. Gentoo has become very slow in terms of decision making and progress. GLEPs to improve security are not implemented for _years_ and people have no idea whether we need a PMS section for that or not. It wasn't really discussed and not one bothers anymore.
Re: [gentoo-dev] punt PMS (was: Sets in the tree)
On Thu, 15 Aug 2013 00:19:40 +0200 hasufell hasuf...@gentoo.org wrote: On 08/14/2013 10:56 PM, Markos Chandras wrote: If you want PMS to go away, and call portage the one-and-true PM for Gentoo, then it's probably something for the Council to decide. I think that would make sense. We don't have enough resources for such fun and overcoming PMS burdens has been a major concern for everyone who is looking to improve basic functionality. What PMS burdens? Give one example of a feature that the Council has approved that was abandoned because of PMS. In the end, people rather go for eclass solutions or just give up. That has brought us to the current discussion, to base.eclass base.eclass was a legacy from the old pre-natively-supported implementation of eclasses. Unfortunately for reasons entirely unrelated to PMS, a few developers haven't bothered moving away from it. and to the multilib eclasses with a very painful way of migration. Mind that I am an author of one of those eclasses as well, so I'm not generally objecting. But it's a fact that portage multilib was held back basically by useless PMS politics, so that we can support alternative PMs like paludis. No, it was held back because no-one was able to explain what was changed, and because there was no agreement between developers that whatever it was that was changed was the right way to do it. The Council hasn't approved the use of Portage multilib. And that's not the only thing that is annoying about PMS and the politics behind it. Gentoo has become very slow in terms of decision making and progress. GLEPs to improve security are not implemented for _years_ and people have no idea whether we need a PMS section for that or not. It wasn't really discussed and not one bothers anymore. Again, nothing to do with PMS. Getting a feature that has Council approval into PMS typically takes a day or two. The delays on the security GLEPs are down to Portage and to git migration, not PMS. PMS has *helped* with progress, not slowed it down: it has allowed us to experiment with new features in other, quicker-to-develop package managers before having to spend the effort implementing them in Portage. Have a look at features added in EAPIs 1 and later: at a guess half of them were the direct result of testing in other package managers. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] punt PMS (was: Sets in the tree)
Dnia 2013-08-15, o godz. 00:19:40 hasufell hasuf...@gentoo.org napisał(a): On 08/14/2013 10:56 PM, Markos Chandras wrote: If you want PMS to go away, and call portage the one-and-true PM for Gentoo, then it's probably something for the Council to decide. I think that would make sense. We don't have enough resources for such fun and overcoming PMS burdens has been a major concern for everyone who is looking to improve basic functionality. And do we have the resources to fix the tree every time someone decides on an awesome improvement that obviously can't hurt anything? In the end, people rather go for eclass solutions or just give up. That has brought us to the current discussion, to base.eclass and to the multilib eclasses with a very painful way of migration. Mind that I am an author of one of those eclasses as well, so I'm not generally objecting. But it's a fact that portage multilib was held back basically by useless PMS politics, so that we can support alternative PMs like paludis. If you mean that we should make the multilib-portage mess the official way for people to obtain 32-bit wine, then deity-of-choice bless PMS! -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Sets in the tree
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. (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. Not documenting package.mask as a directory for EAPI0 even when that feature existed in portage before the initial release of PMS. Etc. etc.) 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.
Re: [gentoo-dev] Sets in the tree
On Wed, Aug 14, 2013 at 4:42 PM, 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. Wow, I had exactly the opposite opinion -- that Ciaran had responded politely to much trolling. 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. I agree with this.
Re: [gentoo-dev] Sets in the tree
On 08/15/2013 04:56 AM, Markos Chandras wrote: On 14 August 2013 21:41, hasufell hasuf...@gentoo.org wrote: On 08/14/2013 10:17 PM, Ulrich Mueller 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 Why don't you respond to my technical points then? PMS is blocking progress, again, because it does not reflect reality. I don't even see a reason why we should keep up that effort. Because if you want to allow multiple package managers as an option, If - but why would we do that? then you need to have a clearly defined spec for them. The fact that portage implemented something that is not part of PMS, is not a PMS problem. It is a problem in the cases where portage had a feature *before* PMS was defined, and then PMS tries to ignore it (see my last mail) It is a problem when PMS does not define the configuration, so two PMS-compatible programs can arrive at opposite results for any operation. (Why does PMS not define config? Well, then paludis would have a problem) So unless it becomes part of PMS, it can't be used in places where you expect PMS compliance. Unless PMS reflects reality it serves no purpose but ego stroking and supressing deviant ideas that some people call progress If you want PMS to go away, and call portage the one-and-true PM for Gentoo, then it's probably something for the Council to decide. De facto it is like that - if it doesn't work with portage it gets fixed, masked and/or removed. Using anything else might work, or not, but it also removes you from support (e.g. #gentoo, bugs.gentoo.org (any maintainer is free to ignore or RESO INVA bugs that are not filed with portage) and so on) Claiming that the absence of a written policy invalidates reality is a rather amusing theory that makes little sense.
Re: [gentoo-dev] punt PMS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/15/2013 01:23 AM, Michał Górny wrote: Dnia 2013-08-15, o godz. 00:19:40 hasufell hasuf...@gentoo.org napisał(a): On 08/14/2013 10:56 PM, Markos Chandras wrote: If you want PMS to go away, and call portage the one-and-true PM for Gentoo, then it's probably something for the Council to decide. I think that would make sense. We don't have enough resources for such fun and overcoming PMS burdens has been a major concern for everyone who is looking to improve basic functionality. And do we have the resources to fix the tree every time someone decides on an awesome improvement that obviously can't hurt anything? I have no idea what that means. Global changes are _always_ discussed in the community. PMS doesn't add anything to that process. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSDB0TAAoJEFpvPKfnPDWzU/sH/1ml/Zq/p/bxju9u/w+7Alxg 9PTUXVZRcGTlOT5+DDSYIUB8R0j0bKMxJLuJKPovNfIF42YyD4uQs2ewcScpQ+s8 y8wTfFOTUwpfnRJdhLDGguw4MOFPpHMTQgAKhiY00SUgfuzBEyUoZ6OuqDdyoeUc RapXUBK4qrDFJ8s/6tsLCKtca7Jv47Ct6deNk8CWauKz3t1Zj65Qtb5qAYkc2wu5 sYLOidwLhUID6v/eGfZ+HhFRAkBawRfWnc5fn+Mz9SLSKxecYUX34F+3ZA99Pc+U sUYVsvgz4PN9qOUxb9m7q9Ii4yLxni6vJS48C6pQN62Yv7M0PUmHLWK6GN+dFew= =PG3m -END PGP SIGNATURE-
Re: [gentoo-dev] Sets in the tree
On Thu, 15 Aug 2013 07:42:21 +0800 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. Credit is where credit is due, this warning is not an attack at that; it is more like a warning for most of the statements made after that, and possible one of the other sub threads as well as per last. (not well maintained: simple patches take months to get applied, Do you have an example? Patches need to be written, discussed and decided on; before applying. and even then often need council interference to be applied. The PMS has its implications on our distribution; that it needs Council decisions is more of a logical consequence, and not the exception. Last Council meeting I did not see any PMS matters; so, it rather seems that nothing was sent for consideration, thus nothing gets applied... Does not reflect reality: See my previous mail in this sub thread, it does not need to. Multiple cases like mandating bash 3.2 that we don't even have in tree anymore, There is =app-shells/bash-3.2_p51 in the Portage tree. so no compliance testing possible. That's for a different reason; a particular blocking bug keeps this up, as you can see in bug #479574 [1]. [1]: app-shells/bash: please consider slotting 3.2 for ebuild testing https://bugs.gentoo.org/show_bug.cgi?id=479574 No idea what the PMS has to do with this, could you explain? Not documenting package.mask as a directory for EAPI0 even when that feature existed in portage before the initial release of PMS. Etc. etc.) The existence of a feature does not imply that it needs to be specified in something like the PMS; that EAPI was written many years ago, so, it is more likely the result of a slow / unclear start than bad reflection. === Non-technical and non-Gentoo part follows, feel free to ignore. === 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. That is a comparison of apples and eggs; in this case of our people, a limited set of options is presented. For kids, providing options works really well; you should try it. Why does it work? It gives them control. So, back to our people; they have the choice to get back on topic, stay away or end up losing their access that they had been rewarded. This of course assumes you have ignored them to the point that it is enough; at which point, you'll have to present them their options. Makes me want to tell you Last warning! Don't warn people again, OR ELSE! just to see what happens. Now I wonder which options you will present to him, and how those options will result in reward or a loss of reward; as I don't see any such options, not much will happen for him regardless of what he does in response to your statement. No control due to no change in reward. -- 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] punt PMS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 15 Aug 2013 02:13:07 +0200 hasufell hasuf...@gentoo.org wrote: I have no idea what that means. Global changes are _always_ discussed in the community. PMS doesn't add anything to that process. It puts the consensus and / or decisions in one canonical categorized resource, such that you don't have to search ages in archives to gather all the pieces together; where would they otherwise be placed? PMS avoids us from having to manually solve an unnecessary puzzle. - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBAgAGBQJSDCY/AAoJEJWyH81tNOV9d5MH/0gdLzOmxV5WLJi1hGFnqDIZ gEWTHv8PXOZFjhMJ4sT5qcvLTw+C+HYZxVEKJLs1v8fzl7nGimIaeyklgC4cDDTi RHCLUtgvBMQg9oLvHD04C1vXtq+Fc6cJbv+s7z6SArjxgWj4gCNeaVOK0kdpFh55 4tHzjgtbhgclfkjzNR3M/Z5WdWeMXXhxIcEpgJnUjIhg5v9joKem8KPv1NNRlt+q VizYt8yjtq9Akte9Ch3ZqC5GQzrUsHYVw30Np5VIGIqIHHhVjzh18qpNKm4UBs2o xKpwdlqoRsATp5iTcO0t7lRLwG9hg6+fLSkbcERZuoN/V+uTy9cWFggq1/9dxt4= =saqg -END PGP SIGNATURE-
Re: [gentoo-dev] Sets in the tree
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/15/2013 02:48 AM, Tom Wijsman wrote: Multiple cases like mandating bash 3.2 that we don't even have in tree anymore, There is =app-shells/bash-3.2_p51 in the Portage tree. Fun facts: It is in unstable branch. So while I write ebuilds I have to code against an unstable bash version which people only use for experimenting. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSDCbWAAoJEFpvPKfnPDWzb6EH/0w+kHYU9B0KiEWqnafKgZxH TVeExr0bNHxTPfoiewDHbWST57uipVnjCTYYpOA2KzD8gZUadT4P6Aq0Mgw/sb6B IhzT5toJHvi/dmR1DXZzn0S9QM/K0BASffmIUERlCl8ddHMa+UtrYk8dOUjd6HWX iPt5SfNMx7VN/o//XEAcpDeKrnDJ0Hhs0FCcfXh45057FL4wz6mu8oYnPhgQyX+N dmLhRmUIDXWmzaDWSCZJVicBevGMMqH6qBZZ4J8EffPjby64NayKdpZTeTr6FOtJ xfQAQJ4CY1TQo8JGk0ku4J5fvXofTa2agbbUrMqfZn+xSwCYqWreKPTOF+DcsJM= =v/UB -END PGP SIGNATURE-
Re: [gentoo-dev] punt PMS
On 08/15/2013 02:52 AM, Tom Wijsman wrote: On Thu, 15 Aug 2013 02:13:07 +0200 hasufell hasuf...@gentoo.org wrote: I have no idea what that means. Global changes are _always_ discussed in the community. PMS doesn't add anything to that process. It puts the consensus and / or decisions in one canonical categorized resource, such that you don't have to search ages in archives to gather all the pieces together; where would they otherwise be placed? PMS avoids us from having to manually solve an unnecessary puzzle. That sounds interesting in theory, in practice it's the other way around. We solve puzzles to avoid PMS or reverse-fix it.
Re: [gentoo-dev] Changes in libreoffice ebuild
On 14/08/13 17:56, Peter Stuge wrote: Luca Barbato wrote: [3] https://wiki.documentfoundation.org/Development/gerrit And all boils down to the fact gerrit needs to be fixed to take patches from a mailing list Usually Gerrit just needs an OpenID in order to accept git push via SSH. That seems significantly better to me than parsing emails. # git-way: git commit ... git send-email -10 --compose --to patc...@project.org # gerrit-way: Register with gerrit Install the magic gerrit commit hooks OR Figure out how you should push your try ## Then we have feedbacks and we want to provide updates # git-way: Read the email comments git rebase -i git send-email -8 --compose --in-reply-to --to patc...@project.org # gerrit-way Follow the links to the website with the comments. Read the documentation again since you will forget how to push stuff in gerrit, hope the commit hook you have manages the rebase and push again. --- Gerrit probably can be nice if you are used to it, you always have a browser open and you do not have a wast mean to move from your mail client to your git (people with emacs would explain better, I use vim and thunderbird and yet I'm quicker in addressing projects using the git email approach than those that use gerrit. lu
Re: [gentoo-dev] Sets in the tree
On Thu, 15 Aug 2013 07:50:16 +0800 Patrick Lauer patr...@gentoo.org wrote: Because if you want to allow multiple package managers as an option, If - but why would we do that? To give our users choice. http://www.gentoo.org/main/en/about.xml http://www.gentoo.org/main/en/philosophy.xml http://www.gentoo.org/doc/en/faq.xml#differences Gentoo is a meta distribution. then you need to have a clearly defined spec for them. The fact that portage implemented something that is not part of PMS, is not a PMS problem. It is a problem in the cases where portage had a feature *before* PMS was defined, and then PMS tries to ignore it (see my last mail) Is it? Portage can still be PMS compliant as long as that feature is not in conflict with the PMS; that is, if it doesn't override a particular specification that is made in the PMS. The problem you perceive is not really Portage, but it rather has to do with the Portage tree; it is whether the Portage tree needs to be entirely PMS compliant that matters here. If it wasn't, then you could just use the feature; but as you see now, we can't due to this. Of course you can interpret this as an intermediate step as Portage == Portage tree == PMS and shorten it as the feature needing to be in the PMS; but well, it just makes me wonder if there's a way to have PM specific features in the Portage tree or perhaps even better in a separate tree. If there is it would break the chain and this wouldn't be a problem. But then the big question is whether we will want to do that? (Not that I want to suggest this myself, it is a brainstorm thought) It is a problem when PMS does not define the configuration, so two PMS-compatible programs can arrive at opposite results for any operation. (Why does PMS not define config? Well, then paludis would have a problem) Because the PMS is the interface with the Portage tree, not with the configuration on the system; it is not possible for such programs to arrive at opposite results for behaviors listed in the PMS. Theoretically, you can write a PM that does crazy non-sense; but why would you want to write that, and how at all is it a problem to you? So unless it becomes part of PMS, it can't be used in places where you expect PMS compliance. Unless PMS reflects reality it serves no purpose but ego stroking and supressing deviant ideas that some people call progress Please read my response to that two of my mails ago in this sub thread; there is no such thing as reflecting reality, rather, you define it. The order in which things are done is Idea - Discussion - Consensus - Specification - Implementation and if you would reflect reality then you would swap the last three around which doesn't make sense, if you don't have a consensus and therefore no specification; then why would it already be implemented? If you want PMS to go away, and call portage the one-and-true PM for Gentoo, then it's probably something for the Council to decide. De facto it is like that - if it doesn't work with portage it gets fixed, masked and/or removed. That is just a false perception, the PMS is a QA project as seen on http://www.gentoo.org/proj/en/qa/ http://www.gentoo.org/proj/en/qa/pms.xml and therefore its rationale applies; which means that as a matter of QA they expect it to work with the PMS in the first instance, and not so much with Portage in specific. So, this leads to the following QA words: This document aims to address both of these concerns by defining almost all aspects of what an ebuild repository looks like, and how an ebuild is allowed to behave. It is the PMS that addresses this, not Portage; although of course, Portage is such a reference implementation, but other PMs are as well; if a package can be shown to have PMS or QA issues, it indeed needs to get fixed, masked and / or removed. These occasions stem very much with doesn't work with Portage because Portage implements the PMS. Using anything else might work, or not, but it also removes you from support (e.g. #gentoo, bugs.gentoo.org (any maintainer is free to ignore or RESO INVA bugs that are not filed with portage) and so on) Indeed, the developer is free to close bugs as invalid if the reported PMS or QA issue is likely a false positive; even when that is Portage. Claiming that the absence of a written policy invalidates reality is a rather amusing theory that makes little sense Policies are based on consensus, consensus are based on discussion; if you can not point me to a discussion with a clear consensus, then you can not make a claim in either direction. Don't make assumptions... -- 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] punt PMS
On Thu, 15 Aug 2013 02:56:18 +0200 hasufell hasuf...@gentoo.org wrote: On 08/15/2013 02:52 AM, Tom Wijsman wrote: On Thu, 15 Aug 2013 02:13:07 +0200 hasufell hasuf...@gentoo.org wrote: I have no idea what that means. Global changes are _always_ discussed in the community. PMS doesn't add anything to that process. It puts the consensus and / or decisions in one canonical categorized resource, such that you don't have to search ages in archives to gather all the pieces together; where would they otherwise be placed? PMS avoids us from having to manually solve an unnecessary puzzle. We solve puzzles to avoid PMS or reverse-fix it. Unnecessary puzzle solving takes a very long time and delays progress. -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 15 Aug 2013 02:54:46 +0200 hasufell hasuf...@gentoo.org wrote: On 08/15/2013 02:48 AM, Tom Wijsman wrote: Multiple cases like mandating bash 3.2 that we don't even have in tree anymore, There is =app-shells/bash-3.2_p51 in the Portage tree. Fun facts: It is in unstable branch. Stabilization has nothing to do with the PMS. So while I write ebuilds I have to code against an unstable bash version which people only use for experimenting. No, that's called testing; without it, you delay stabilization. Experiments should be masked or one one or another overlay... - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBAgAGBQJSDDF4AAoJEJWyH81tNOV9xf0H/2kGIBmocTbfbIrCByGnyJyw c5wepxHLYCSJYKJWuHgZqTP9zb8QhU8INe3qlmaWJOXDcjtHd+QpzW/21TORngjU +Ea+SVFf0h+7jSmSZ/qDUXZSGBKSgTxoPkDGVOFK+/u8qJdNg0QVHM4TzMkYG2cl 0aW8lrgac5uRC+07g25HOQRKIVCm2UNiziRERV5j5NekG4lm1sk0iyjbAXrem/fP mnsAt1/UCBtBptIDKoc0sXFpTOIgoII3j66RshyzRbpVmihB+M+CLCimKlNl+UUE KBilnDJfH2PbpQji1GjJxoBFNQL+xDxrbB8DW0yozv/2uIEG8zjobDWU6lAtlCs= =aQ49 -END PGP SIGNATURE-
[gentoo-portage-dev] [PATCH 0/3] Implement a more verbose User-Agent HTTP-header
From: W-Mark Kubacki wm...@hurrikane.de Before this patch series Portage identified itself as Gentoo Portage Now it will be the output of ```emerge --version```, i.e.: Gentoo 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 longer string makes debugging easier and helps deciding when to deploy changes on the Gentoo binhost's side. W-Mark Kubacki (3): Send exact version with User-Agent HTTP-header Send output of ```emerge --version``` as User-Agent HTTP-header Add CPU model name to output of getportageversion as fifth element pym/_emerge/actions.py | 4 +++- pym/portage/dbapi/bintree.py | 8 +++- pym/portage/util/_urlopen.py | 5 +++-- 3 files changed, 13 insertions(+), 4 deletions(-) -- 1.8.3.2
[gentoo-portage-dev] [PATCH 2/3] Send output of ```emerge --version``` as User-Agent HTTP-header
From: W-Mark Kubacki wm...@hurrikane.de
The remote server logs will read like this:
2001:db8::4 - - [14/Aug/2013:20:58:02 +0200]
GET /Packages HTTP/1.1 304 0 -
Gentoo 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)
This will enable administrators to…
• check if a machine uses the correct binhost
• decide when new server-side features can be enabled (Portage ver.)
• notify the machine's administrator of malconfigurations
(such as wrong GCC libraries, profile, obsolete kernel)
Construction of this header happens before Packages are fetched
from a remote binhost.
Signed-off-by: W-Mark Kubacki wm...@hurrikane.de
---
pym/portage/dbapi/bintree.py | 8 +++-
pym/portage/util/_urlopen.py | 4 ++--
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/pym/portage/dbapi/bintree.py b/pym/portage/dbapi/bintree.py
index 61ac6b5..44ee8e6 100644
--- a/pym/portage/dbapi/bintree.py
+++ b/pym/portage/dbapi/bintree.py
@@ -20,6 +20,7 @@ portage.proxy.lazyimport.lazyimport(globals(),
'portage.util.listdir:listdir',
'portage.util._urlopen:urlopen@_urlopen',
'portage.versions:best,catpkgsplit,catsplit,_pkg_str',
+ '_emerge.actions:load_emerge_config,getportageversion',
)
from portage.cache.mappings import slot_dict_class
@@ -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)
try:
- f = _urlopen(url,
if_modified_since=local_timestamp)
+ f = _urlopen(url,
user_agent=user_agent,
+
if_modified_since=local_timestamp)
if hasattr(f, 'headers') and
f.headers.get('timestamp', ''):
remote_timestamp =
f.headers.get('timestamp')
except IOError as err:
diff --git a/pym/portage/util/_urlopen.py b/pym/portage/util/_urlopen.py
index 798e7b4..9876f29 100644
--- a/pym/portage/util/_urlopen.py
+++ b/pym/portage/util/_urlopen.py
@@ -26,7 +26,7 @@ if sys.hexversion = 0x300:
# and the file-'mtime'
TIMESTAMP_TOLERANCE=5
-def urlopen(url, if_modified_since=None):
+def urlopen(url, user_agent=None, if_modified_since=None):
parse_result = urllib_parse.urlparse(url)
if parse_result.scheme not in (http, https):
return _urlopen(url)
@@ -35,7 +35,7 @@ def urlopen(url, if_modified_since=None):
url = urllib_parse.urlunparse((parse_result.scheme, netloc,
parse_result.path, parse_result.params, parse_result.query,
parse_result.fragment))
password_manager =
urllib_request.HTTPPasswordMgrWithDefaultRealm()
request = urllib_request.Request(url)
- request.add_header('User-Agent', 'Gentoo Portage '+VERSION)
+ request.add_header('User-Agent', user_agent or 'Gentoo Portage
'+VERSION)
if if_modified_since:
request.add_header('If-Modified-Since',
_timestamp_to_http(if_modified_since))
if parse_result.username is not None:
--
1.8.3.2
[gentoo-portage-dev] [PATCH 1/3] Send exact version with User-Agent HTTP-header
From: W-Mark Kubacki wm...@hurrikane.de
Signed-off-by: W-Mark Kubacki wm...@hurrikane.de
---
pym/portage/util/_urlopen.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/pym/portage/util/_urlopen.py b/pym/portage/util/_urlopen.py
index 768ccb8..798e7b4 100644
--- a/pym/portage/util/_urlopen.py
+++ b/pym/portage/util/_urlopen.py
@@ -6,6 +6,7 @@ import sys
from datetime import datetime
from time import mktime
from email.utils import formatdate, parsedate
+from portage import VERSION
try:
from urllib.request import urlopen as _urlopen
@@ -34,7 +35,7 @@ def urlopen(url, if_modified_since=None):
url = urllib_parse.urlunparse((parse_result.scheme, netloc,
parse_result.path, parse_result.params, parse_result.query,
parse_result.fragment))
password_manager =
urllib_request.HTTPPasswordMgrWithDefaultRealm()
request = urllib_request.Request(url)
- request.add_header('User-Agent', 'Gentoo Portage')
+ request.add_header('User-Agent', 'Gentoo Portage '+VERSION)
if if_modified_since:
request.add_header('If-Modified-Since',
_timestamp_to_http(if_modified_since))
if parse_result.username is not None:
--
1.8.3.2
[gentoo-portage-dev] [PATCH 3/3] Add CPU model name to output of getportageversion as fifth element
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! The former output is not sufficient to tell if a machine has been downgraded (i.e. 3rd gen. Core i7 running a configuration for x86 Pentium Celeron) or to distinguish between i.e. ARM CPUs (arm5tel could be a lot, including incompatible instruction sets). Signed-off-by: W-Mark Kubacki wm...@hurrikane.de --- pym/_emerge/actions.py | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/pym/_emerge/actions.py b/pym/_emerge/actions.py index 52ceba4..e1873cd 100644 --- a/pym/_emerge/actions.py +++ b/pym/_emerge/actions.py @@ -3017,9 +3017,11 @@ def getportageversion(portdir, _unused, profile, chost, vardb): gccver = getgccversion(chost) unameout=platform.release()+ +platform.machine() + cpu_model_name=platform.processor() return Portage %s (%s, %s, %s, %s) % \ - (portage.VERSION, profilever, gccver, ,.join(libcver), unameout) + (portage.VERSION, profilever, gccver, ,.join(libcver), unameout, + cpu_model_name) def git_sync_timestamps(portdb, portdir): -- 1.8.3.2
