Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
On Sat, 28 Apr 2012 16:44:57 -0700
Luca Barbato wrote:
> On 10/04/12 11:45, William Hubbs wrote:
> > There are binaries in /{bin,sbin} which link against libraries in
> > /usr/lib for example.
>
> We could try to have an exact list and figure out exactly what is it
> and how impacting it is. If any of those are needed for early-boot it
> would be something to address nonetheless.
I have already opened bugs for many of them. But the list will increase
in time, and we'll either move a lot of libraries to /lib* or decide to
go the other way.
Did someone mentioned mentioning two cross-linked program/data trees
(well, three or four in our case) with fuzzy classification rules is
against KISS?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] Re: New license: yEd Software License Agreement
Alec Warner posted on Sat, 28 Apr 2012 11:53:03 -0700 as excerpted: > On Fri, Apr 27, 2012 at 12:02 PM, Rich Freeman wrote: >> I'd argue that it is impossible to "accept a license" in the >> first place. It is possible to agree to a contract if there is >> consideration on both sides and a meeting of the minds. > > That doesn't mean you didn't / cannot accept, merely that some (all?) > provisions are likely unenforceable in a court of law. I don't think > EULAs have been ruled illegal yet. > >> Copyright says you can't copy something. A license says you might be >> able to. You don't have to "accept" a license to benefit it. A >> license does not restrict what a user can do, it restricts what the >> person issuing the license can do (I can't sue you for redistributing >> my code if I licensed it to you under the GPL). Some licenses are >> conditional - I only limit my own ability to sue you if you give people >> a copy of the source for any binary you give them, and if you don't do >> that I am now free to sue you. > > Have you read the yEd license? I mean it does restrict what users can > do: > "The Software may not be used as part of an automated process. The > Licensee may not reverse engineer, disassemble, decompile, or unjar > the Software, or otherwise attempt to derive the source code of the > Software." > > How is that not restricting what the end user can do? I believe he's viewing it in the context many explanations of the the GPL take pains to explain, namely: Since copyright law prohibits copying (and in some cases, reading into computer memory for purposes of execution has been held to be copying in the context of copyright as well!!) without permission in the first place, it is as rich0 says, COPYRIGHT law that default-forbids doing anything at all with that string of binary data that happens to form the software. As rich0 further points out, licenses modify that default-no state to allow the user some privileges they'd otherwise be denied by copyright law. Many of them, including the GNU General Public License (GPL) and the yEd license, do so conditionally. They allow the privileges IF AND ONLY IF certain conditions are met. In the case of the GPL, these conditions, only apply to distributors, mere end-users are free and clear of all such conditions as long as they don't redistribute to others. Further, the conditions on distributors are designed to ensure that end users of any derived programs get the same rights from the folks that distribute it to them. In the case of most EULAs including the yEd license, by contrast, distribution is simply reserved as a right to the owning company (separate agreements are needed for distribution rights), and permission to copy and use the work under copyright is granted to the end-user only under rather severe conditions. But from the viewpoint of copyright, it's simply an agreement by the owner to give you permission to copy and use under certain stated conditions, thus limiting their right to sue, but only to the extent that you're in compliance with the (in the case of most EULAs, conditional to an extreme) license (which is itself limited by laws that grant various "fair use" rights that differ by jurisdiction). Thus, by this view, a EULA isn't limiting to the user, because all it's doing is granting (perhaps conditional) rights that would otherwise be reserved to the copyright owner only, under copyright law. Someone can thus choose not to be subject to the license, or simply to ignore it entirely. That's fine as long as they aren't doing something that copyright says they can be sued for. But if they are doing something copyright says they could be sued for, and they draw the attention of the owner and/or their legal representatives, then to the extent that the license allows it, it's in their interest to claim the legal coverage of the license to prevent being sued by that owner/owner-representative. Which is what makes relatively liberal licenses such as the GPL so strong. Since they allow so much, with relatively light conditions, it's very strongly in the interest of parties who might otherwise be sued to comply with the GPL instead. With rather more restrictive EULAs, not so much, since the EULA has such strict conditions. In that case, it's far harder to comply with and far more likely that a copyright violator will be violating the EULA's conditions as well, so claiming the protections of the license doesn't tend to help as much, except to the extent that there really is a disagreement about the conditions of said license. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
On 10/04/12 11:45, William Hubbs wrote:
> Also, I am going to reiterate what Greg said. This is not an issue with
> udev, but with the entire linux ecosystem.
As in bluez using dbus and some mount helpers requiring libraries in /usr.
> There are binaries in /{bin,sbin} which link against libraries in
> /usr/lib for example.
We could try to have an exact list and figure out exactly what is it and
how impacting it is. If any of those are needed for early-boot it would
be something to address nonetheless.
> Also, with the appropriate documentation changes, which are being worked
> on (see [1]), I feel that the statement above that newer udev can't be
> stabled should be re-evaluated.
lu
--
Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force
On 04/28/2012 02:17 PM, Mike Frysinger wrote:
> On Friday 27 April 2012 03:30:43 Zac Medico wrote:
>> On 04/26/2012 11:48 PM, Zac Medico wrote:
>>> On 04/26/2012 11:28 PM, Mike Frysinger wrote:
On Friday 27 April 2012 00:43:15 Jonathan Callen wrote:
> On 04/26/2012 06:03 PM, Andreas K. Huettel wrote:
>> I'd like to suggest we introduce the following very useful
>> feature, as soon as possible (which likely means in the next
>> EAPI?):
>>
>> * two new files in profile directories supported,
>> package.use.stable.mask and package.use.stable.force * syntax is
>> identical to package.use.mask and package.use.force * meaning is
>> identical to package.use.mask and package.use.force, except that
>> the resulting rules are ONLY applied iff a stable keyword is in
>> use
>
> As "a stable keyword is in use" is either ambiguous or outright wrong
> (depending on exactly what was meant by that), I would propose that
> one of the following cases replace that:
>
> * At least one keyword beginning with "~" or the value "**" is in the
> global ACCEPT_KEYWORDS.
> * At least one keyword beginning with "~" or the value "**" is in the
> ACCEPT_KEYWORDS used for the package in question.
>
> This is required because on a typical ~amd64 system, the effective
> value of ACCEPT_KEYWORDS is "amd64 ~amd64" -- which would be covered
> under "a stable keyword is in use" (the same applies for other arches
> as well).
i don't think that wording is correct and misses the point. simple
example of how this should work:
if package.use.stable.force has:
cat/pkg foo
and then cat/pkg/pkg-0.ebuild has:
KEYWORDS="~amd64 x86"
the forcing of "foo" would apply to people who are ARCH=x86 (regardless
of their ACCEPT_KEYWORDS containing ~x86), but not apply to people who
are ARCH=amd64. once the ebuild changes to KEYWORDS="amd64 x86", then
it would apply to both.
i.e. the keyword matching is to the ebuild, not to the user's
ACCEPT_KEYWORDS.
>>>
>>> That makes sense in the context of trying to keep repoman from
>>> complaining. Since repoman complains about stable keywords for packages
>>> with unstable dependencies, package.use.stable.{force,mask} will serve
>>> to mask off conditional dependencies that would otherwise trigger
>>> *DEPEND.bad complaints from repoman.
>>
>> Actually, I don't think the specification should involve ARCH. In order
>> to determine whether package.use.stable.{force,mask} apply, I would
>> intersect KEYWORDS with ACCEPT_KEYWORDS, and apply
>> package.use.stable.{force,mask} if this intersection contains only
>> stable keywords. So, I think that I mostly agree with Jonathan's
>> statements, though I describe the behavior slightly differently than how
>> he did.
>
> wrt repoman, it doesn't know anything about ACCEPT_KEYWORDS
It does know about ACCEPT_KEYWORDS because it generates them
automatically from KEYWORDS. The relevant code in /usr/bin/repoman looks
like this:
arches=[]
for keyword in myaux["KEYWORDS"].split():
if (keyword[0]=="-"):
continue
elif (keyword[0]=="~"):
arches.append([keyword, keyword[1:], [keyword[1:], keyword]])
else:
arches.append([keyword, keyword, [keyword]])
if not arches:
# Use an empty profile for checking dependencies of
# packages that have empty KEYWORDS.
arches.append(['**', '**', ['**']])
> as for intersection, i don't think that works. if my make.conf is:
> ACCEPT_KEYWORDS="amd64 ~amd64"
> and i emerge a package that has:
> KEYWORDS="~amd64"
>
> package.use.stable should not apply to this package. it should only apply if
> it had:
> KEYWORDS="amd64"
See the algorithm that I've described here:
http://archives.gentoo.org/gentoo-dev/msg_6c492ae43ad7c70cef6aa8ac34911adf.xml
The case that you're talking about is equivalent to the 4th row of the
table in that message, and note that it says "no" in the package.stable
column, as you would expect.
--
Thanks,
Zac
Re: [gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force
On Friday 27 April 2012 03:30:43 Zac Medico wrote:
> On 04/26/2012 11:48 PM, Zac Medico wrote:
> > On 04/26/2012 11:28 PM, Mike Frysinger wrote:
> >> On Friday 27 April 2012 00:43:15 Jonathan Callen wrote:
> >>> On 04/26/2012 06:03 PM, Andreas K. Huettel wrote:
> I'd like to suggest we introduce the following very useful
> feature, as soon as possible (which likely means in the next
> EAPI?):
>
> * two new files in profile directories supported,
> package.use.stable.mask and package.use.stable.force * syntax is
> identical to package.use.mask and package.use.force * meaning is
> identical to package.use.mask and package.use.force, except that
> the resulting rules are ONLY applied iff a stable keyword is in
> use
> >>>
> >>> As "a stable keyword is in use" is either ambiguous or outright wrong
> >>> (depending on exactly what was meant by that), I would propose that
> >>> one of the following cases replace that:
> >>>
> >>> * At least one keyword beginning with "~" or the value "**" is in the
> >>> global ACCEPT_KEYWORDS.
> >>> * At least one keyword beginning with "~" or the value "**" is in the
> >>> ACCEPT_KEYWORDS used for the package in question.
> >>>
> >>> This is required because on a typical ~amd64 system, the effective
> >>> value of ACCEPT_KEYWORDS is "amd64 ~amd64" -- which would be covered
> >>> under "a stable keyword is in use" (the same applies for other arches
> >>> as well).
> >>
> >> i don't think that wording is correct and misses the point. simple
> >> example of how this should work:
> >>
> >> if package.use.stable.force has:
> >>cat/pkg foo
> >>
> >> and then cat/pkg/pkg-0.ebuild has:
> >>KEYWORDS="~amd64 x86"
> >>
> >> the forcing of "foo" would apply to people who are ARCH=x86 (regardless
> >> of their ACCEPT_KEYWORDS containing ~x86), but not apply to people who
> >> are ARCH=amd64. once the ebuild changes to KEYWORDS="amd64 x86", then
> >> it would apply to both.
> >>
> >> i.e. the keyword matching is to the ebuild, not to the user's
> >> ACCEPT_KEYWORDS.
> >
> > That makes sense in the context of trying to keep repoman from
> > complaining. Since repoman complains about stable keywords for packages
> > with unstable dependencies, package.use.stable.{force,mask} will serve
> > to mask off conditional dependencies that would otherwise trigger
> > *DEPEND.bad complaints from repoman.
>
> Actually, I don't think the specification should involve ARCH. In order
> to determine whether package.use.stable.{force,mask} apply, I would
> intersect KEYWORDS with ACCEPT_KEYWORDS, and apply
> package.use.stable.{force,mask} if this intersection contains only
> stable keywords. So, I think that I mostly agree with Jonathan's
> statements, though I describe the behavior slightly differently than how
> he did.
wrt repoman, it doesn't know anything about ACCEPT_KEYWORDS
as for intersection, i don't think that works. if my make.conf is:
ACCEPT_KEYWORDS="amd64 ~amd64"
and i emerge a package that has:
KEYWORDS="~amd64"
package.use.stable should not apply to this package. it should only apply if
it had:
KEYWORDS="amd64"
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012
On Wednesday 11 April 2012 12:10:05 Steven J Long wrote:
> William Hubbs wrote:
> > Another issue to consider is binaries that want to access things in
> > /usr/share/*. If a binary in /{bin,sbin} needs to access something in
> > /usr/share/*, you have two choices. move the binary to /usr or move the
> > thing it wants to access to / somewhere which would involve creating
> > /share. Actually there is another choice, but I don't want to go there.
> > That would be writing patches.
>
> I'm ignorant of which binaries do that?
off the top of my head:
- this is why /etc/localtime is no longer a symlink to
/usr/share/zoneinfo/
- this is why we have copies for a few terminals in /etc/terminfo from
/usr/share/terminfo/ ... hopefully the one you're using is listed there
- this is why we have to delay running keymap and consolefont init.d
scripts until after /usr has been mounted (/usr/share/keymaps
/usr/share/consolefont /usr/share/consoletrans)
- anything locale related doesn't work until /usr is mounted
(/usr/lib/locale /usr/share/locale)
- passwd changing relying on cracklib dicts won't work
(/usr/lib/cracklib_dict* /usr/share/misc/)
> (It's understood that you might not
> have manpages in rescue-mode.) OT, it's odd that nano is in /usr/bin but on
> my system at least it only links to /lib64.
/usr/bin/nano is a symlink
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: New license: yEd Software License Agreement
On Sat, Apr 28, 2012 at 2:53 PM, Alec Warner wrote: > That doesn't mean you didn't / cannot accept, merely that some (all?) > provisions are likely unenforceable in a court of law. I don't think > EULAs have been ruled illegal yet. I doubt that my proclamation that you aren't allowed to eat breakfast has been ruled illegal yet either. Fortunately that has no bearing on whether you need to listen to me. :) Oh, and I also proclaim that you accept my proclamation by choosing to eat your next meal. Fortunately in reality that has no bearing on whether you accept my agreement either. Just because a publisher says that the terms of a contract of adhesion are binding on you by virtue of your taking some action does not make it so. Courts have ruled inconsistently on whether EULAs can be enforced. Then again, Missouri is one of those places where courts have ruled that software is not sold but licensed, and the Foundation is incorporated there (as well as in New Mexico). So, perhaps there is some element of risk here, though I'd have to read the court decisions to see whether the fact that the software is free impacts the enforcability of the EULA. That makes me wonder whether we should consider more carefully where we incorporate - if it makes us more subject to local jurisdiction it probably isn't a good idea to incorporate in multiple jurisdictions since it allows a potential plaintiff to venue shop. Rich
Re: [gentoo-dev] Re: eselect git repo
On 28/04/12 08:44, Ulrich Mueller wrote: >> On Thu, 26 Apr 2012, I wrote: > >> Just a heads up, lu_zero has discovered that the eselect git >> repository contains some commits with invalid author lines. This is >> a holdover from the conversion from svn to git (basically, the real >> name is missing for devs who changed their Gentoo username). I'm >> going to fix this within the next few days, but I believe this means >> that the history will change. > >> So, please don't push to the eselect repo until I give the >> all-clear. > > To the best of my knowledge, the repo should be fixed now. Please note > that the history has changed. So either do a fresh git clone or follow > git-rebase(1), section "RECOVERING FROM UPSTREAM REBASE". > Thank you a lot =) lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Re: Gentoostats, SoC 2011
On 04/27/2012 06:34 PM, Nikos Chantziaras wrote: > On 23/08/11 00:20, Vikraman wrote: >> Hi all, >> >> Gentoostats[0] is a GSoC 2011 project to collect package statistics >> from gentoo >> machines. Please check it out. Bug reports and feature suggestions are >> welcome. >> >> To submit your stats, use the app-portage/gentoostats ebuild from >> betagarden >> overlay[1]. >> >> [0] https://soc.dev.gentoo.org/gentoostats/ >> [1] https://soc.dev.gentoo.org/gentoostats/about > > Is this project dead now? > > Hi, The project is not dead. As part of GSoC 2012 I will be working on improving gentoostats. I'll post an official announcement here in the very near future. If you have any questions and/or ideas about the project please don't hesitate to get in touch with me. Regards, G. Gaydarov
[gentoo-dev] Last rites: dev-python/xsv
# Kacper Kowalik (28 Apr 2012) # No longer maintained upstream, superseeded by # dev-python/lxml, bug 396497 # Masked for removal in 30 days. dev-python/xsv signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: New license: yEd Software License Agreement
On Fri, Apr 27, 2012 at 12:02 PM, Rich Freeman wrote: > On Fri, Apr 27, 2012 at 2:04 PM, Nikos Chantziaras wrote: >> Didn't the user already accept the license by putting it in ACCEPT_LICENSE? >> If not, portage will not download it. >> > > Well, I'd argue that it is impossible to "accept a license" in the > first place. It is possible to agree to a contract if there is > consideration on both sides and a meeting of the minds. That doesn't mean you didn't / cannot accept, merely that some (all?) provisions are likely unenforceable in a court of law. I don't think EULAs have been ruled illegal yet. > > Copyright says you can't copy something. A license says you might be > able to. You don't have to "accept" a license to benefit it. A > license does not restrict what a user can do, it restricts what the > person issuing the license can do (I can't sue you for redistributing > my code if I licensed it to you under the GPL). Some licenses are > conditional - I only limit my own ability to sue you if you give > people a copy of the source for any binary you give them, and if you > don't do that I am now free to sue you. Have you read the yEd license? I mean it does restrict what users can do: "By installing the Software, the Licensee is indicating that he/she has read and understands this Agreement and agrees to be bound by its terms and conditions." "The Licensee is granted a non-exclusive and non-transferable right to install one copy of the Software and use it as an application. The Software may not be used as part of an automated process. The Licensee may not reverse engineer, disassemble, decompile, or unjar the Software, or otherwise attempt to derive the source code of the Software." How is that not restricting what the end user can do? A court of law could find a number of wiggle areas (what does it mean to 'install the software' for instance, in some countries reverse engineering is fair user and this right cannot be taken away by a license, etc..) > > Ultimately the foundation for licenses is copyright law, and other > forms of IP law. Copyright says we can't distribute anything we don't > create except under very specific circumstances. A license says that > we can distribute stuff without fear of lawsuit under some conditions. I don't think we are talking solely about redistribution rights but also end user rights (EULA.) In this case their license (tries to) cover both aspects. > > The yEd license says we can't distribute anything, so as far as I can > see, we might as well not have any license at all. We're not > protected at all from a lawsuit, except to the degree that we don't do > anything that we can be sued for (like distributing their software). > > But yes, from a technical standpoint you can only install a package if > its license is contained in ACCEPT_LICENSE. Whether this has any > legal meaning is up to you or a court with jurisdiction to decide. Its unclear if ACCEPT_LICENSE actually implies the user read and accepted the EULA; but since the EULA is implicit w/installing the software it is unclear to me (in my lay opinion) if this actually matters. > > Rich >
Re: [gentoo-dev] [RFC] Changing default serial-console definition in inittab
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/28/2012 01:38 AM, Patrick Lauer wrote: > On 04/28/12 01:29, Diego Elio Pettenò wrote: >> Since I've been configuring a couple of systems lately for >> remote access, which include configuring the serial console, I'm >> wondering if it would be a good idea to change our inittab so >> that the default (commented out) definition of the serial >> consoles is a bit more.. modern. >> >> The current definition sets the console at 9600 baud, using >> vt100 emulation; I think most of us who configure it, do so at >> 115200 baud, and some prefer vt-utf8 over vt100 (the two are >> partially compatible as far as I can tell). >> >> Of the two systems I've configured – a SuperMicro server which >> is the new tinderbox host, and an HP for work – both have the >> default IPMI configuration for Serial-over-LAN set at 115200, and >> the HP also had VT-UTF8 by default for emulation (SuperMicro >> defaulted to vt100 but still allows utf8). >> >> Comments? >> > > Leave the old defaults, add an example with the new options? > > Since serial consoles are not default the user will have to > consciously enable them anyway, so there are no "defaults" > > Have fun, > > Patrick > Yeah +1 on that - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJPnDvUAAoJEPqDWhW0r/LCJDwP/0Qn+OwDvZSEbMAto/DzAze0 Y13mXqOljzEg8nkaO7EODXbUdxE8PvVlRhMMyjOTBISFNWV4Y6Bv5jRfb3kx3M+j H8SZdh/SkpHQMyZVaBm2CN8abVpvrewPfyokaesIgDpJZxFYkvN/jP2fjMgZV+gs zLARFdch7yNWx5/a7Qe4GVzCsSP7xZXz/7m2u+jlnRYS+2d1fYjL0i17hqlO8XIC VvIGY7RfAdyFypL7hYa1v6PbBXpT+gUru6dtv0zRXunz/+yHMieq2+J5/JLeivuc K5hI5qRrlMxXcXQRXoTd7glqSjC69mKDJx34po0qiRuFxfIFep9a50X482cGxo2/ qfK+OXLznEjp9bAQdeZaajkXhlGup7HJhGRCZLTTH+9rQpQ5SEvHzh/iOThV4dDU XbW4CHZZxo6B/nNAvN77Wfc82tcXPssozU98Ri4jbZ4psXnanCmtf3MarEdL/EVX CJBa42W2N8FQreCOe0vRtQi8zvK6nuQv5qFVFLpTsct+VpBMHlcvBhb+p4KmFcxw pwtmWCICwoZTaGMO8pTFPCJgjL/YwMMaPFflsu6o6W8K1UQzGUANXaer98BFZavs 8WQ96/Jgl2CFcrZNTnyqqfQfRY6lFS7IO179eAO+49A66nX61FGSRODWnVFeGavK kQ4WxQOjTtPzw9xYgdjM =SDkT -END PGP SIGNATURE-
Re: [gentoo-dev] Re: New license: yEd Software License Agreement
On 2012.04.27 18:38, Rich Freeman wrote: [snip] > Do we as a matter of policy want to respect broken click-through > download implementations? > > Rich > Yes we do. Intent it what counts in the eyes of the law in most places. Sites with broken click-throughs intend for them to be used. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees
[gentoo-dev] Re: eselect git repo
> On Thu, 26 Apr 2012, I wrote: > Just a heads up, lu_zero has discovered that the eselect git > repository contains some commits with invalid author lines. This is > a holdover from the conversion from svn to git (basically, the real > name is missing for devs who changed their Gentoo username). I'm > going to fix this within the next few days, but I believe this means > that the history will change. > So, please don't push to the eselect repo until I give the > all-clear. To the best of my knowledge, the repo should be fixed now. Please note that the history has changed. So either do a fresh git clone or follow git-rebase(1), section "RECOVERING FROM UPSTREAM REBASE". (And apologies for the spam in #gentoo-commits. I hadn't expected that all these commits would be reported to cia.vc, otherwise I'd have asked infra to temporarily disable it in the commit hook.) Ulrich
Re: EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)
On Sat, 28 Apr 2012 10:09:01 + Francesco Riosa wrote: > What's changed from 2006 in version handling? The ordering rules, the handling of zeroes and the behaviour of suffixes. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Lastrite app-text/chmsee. Semi-lastrite libopensync-plugin-google-calendar.
On Sat, 28 Apr 2012 12:17:55 +0200 Michael Weber wrote: > Is there any state-of-the-art(tm) alternative to read .chm ebooks? I > wouldn't want to loose this possibility. The one and only FBReader? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Lastrite app-text/chmsee. Semi-lastrite libopensync-plugin-google-calendar.
On 28 April 2012 18:17, Michael Weber wrote: > Is there any state-of-the-art(tm) alternative to read .chm ebooks? I > wouldn't want to loose this possibility. app-text/kchmviewer
Re: [gentoo-dev] Lastrite app-text/chmsee. Semi-lastrite libopensync-plugin-google-calendar.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 According to upstreams homepage [1], the current tagged v1.99.09 does support xulrunner 11.0. @dirtyepic: Any chance to bump the version in portage? I can take a look (and grab this package). Is there any state-of-the-art(tm) alternative to read .chm ebooks? I wouldn't want to loose this possibility. Thanks, Michael [1] http://code.google.com/p/chmsee/ On 04/22/2012 08:21 AM, Samuli Suominen wrote: > # Samuli Suominen (22 Apr 2012) # One of the > last packages still using the obsolete pyxml package # Masked for > removal in 30 days wrt bug 367739 > > # Samuli Suominen (22 Apr 2012) # Masked for > removal in 30 days for using the obsolete xulrunner # package wrt > #412875 and #403415 app-text/chmsee > - -- - -- Gentoo Dev http://xmw.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk+bw9MACgkQknrdDGLu8JA92AD+OX0PrpAfmeBnYTZX2N50FKPb eWM/uueFFhBS9EFQxvUA/0vZkVfz2G/wdx7q9SQ8Vzx3ImomMbyOJc1iWn7lofxe =IzMJ -END PGP SIGNATURE-
Re: EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)
What's changed from 2006 in version handling? Il giorno 28/apr/2012 11:39, "Ciaran McCreesh" < ciaran.mccre...@googlemail.com> ha scritto: > > On Sat, 28 Apr 2012 10:52:07 +0200 > Michał Górny wrote: > > On Fri, 27 Apr 2012 21:12:27 +0100 > > Ciaran McCreesh wrote: > > > * Get a versionator replacement into the PM > > > > Why are we trying to make PM a brick instead of keeping stuff modular? > > What does the eclass lack which could be provided by PM? > > Because trying to parse version formats correctly in bash is a huge > pain, and versionator doesn't get it right (never mind that the rules > were different when versionator was written). > > -- > Ciaran McCreesh What's changed from 2006 in version handling?
Re: EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)
On Sat, 28 Apr 2012 10:52:07 +0200 Michał Górny wrote: > On Fri, 27 Apr 2012 21:12:27 +0100 > Ciaran McCreesh wrote: > > * Get a versionator replacement into the PM > > Why are we trying to make PM a brick instead of keeping stuff modular? > What does the eclass lack which could be provided by PM? Because trying to parse version formats correctly in bash is a huge pain, and versionator doesn't get it right (never mind that the rules were different when versionator was written). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)
On Fri, 27 Apr 2012 21:12:27 +0100 Ciaran McCreesh wrote: > * Get a versionator replacement into the PM Why are we trying to make PM a brick instead of keeping stuff modular? What does the eclass lack which could be provided by PM? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: EAPI 5 (Was: Re: [gentoo-dev] Re: Making user patches globally available)
El vie, 27-04-2012 a las 21:12 +0100, Ciaran McCreesh escribió: > On Fri, 27 Apr 2012 21:58:24 +0200 > Michał Górny wrote: > > Of course, if we take the 'quick EAPI 5 route', it won't include > > anything useful. In the meantime, do we have a complete list of > > candidates for EAPI 5? > > Let's continue this on the PMS list. > > * user patches > > * EAPI parsing > > * the things that were left out of 4: > > + slot operator deps > > + profile IUSE > > * No -j1 for src_test > > * Remove deprecated stuff > > * Zero or one REQUIRED_USE operator > > These might be cheap now? > > * New bash version > > * Get a versionator replacement into the PM > Could: https://bugs.gentoo.org/show_bug.cgi?id=408693 be handled also? Thanks signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: dev-ruby/facets
# Hans de Graaff (28 Apr 2012) # History of broken code, new releases use a test system # that does not work itself and has many new dependencies. # Current stable version blocks rubygems stabilization. # No reverse dependencies. # Masked for removal in 30 days. =dev-ruby/facets signature.asc Description: This is a digitally signed message part
