Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 12 March 2012 15:20, Rich Freeman ri...@gentoo.org wrote: On Sun, Mar 11, 2012 at 10:03 PM, Brian Harring ferri...@gmail.com wrote: Pragmatic reality, the eapi function actually would work fine. As pointed out elsewhere, bash parses as it goes- which isn't going to change. Unless the ebuild isn't written in bash... How do you source the ebuild if you don't know what to use to source it? How do you know what to use to source it if you don't know the EAPI? Right now all the existing EAPIs use bash, but there is no reason the file couldn't be xml, or python, or just about anything else. A convention that is often used in this scenario is to combine a hashbang call with that specific sourcer stripping that hashbang prior to the parse. ie: foo.ebuild: #!/usr/bin/env eapi-xml-5 would send the current file ( foo.ebuild ) to the process eapi-xml-5 ( as defined by the current $PATH setting ) This process can easily then strip the #! stanza before sending the content to an XML parser. ( ps. while I wouldn't actually use XML, its a good example case because standard shell-script style commenting is illegal syntax in XML ) The benefits of this approach seem obvious, but there are also obvious downsides. 1. PRO: Unlike /usr/bin/eapi , this style is PMS Agnostic, and only requires the PMS have a process named eapi-xml-5 *somewhere* in the system under $PATH 2. CON: Unlike /usr/bin/eapi , you're limited by what you can send it , /usr/bin/env eapi xml-5 would be preferable syntax imo, but it doesn't work, because its parsed as [ '/usr/bin/env' , 'eapi xml-5' ] which then yeilds a permission denied due to no command with that name existing. 3. PRO: There's not /much/ risk of a user trying to run it directly, mostly because there's no +x bit 4. CON: This syntax is going to conflict with whatever language we are proceeding, which while this caveat is dealt with by the command that the file is dispatched to, its a lot of work getting everything else to play ball ( editors won't understand, linters wont understand, various other tools that work strictly with the native forms of that language wont understand ) and this problem exists for *every* case where the coding system we're targeting doesn't natively support whatever magic indicators we're trying to stuff in the file. 5. PRO: detecting this notation being used in a file is cheap-ish , you only have to read 2 characters into the file to know its using this notation. As a result of all these, it seems to me if we ever want to support non-bash or non-scripting sources ( ie: YAML, JSON, XML , etc ) or any other language which doesn't support # is a comment , we're going to be pretty much forced to declare the EAPI outside the file somehow. Whether this is via the filename ( yes, I've seen that debate ) or via some other metadata file ( which seems more poison than cure ) would be the real issue. Having to store this in a metadata file that maps *.ebuild to EAPI would seem like a solution that would only increase the filesize of portage, and slow down runtime substantially, unless of course you had a per-repository index that sped this up and was generated during the metadata/ generation phase. Then $PMS could just load that file from each repository , and assuming the cache was still valid, it could easily know the EAPI for any .ebuild it would source in advance. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 12 March 2012 15:24, Alec Warner anta...@gentoo.org wrote: I will stab the next person who suggests 'xml-like ebuilds.' State-fully coded ebuilds, while perhaps not to your liking, for some code-types can be incredibly useful. For example, 9/10 perl-module ebuilds don't need any code at all in the ebuild itself, it could do most of the work via structured data, with the rest of the work done by an e-class. However, bash has serious problems when you want to represent hierarchical data. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/11/2012 11:50 PM, Kent Fredric wrote: #!/usr/bin/env eapi-xml-5 would send the current file ( foo.ebuild ) to the process eapi-xml-5 ( as defined by the current $PATH setting ) All we need is a way for the package manager to probe the EAPI. Spawning a process to do that is just overkill. -- Thanks, Zac
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 12 March 2012 20:08, Zac Medico zmed...@gentoo.org wrote: On 03/11/2012 11:50 PM, Kent Fredric wrote: #!/usr/bin/env eapi-xml-5 would send the current file ( foo.ebuild ) to the process eapi-xml-5 ( as defined by the current $PATH setting ) All we need is a way for the package manager to probe the EAPI. Spawning a process to do that is just overkill. Yeah, but if you read the rest of my message, you'll see my argument that hinges around the fact most proposals so far tend to focus around the fact the current format for ebuild is bash, and bash only, and I think it very hard to implement a language agnostic way to specify the EAPI in a way that will work on languages where you a) Can't use # to mark comments b) May not even be working with the file directly, and perhaps generating a .json file from a data-structure being serialised, and the key named EAPI may be unpredictably placed near the end of the .json file. Case b is entirely plausible, and even realistic, because non-script-based data-structures often don't bear importance on the order of elements. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
Re: [gentoo-dev] Deprecate EAPI1?
El dom, 11-03-2012 a las 13:01 +0100, Pacho Ramos escribió: After reading previous discussion: http://help.lockergnome.com/linux/gentoo-dev-Deprecate-EAPIs--ftopict530567.html Looks like preventing NEW commits from using eapi1 (via repoman) could be done without major issues. This could even being done also for eapi2 as it's close enough to eapi3, but I don't have a strong opinion about eapi2 deprecation (personally, I try to always use latest eapi if eclass allows me to do so). Any thoughts on this? Thanks Well, the reasons for me preferring to not allow *new* ebuilds to use eapi1 is to try to move to use things like, for example, src_prepare/src_configure phases. I guess that phases were included for some technical reasons and, then, I think we should try to use them if possible install of still adding NEW ebuilds using old eapi0/1 way of doing things signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Proposal: New irc data field in layman's repositories.xml file format
On 11 March 2012 22:09, Brian Dolbec dol...@gentoo.org wrote: eg: ircChannel #gentoo-guis on the freenode network/irc or irc#gentoo-guis on the freenode IRC network, irc://irc.gentoo.org/gentoo-guis/irc Though a freeform text field is probably better for humans, I'd suggest having more explicit data available as an option, ie: irc network=irc.freenode.org channel=#gentoo-guisChannel #gentoo-guis on the freenode network/irc This way you can put more behaviour on the display side in whatever UA is processing the XML, for example, you could easily add support for some GUI portage tool to add an IRC button on relevant packages being displayed, that opens the IRC channel listed in the users chosen IRC client ( as configured in the GUI's preferences ). -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Mon, 12 Mar 2012 00:08:46 -0700 Zac Medico zmed...@gentoo.org wrote: On 03/11/2012 11:50 PM, Kent Fredric wrote: #!/usr/bin/env eapi-xml-5 would send the current file ( foo.ebuild ) to the process eapi-xml-5 ( as defined by the current $PATH setting ) All we need is a way for the package manager to probe the EAPI. Spawning a process to do that is just overkill. And we could just use a good regex for that instead. Something like: [eE][aA][pP][iI] whitespace-or-symbols [a-z0-9-+]+ and just require users for this to be the first thing declared in an ebuild. Of course, this could make problems with stuff like: # EAPI 4 because of foobarbaz EAPI=4 (on the other hand, in this particular case it will fetch '4' anyway). And this will work as well with: eapi15-xml/eapi and - eapi: 15-yaml -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Mon, 12 Mar 2012 09:27:11 +0100 Michał Górny mgo...@gentoo.org wrote: eapi15-xml/eapi and - eapi: 15-yaml You're carefully concocting your examples to make it look like it should work. If you go the XML route, though, the EAPI would either be in a DTD or as eapi value=15 /. Part of the point of all of this is that we shouldn't have to guess what future EAPIs will look like. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Sun, Mar 11, 2012 at 09:08:24PM -0700, Zac Medico wrote: On 03/11/2012 06:55 PM, Brian Harring wrote: On Sat, Mar 10, 2012 at 08:06:50AM -0800, Zac Medico wrote: Yeah. Another way of putting it is that the requirement to spawn a bash process and source the ebuild adds a ridiculous amount of unnecessary complexity, in violation of the KISS principle [1]. This statement is incorrect. Even if EAPI could be parsed via some non sourcing approach, we *still* have to source the ebuild to get the metadata for when the EAPI is supported (the vast majority of usage). That complexity is there one way or another- we wouldn't be trying to extract the EAPI from the ebuild unless the cache was invalid/missing. There are a couple of other cases worth considering: 1) User downloads an overlay that doesn't provide cache. We want the package manager to give a pretty EAPI unsupported message, rather than spit out some bash syntax errors. This criticsm pretty much applies *strictly to the existing implementation*. It's disenguous busting it in this fashion. EAPI as a function explicitly gives it an out before hitting any of that, eliminating your entire critique. Same goes for parsing it out of the ebuild, or renaming the extension. 2) You're assuming that a package manager can validate cache for an EAPI that it doesn't necessarily support. Actually, I'm not. That's a somewhat fragile assumption, given the complexities of cache validation, which involve verification all files that affect metadata and those files may vary depending on the EAPI. This is a fair bit of handwavey bullshit. The same complexities of cache validation we have to by default deal with for valid/supported EAPIs; the case for unsupported EAPIs is actually simpler than for supported EAPis, and up until 7ddb7d30, was likely working fine in portage. Tweaking portage to restore that support is pretty easy. Also note that with the sole exception of g55, every implementation has to deal with this specific issue, even g55 isn't fully exempt from it since in cleansing a cache, there is the open question of pruning cache entries for ebuilds known, but not understood by the local PM. Either way, the algo is as follows: PM pulls EAPI from the ebuild (regardless of method); PM recognizes that it can't handle it- thus it stores EAPI:-$EAPI, and the normal cache ebuild checksumming; whether it be mtime, md5 for md5-dict, or whatever form new caches choose to use. For attempts to load, the cache subsystem checks that validation before trusting the cache entry- this is in place and has been for a very, very long time. This isn't anything new. So... the entry point is the ebuild; we have checksums for it, and a prefixed versions of it's EAPI stored. The sole deal breaker here is if we were to decide to allow eclasses to set EAPI (rather than the current you're not supposed to, although we don't explicitly block it- which could be tightened to be disallowed at the implementation level for EAPI4). The following scenarios exist: 1) PM still doesn't support that EAPI, looks at the cache/ebuild: checksums are the same, thus the stored EAPI is trustable, leading to the PM knowing it still can't process that ebuild and masking it appropriately. 2) PM still doesn't support that EAPI, looks, sees that the checksums no longer match the ebuild. Re-pulls metadata/EAPI; if the ebuild has been changed to a supported EAPI, continues on its way. If not, stores the checksum/negated EAPI, and masks appropriately. 3) PM now supports that EAPI, looks, sees the negated eapi and recognizes it as one it knowns, and forces regeneration. All of those scenarios are there, and easy enough to handle- this applies for the existing EAPI implementation additionally. Now, this isn't to say that someone can't go and try to structure new features explicitly to defeat the existing validations. They could. The question here is whether or not new features would actually *break* that w/out intentionally going out of their way to do so (aka, skip the strawman arguments, actual examples required). Phrasing it more bluntly: you can only avoid the sourcing step if you can isolate that the EAPI is unsupported (which is extremely rare in terms of actual user experience). For the rest of the time (well past the 99% mark) sourcing is the immediate step following. For the sake of being robust in all possible cases, it's just a lot simpler if we can obtain the EAPI simply and reliably, without spawning bash to source the ebuild. This still is arguable; any performant PM is going to have to do the cache dance I mentioned above, or maintain an in memory list of ebuilds it knows it can't handle (which if you want to talk robust, fails miserably if the API isn't designed for sync invalidation of that global list). Complexity, oh my. That's the kicker from where I'm sitting; you're so focused
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 12 March 2012 21:27, Michał Górny mgo...@gentoo.org wrote: And we could just use a good regex for that instead. Something like: [eE][aA][pP][iI] whitespace-or-symbols [a-z0-9-+]+ and just require users for this to be the first thing declared in an ebuild. Of course, this could make problems with stuff like: # EAPI 4 because of foobarbaz EAPI=4 (on the other hand, in this particular case it will fetch '4' anyway). And this will work as well with: eapi15-xml/eapi and - eapi: 15-yaml Also, remember the proposal is to read it only from the first 10-30 lines of the file, and if you're *generating* YAML/XML , then this is not necessarily guaranteed. Some generation tools emit keys in alphanumeric ordering, others psuedo-randomly, and the EAPI declaration line in some formats could easily be on the very last line of the file. And then the regexp could falsely detect something in another key the original author had not intended as an EAPI definition, but merely a comment, ... ie: generateddata comment This is a user comment, hurr, I hate EAPI 5 /comment eapi value=15 / /generateddata -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
Re: [gentoo-dev] Proposal: New irc data field in layman's repositories.xml file format
On Mon, Mar 12, 2012 at 08:52:20PM +1300, Kent Fredric wrote: On 11 March 2012 22:09, Brian Dolbec dol...@gentoo.org wrote: eg: ?? ??ircChannel #gentoo-guis on the freenode network/irc or ?? ??irc#gentoo-guis on the freenode IRC network, irc://irc.gentoo.org/gentoo-guis/irc Though a freeform text field is probably better for humans, I'd suggest having more explicit data available as an option, ie: irc network=irc.freenode.org channel=#gentoo-guisChannel #gentoo-guis on the freenode network/irc +1 on this. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
[gentoo-dev] Re: newsitem: unmasking udev-181
Robin H. Johnson posted on Sun, 11 Mar 2012 23:14:46 + as excerpted:
On Sun, Mar 11, 2012 at 11:03:50PM +, Duncan wrote:
Meanwhile, also note that there's PARTLABEL, PARTUUID and ID, that the
mount manpage promises to honor. I've not used these myself, but there
was a thread on the btrfs list discussing GPT format and users of its
partition-labels (as opposed to filesystem labels), that pointed out
that mount honors these, since it internally uses the udev symlinks
mechanism to support (fs) labels, etc, so they get support for
gpt-partition- labels, etc, essentially for free.
What manpage are you reading?
# man 8 mount |grep PART # man 2 mount |grep PART Nada.
When the blkid tool can read PARTUUID/PARTLABEL, then it will just work
with genkernel, as we use blkid for doing that.
mount (8) under device indication:
Most devices are indicated by a file name (of a block special device),
like /dev/sda1, but there are other possibilities. [...] It is possible
to indicate a block special device using its volume LABEL or UUID (see
the -L and -U options below).
The recommended setup is to use LABEL=label or UUID=uuid tags rather
than /dev/disk/by-{label,uuid} udev symlinks in the /etc/fstab file. The
tags are more readable, robust and portable. The mount(8) command
internally uses udev symlinks, so use the symlinks in /etc/fstab has no
advantage over LABEL=/UUID=. For more details see libblkid(3).
As I said, it wasn't apparent to me until someone pointed it out to me on
the btrfs list, but apparently, mount understands SOMETHING= as
referencing /dev/disk/by-something, using those symlinks internally, so
while the manpage doesn't specifically mention PARTLABEL, etc, according
to that person, it just works. Upon seeing that claim, I reread the
manpage, and sure enough, that meaning can be seen between the lines if
you already know to look for it.
I had intended to try it, since I use gptfdisk and gpt partitions pretty
much universally now, and referencing the PARTLABEL would have meant that
I could for instance do a mkfs and redo my backup partitions without
having to update fstab's labels because I could use the partlabels
instead. Unfortunately, when I actually checked to see what symlinks
udev was putting in /dev/disk/by-partlabel, while indeed the gpt
partlabels for the physical disks were there, the partlabels for the
gpt-partitioned md/raid devices were NOT, and that's what I actually
needed, so unfortunately I couldn't try using partlabels after all.
That's why I've yet to actually verify the claim.
At some point I'll probably verify it with a USB attached external drive,
as it's my last-resort backup, and/or on my netbook, with only one drive
so no raid, but I've not gotten that far, yet.
FWIW, the thread started with someone complaining that a btrfs label on a
multi-device filesystem (since btrfs can do that) was attached to the
filesystem, NOT the device/partition. Various people pointed out that
it's a filesystem label and that btrfs thus had it correct. Meanwhile,
on one subthread I pointed out gpt partition labels as an alternative,
but said I didn't think Linux could actually do much with them yet.
That's when someone else replied that it could do more than I thought,
mount and fstab handled partlabel, and he thought the kernel root=
parameter could take it as well.
Here's his post on gmane:
http://permalink.gmane.org/gmane.comp.file-systems.btrfs/16023
As I said, after reading that, rereading the mount (8) manpage, it /did/
seem to hint that it should do so even if it doesn't outright say it,
since it specifically mentions using udev's symlinks internally.
But as I've not tried it yet I have only his post and my reparsing of
that manpage based on it, to go on. Is it incorrect?
--
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] RFD: EAPI specification in ebuilds
On Mon, 12 Mar 2012 08:30:19 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 12 Mar 2012 09:27:11 +0100 Michał Górny mgo...@gentoo.org wrote: eapi15-xml/eapi and - eapi: 15-yaml You're carefully concocting your examples to make it look like it should work. Or I am just printing the first thing that comes into my head. If you go the XML route, though, the EAPI would either be in a DTD Like .../gentoo/eapi/15-xml.dtd ? That would match my regex as well, unless we allow dots in EAPI. or as eapi value=15 /. No, definitely not. That's not the XML style. Part of the point of all of this is that we shouldn't have to guess what future EAPIs will look like. I'm just suggesting a way which will support a little more than bash-based solutions. We could also assume that if a file doesn't match the regexp at all, it's a unsupported EAPI. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Mon, 12 Mar 2012 21:39:52 +1300 Kent Fredric kentfred...@gmail.com wrote: On 12 March 2012 21:27, Michał Górny mgo...@gentoo.org wrote: And we could just use a good regex for that instead. Something like: [eE][aA][pP][iI] whitespace-or-symbols [a-z0-9-+]+ and just require users for this to be the first thing declared in an ebuild. Of course, this could make problems with stuff like: # EAPI 4 because of foobarbaz EAPI=4 (on the other hand, in this particular case it will fetch '4' anyway). And this will work as well with: eapi15-xml/eapi and - eapi: 15-yaml Also, remember the proposal is to read it only from the first 10-30 lines of the file, and if you're *generating* YAML/XML , then this is not necessarily guaranteed. Some generation tools emit keys in alphanumeric ordering, others psuedo-randomly, and the EAPI declaration line in some formats could easily be on the very last line of the file. You should ensure your tool does the right thing, I'd say. XML with DTD often requires specific element order, so such a tool is simply bound to fail with XML. For yaml, it's a fair point. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 12 March 2012 22:09, Michał Górny mgo...@gentoo.org wrote: or as eapi value=15 /. No, definitely not. That's not the XML style. Sure, but these examples are just examples after all. And XML is only being used for an example use case, but there are many more structured formats than XML. Some of us are mostly just worried that the proposals as they stand won't be resilient enough to allow a future that isn't bash. Part of the point of all of this is that we shouldn't have to guess what future EAPIs will look like. I'm just suggesting a way which will support a little more than bash-based solutions. We could also assume that if a file doesn't match the regexp at all, it's a unsupported EAPI. I just find a top-down regexp solution dangerously naive, as its infering that the first line that matches the regexp *is* the EAPI requirement field, when depending on the actual format used, that may not be the case. If for example, a format is machine generated, and the EAPI declaration accidentally comes after something that *isnt* an EAPI declaration but by the regexp, LOOKS like one, then the probing mechanism will resolve the WRONG value. And that doesn't strike me as being very resilient. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
Re: [gentoo-dev] RFC: virtual/shadow
On 3/8/12 2:23 PM, Paweł Hajdan, Jr. wrote: And then convert profiles to the new virtual (the relevant files; below are all occurrences of sys-apps/shadow): Because of no comments, I went ahead and checked in sys-apps/hardened-shadow and virtual/shadow, and now made changes in profiles/ Please let me know if you see any problems after those changes, especially related to stage generation, prefix, bsd, and uclibc. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: an eclass for github snapshots?
On Mon, 12 Mar 2012 09:36:00 +0800
Ben yng...@gmail.com wrote:
On 12 March 2012 02:27, Michał Górny mgo...@gentoo.org wrote:
On Sun, 11 Mar 2012 10:25:38 -0700 (PDT)
Leho Kraav l...@kraav.com wrote:
On Monday, May 30, 2011 9:30:02 AM UTC+3, Michał Górny wrote:
Right now, a quick 'grep -l github.*tarball' shows that there are
about 147 ebuilds in portage using github snapshots. This
evaluates to 83 different packages.
The problem with github is that it suffixes the tarballs with
a complete git commit id. This means that the `S' variable
in the ebuild needs to refer to a long hash changing randomly.
Right now, the problem is handled in a number of ways:
1) (from app-admin/rudy)
2) (app-emacs/calfw and suggested solution for Sunrise)
3) (app-misc/bgrep)
4) (app-misc/tmux-mem-cpu-load)
What I'd like to do is creating a small github.eclass,
encapsulating a common, nice way of handling the S issue. I
guess the best solution would be to git with something like 2)
above, with the eclass providing github_src_unpack() for EAPIs
2+.
What is the current situation with this one? Every once in a while
I run into a github ebuild I need to create and I am not really
sure what to do with it.
Right now 2) seems like the safest approach. But did anything get
into EAPI?
You mean eclass? I submitted one for review but didn't get much of
positive feedback on it. I'll commit it anyway soon, just let me
double check and do some testing.
+1 from me. I think it would be useful to have a standard way of
handling this.
Attaching my current conceptual eclass. I've tested it with github,
gitweb and bitbucket. It won't work with gitorious but their snapshot
download mechanism is broken anyway (they like to submit 'try again
later' in plaintext).
--
Best regards,
Michał Górny
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: vcs-snapshot.eclass
# @MAINTAINER:
# mgo...@gentoo.org
# @BLURB: support eclass for VCS (github, bitbucket, gitweb) snapshots
# @DESCRIPTION:
# This eclass provides a convenience src_unpack() which does support
# working with snapshots generated by various VCS-es. It unpacks those
# to ${S} rather than the original directory containing commit id.
#
# Note that this eclass handles only unpacking. You need to specify
# SRC_URI yourself, and call any autoreconfiguration as necessary.
# The example does that using autotools-utils eclass.
#
# Right now, the eclass was tested with github, bitbucket and gitweb
# snapshots. Feel free to report snapshotting services which aren't
# working.
# @EXAMPLE:
#
# @CODE
# EAPI=4
# AUTOTOOLS_AUTORECONF=1
# inherit autotools-utils vcs-snapshot
#
# SRC_URI=http://github.com/example/${PN}/tarball/v${PV} - ${P}.tar.gz
# @CODE
case ${EAPI:-0} in
0|1) die EAPI ${EAPI} unsupported.;; # default(), SRC_URI arrows
2|3|4) ;;
*) die github-snapshot.eclass API in EAPI ${EAPI} not yet established.
esac
EXPORT_FUNCTIONS src_unpack
vcs-snapshot_src_unpack() {
default
# github, bitbucket: username-projectname-hash
# gitweb: projectname-tagname-hash
mv *-*-[0-9a-f]*[0-9a-f]/ ${S} || die
}
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Mon, 12 Mar 2012, Kent Fredric wrote: I just find a top-down regexp solution dangerously naive, as its infering that the first line that matches the regexp *is* the EAPI requirement field, when depending on the actual format used, that may not be the case. There's little danger if we require the EAPI specification to be in the first line of the ebuild. Of course the regexp should be general enough to account for a non-bash comment syntax. Ulrich
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 12 March 2012 22:48, Ulrich Mueller u...@gentoo.org wrote: On Mon, 12 Mar 2012, Kent Fredric wrote: There's little danger if we require the EAPI specification to be in the first line of the ebuild. Of course the regexp should be general enough to account for a non-bash comment syntax. There's the obvious case of compiled-binaries where that might not be possible, but thats definately strawman stuff and I wouldn't support that sort of nonsense anyway. Compiled binaries for ebuilds can gtfo. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
Re: [gentoo-dev] RFC: virtual/shadow
On 12-03-2012 10:16:12 +0100, Paweł Hajdan, Jr. wrote: On 3/8/12 2:23 PM, Paweł Hajdan, Jr. wrote: And then convert profiles to the new virtual (the relevant files; below are all occurrences of sys-apps/shadow): Because of no comments, I went ahead and checked in sys-apps/hardened-shadow and virtual/shadow, and now made changes in profiles/ Please let me know if you see any problems after those changes, especially related to stage generation, prefix, bsd, and uclibc. My rsync0 now spits out this message: Virtual package in package.provided: virtual/shadow-0 See portage(5) for correct package.provided usage. I did not forsee this happening, but each and every Prefix user now gets this complaint on each and every emerge invocation. It does not seem to block any operation, but could we perhaps hold back further changes until I can sort this out with Zac? Thanks -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] RFC: virtual/shadow
On 3/12/12 11:27 AM, Fabian Groffen wrote: My rsync0 now spits out this message: Virtual package in package.provided: virtual/shadow-0 See portage(5) for correct package.provided usage. I did not forsee this happening, but each and every Prefix user now gets this complaint on each and every emerge invocation. It does not seem to block any operation, but could we perhaps hold back further changes until I can sort this out with Zac? Ah, I read portage(5) now and adding a virtual to package.provided is indeed explicitly prohibited. I removed it, but some further changes might be required for prefix (i.e. version number = 4.1 in package.provided to satisfy the virtual), and I'll indeed hold back further changes in that area, and preferably just let you do any necessary fixes for prefix. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: virtual/shadow
On 12-03-2012 11:35:43 +0100, Paweł Hajdan, Jr. wrote: On 3/12/12 11:27 AM, Fabian Groffen wrote: My rsync0 now spits out this message: Virtual package in package.provided: virtual/shadow-0 See portage(5) for correct package.provided usage. I did not forsee this happening, but each and every Prefix user now gets this complaint on each and every emerge invocation. It does not seem to block any operation, but could we perhaps hold back further changes until I can sort this out with Zac? Ah, I read portage(5) now and adding a virtual to package.provided is indeed explicitly prohibited. I removed it, but some further changes might be required for prefix (i.e. version number = 4.1 in package.provided to satisfy the virtual), and I'll indeed hold back further changes in that area, and preferably just let you do any necessary fixes for prefix. Thanks a lot for your swift actions! -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
[gentoo-dev] Lastrite: dev-ada/qtada
12 Mar 2012; Samuli Suominen ssuomi...@gentoo.org package.mask: Lastrite dev-ada/qtada as per request from yngwin. # Samuli Suominen ssuomi...@gentoo.org (12 Mar 2012) # Severely broken wrt bugs #227171, #286550 and #287483 # Removal in 30 days dev-ada/qtada
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On Sun, Mar 11, 2012 at 7:15 PM, William Hubbs willi...@gentoo.org wrote: I was thinking of another news item once we are ready to go stable. What do you think? I think that makes the most sense. That news item can include links to the documentation that gets written over the next few months. Rich
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On Sunday 11 March 2012 21:08:47 Robin H. Johnson wrote: On Sun, Mar 11, 2012 at 12:49:11AM -0600, Ryan Hill wrote: On Sat, 10 Mar 2012 20:27:06 -0600 William Hubbs willi...@gentoo.org wrote: An initramfs which does this is created by =sys-kernel/genkernel-3.4.25 or =sys-kernel/dracut-017-r1. If you do not want to use these tools, be sure any initramfs you create pre-mounts /usr. We should really have some documentation on how to create a minimal initramfs that mounts /usr (if we don't already, I haven't looked). I've never needed one until now and don't have the foggiest idea how it's done. I can't be the only one. The quickest initramfs, assuming that ALL kernel modules you need to boot are already compiled into your kernel: genkernel --install --no-ramdisk-modules initramfs But this will not mount /usr. At least it did not for me. To make it work you have to # echo /usr /etc/initramfs.mounts and recreate the ramdisk (genkernel ramdisk) I had to look into the code for that as this seems not to be documented anywhere. -Marc signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Mon, Mar 12, 2012 at 6:12 AM, Kent Fredric kentfred...@gmail.com wrote: There's the obvious case of compiled-binaries where that might not be possible, but thats definately strawman stuff and I wouldn't support that sort of nonsense anyway. Compiled binaries for ebuilds can gtfo. Why do I feel like a similar debate must have happened on some list back when the SMTP message terminator was worked out? The problem is that we're running into is the use of in-band control information. An advantage of sticking the EAPI in the filename is that it is completely out-of-band. Other options like an external file or POSIX attributes have the same advantage (with the disadvantage that they are harder to keep in-sync or support in general). If you want to stick the EAPI inside the file then we have to go with one of two routes: 1. Make the file directly interpret-able by some existing tool like bash, xml parsers, or (gtfo) ld-linux.so. This requires making the EAPI in-band info, and thus if the file format changes there is risk that any existing code that interprets EAPIs could break, to the degree that we weren't infinitely clever in designing the spec. 2. Make the file require pre-processing before being fed to another interpreter. This breaks syntax-highlighting and such, and is generally more of a pita. However, this allows in-file EAPI info to remain out-of-band. An ebuild might be an xml file with EAPI and other meta-data, and might contain sections that get ripped out and handed over to bash, python, or ld-linux.so to the extent that you want to be told to gtfo. In my thinking the option with the fewest drawbacks and the greatest extent of future-proofing is to go with GLEP 55 and stick it in the filename. Every filesystem and rsync tool handles filenames, they're impossible to separate from file contents, and every interpreter out there ignores them. If we don't want to stick it in the filename then either we have to decide that whatever we come up with could break, or that we really have to change what ebuilds look like. Rich
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Mon, 12 Mar 2012 01:36:12 -0700 Brian Harring ferri...@gmail.com wrote: Also note that with the sole exception of g55 ... and does so at the same robustness as everything sans g55 ... G55 is the sole exception. Interesting pattern, huh? -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] RFD : .ebuild is only bash
On 12 March 2012 22:37, Brian Harring ferri...@gmail.com wrote: Ebuilds *are* bash. There isn't ever going to be a PMS labeled xml format that is known as ebuilds... that's just pragmatic reality since such a beast is clearly a seperate format (thus trying to call it an 'ebuild' is dumb, confusing, and counter productive). I think this notion should be concluded before we continue debating as to how best to implement EAPI declarations. Is it really so fixed that .ebuild will only ever be bash ? If thats the case, then G55 ( or something similar ) is practically guaranteed as soon as we want something non-bash. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
Re: [gentoo-dev] RFD : .ebuild is only bash
On Tue, 13 Mar 2012 04:57:04 +1300 Kent Fredric kentfred...@gmail.com wrote: I think this notion should be concluded before we continue debating as to how best to implement EAPI declarations. Is it really so fixed that .ebuild will only ever be bash ? What version of bash are we talking about here? It's not the case that ebuilds will always be bash 3, which is enough to make GLEP 55 the safe option. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/12/2012 01:36 AM, Brian Harring wrote: On Sun, Mar 11, 2012 at 09:08:24PM -0700, Zac Medico wrote: 1) User downloads an overlay that doesn't provide cache. We want the package manager to give a pretty EAPI unsupported message, rather than spit out some bash syntax errors. This criticsm pretty much applies *strictly to the existing implementation*. It's disenguous busting it in this fashion. EAPI as a function explicitly gives it an out before hitting any of that, eliminating your entire critique. Same goes for parsing it out of the ebuild, or renaming the extension. You're assuming that the ebuild calls your eapi() function before it uses any syntax that's unsupported by the user's installed version of bash. 1) PM still doesn't support that EAPI, looks at the cache/ebuild: checksums are the same, thus the stored EAPI is trustable, leading to the PM knowing it still can't process that ebuild and masking it appropriately. You're assuming that cache is provided by the repo, which is not guaranteed, depending on the source. Even if the cache does exist, then you're assuming it's in a format that the package manager can reliably parse the EAPI from, even though that EAPI may not be supported. That may or may not reliable assumption, and having a pre-defined protocol to directly obtain the EAPI without using the cache is much more reliable. What I'd like to see, is accuracy in this discussion. Skip the handwavey complexity! complexity! complexity! crap, same for selective robustness definitions. Past attempts at this discussion mostly failed due to people pulling crap like this and frankly it just pisses people off. It's just a symptom of people not abiding by the KISS principle. When you start talking about an approach such as the eapi() function approach which introduces lots of unnecessary complexity, it naturally makes the whole discussion more complex and hand-wavey. -- Thanks, Zac
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Mon, 12 Mar 2012 09:05:26 -0700 Zac Medico zmed...@gentoo.org wrote: It's just a symptom of people not abiding by the KISS principle. Abiding by the KISS principle is what got us into this mess in the first place. EAPI as a metadata variable is too simple to allow us to do what we want to do. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/12/2012 09:12 AM, Ciaran McCreesh wrote: On Mon, 12 Mar 2012 09:05:26 -0700 Zac Medico zmed...@gentoo.org wrote: It's just a symptom of people not abiding by the KISS principle. Abiding by the KISS principle is what got us into this mess in the first place. EAPI as a metadata variable is too simple to allow us to do what we want to do. If our goal is to obtain the EAPI before the ebuild is sourced, then GLEP 55 is more in alignment with the KISS principle. The EAPI as metadata variable approach simply wasn't designed with our current goal in mind. -- Thanks, Zac
[gentoo-dev] Lastrite: lilypond and reverse dependencies
# Samuli Suominen ssuomi...@gentoo.org (12 Mar 2012) # Severely broken wrt bugs #179178, #331181, #334835, #350059, # #372839, #380155, #380627, #381055, #383515, #383553, #384687, # and #403399. Search bugzilla with keyword lilypond. Nothing # left in tree that builds. Removal in 30 days. media-sound/lilypond-2.12.4 media-sound/denemo media-sound/frescobaldi # Samuli Suominen ssuomi...@gentoo.org (12 Mar 2012) # media-sound/lilypond required for this is masked in ../package.mask # for removal app-text/asciidoc test
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, Mar 12, 2012 at 11:59 AM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 13 Mar 2012 04:57:04 +1300 Kent Fredric kentfred...@gmail.com wrote: I think this notion should be concluded before we continue debating as to how best to implement EAPI declarations. Is it really so fixed that .ebuild will only ever be bash ? What version of bash are we talking about here? It's not the case that ebuilds will always be bash 3, which is enough to make GLEP 55 the safe option. Well, we do always have the option of keeping the EAPI= syntax but making it more strict per the proposals, and then grepping it out rather than sourcing the ebuild. That seems likely to always work with bash. Then if we ever switched to some other format we'd have to reconsider whether we want to tweak this approach further or adopt GLEP 55. If you envision a future where big changes are inevitable over the long term, then just going with GLEP 55 is probably the cleanest solution. If you envision a future where we are likely to never move away from bash, or if we do it is so far off that we're content to let our children deal with it, then other approaches may seem nicer. I guess the question is whether we need to future-proof against a future that may never come. Then again, as we're seeing from systemd a lot of stuff that always was done in bash doesn't necessarily have to stay that way. Rich
Re: [gentoo-dev] RFD : .ebuild is only bash
On Tue, 13 Mar 2012, Kent Fredric wrote: Is it really so fixed that .ebuild will only ever be bash ? Certainly it would make sense to change the file extension when an EAPI will require something different than bash. For example, some editors (Emacs and XEmacs at least) recognise the .ebuild extension and use corresponding syntax rules. If thats the case, then G55 ( or something similar ) is practically guaranteed as soon as we want something non-bash. No, you just use a new extension once and you're done. And I guess such drastic changes won't happen frequently. In the past 12 years there hasn't been a single one. (If they will ever happen, this is a pretty academic discussion.) Ulrich
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
Rich Freeman wrote: I think that makes the most sense. That news item can include links to the documentation that gets written over the next few months. In the German (not Gentoo-specific) newsgroup de.comp.os.unix.linux.misc, someone mentioned that he upgraded to udev-180 and lost the device nodes for the hard disk (or something like that) because CONFIG_DEVTMPFS was not set in his kernel configuration. He says udev=180 needs DEVTMPFS set. Is there any issue with Gentoo's udev-181 and CONFIG_DEVTMPFS? If so, you should include it in the documentation. -Matt
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/12/2012 02:16 AM, Kent Fredric wrote: I just find a top-down regexp solution dangerously naive, as its infering that the first line that matches the regexp *is* the EAPI requirement field, when depending on the actual format used, that may not be the case. If for example, a format is machine generated, and the EAPI declaration accidentally comes after something that *isnt* an EAPI declaration but by the regexp, LOOKS like one, then the probing mechanism will resolve the WRONG value. And that doesn't strike me as being very resilient. It would be very fragile without the sanity check / feedback mechanism that's already been suggested [1]. The idea is to compare the probed EAPI with the result that's obtained from bash, and treat the ebuild as invalid if they are not identical. This would allow ebuilds that don't fit our EAPI probing mechanism to be immediately detected so that the ebuild developer could fix them. In practice, this will not be much of an issue, since the EAPI assignment will be required to be very close to the top of the file, and the package manager will stop searching as soon as it finds the first match. [1] https://bugs.gentoo.org/show_bug.cgi?id=402167#c18 -- Thanks, Zac
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, 12 Mar 2012, Rich Freeman wrote: Well, we do always have the option of keeping the EAPI= syntax but making it more strict per the proposals, and then grepping it out rather than sourcing the ebuild. That seems likely to always work with bash. Then if we ever switched to some other format we'd have to reconsider whether we want to tweak this approach further or adopt GLEP 55. As long as we stay with some textual format for ebuilds, the header comment approach will always work, if its syntax is general enough. (For example, requiring # as comment introducer would be stupid.) And I don't expect that we will move away from bash within the next two or three years, so there won't be any upgrade problems for systems with old package managers. If you envision a future where big changes are inevitable over the long term, then just going with GLEP 55 is probably the cleanest solution. If you envision a future where we are likely to never move away from bash, or if we do it is so far off that we're content to let our children deal with it, then other approaches may seem nicer. I guess the question is whether we need to future-proof against a future that may never come. Then again, as we're seeing from systemd a lot of stuff that always was done in bash doesn't necessarily have to stay that way. See above, even if we should ever move away from bash, GLEP 55 is still not needed. Ulrich
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, 12 Mar 2012 18:05:46 +0100 Ulrich Mueller u...@gentoo.org wrote: See above, even if we should ever move away from bash, GLEP 55 is still not needed. ...but we might as well go with GLEP 55 anyway, since GLEP 55 definitely works, whereas other solutions might work so long as we don't do something unexpected. This whole thing is just an exercise in trying to find excuses not to use GLEP 55. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFD : .ebuild is only bash
On 03/12/12 13:12, Ciaran McCreesh wrote: On Mon, 12 Mar 2012 18:05:46 +0100 Ulrich Mueller u...@gentoo.org wrote: See above, even if we should ever move away from bash, GLEP 55 is still not needed. ...but we might as well go with GLEP 55 anyway, since GLEP 55 definitely works, whereas other solutions might work so long as we don't do something unexpected. This whole thing is just an exercise in trying to find excuses not to use GLEP 55. Not understanding any of the politics involved, what are the technical arguments against it?
Re: [gentoo-dev] RFD : .ebuild is only bash
On 03/12/2012 10:12 AM, Ciaran McCreesh wrote: On Mon, 12 Mar 2012 18:05:46 +0100 Ulrich Mueller u...@gentoo.org wrote: See above, even if we should ever move away from bash, GLEP 55 is still not needed. ...but we might as well go with GLEP 55 anyway, since GLEP 55 definitely works, whereas other solutions might work so long as we don't do something unexpected. This whole thing is just an exercise in trying to find excuses not to use GLEP 55. If we do go with a variant of GLEP 55, I'd prefer a variant that uses a constant extension (like .eb) and places the EAPI string just after the version component of the name. For example: foo-1.0-r1-eapi5.ebuild -- Thanks, Zac
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, 12 Mar 2012 13:17:15 -0400 Michael Orlitzky mich...@orlitzky.com wrote: This whole thing is just an exercise in trying to find excuses not to use GLEP 55. Not understanding any of the politics involved, what are the technical arguments against it? The person who wrote it is one of Satan's little minions. Also, change is bad. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Lastrite: lilypond and reverse dependencies
On Mon, Mar 12, 2012 at 11:29 AM, Samuli Suominen ssuomi...@gentoo.org wrote: # Samuli Suominen ssuomi...@gentoo.org (12 Mar 2012) # Severely broken wrt bugs #179178, #331181, #334835, #350059, # #372839, #380155, #380627, #381055, #383515, #383553, #384687, # and #403399. Search bugzilla with keyword lilypond. Nothing # left in tree that builds. Removal in 30 days. media-sound/lilypond-2.12.4 media-sound/denemo media-sound/frescobaldi # Samuli Suominen ssuomi...@gentoo.org (12 Mar 2012) # media-sound/lilypond required for this is masked in ../package.mask # for removal app-text/asciidoc test Just curious, but is there no one interested in this, lilypond, package anymore? The latest stable is 2.14.2 and the project is pretty active. Seems like a shame to get rid of it entirely. -- Matthew W. Summers Gentoo Foundation Inc.
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Mon, Mar 12, 2012 at 1:01 PM, Zac Medico zmed...@gentoo.org wrote: It would be very fragile without the sanity check / feedback mechanism that's already been suggested. Another obvious check is to have repoman run a grep with the regexp and give an error if there is not exactly one match. Rich
Re: [gentoo-dev] RFD : .ebuild is only bash
On 03/12/2012 10:17 AM, Michael Orlitzky wrote: On 03/12/12 13:12, Ciaran McCreesh wrote: On Mon, 12 Mar 2012 18:05:46 +0100 Ulrich Mueller u...@gentoo.org wrote: See above, even if we should ever move away from bash, GLEP 55 is still not needed. ...but we might as well go with GLEP 55 anyway, since GLEP 55 definitely works, whereas other solutions might work so long as we don't do something unexpected. This whole thing is just an exercise in trying to find excuses not to use GLEP 55. Not understanding any of the politics involved, what are the technical arguments against it? I think the bulk of resistance has been due to its use of an infinite series of extensions, like .ebuild-5, .ebuild-6 and so on. GLEP 55 itself has since been amended to include a one time extension change option [1]. [1] http://www.gentoo.org/proj/en/glep/glep-0055.html#eapi-in-the-filename-with-one-time-extension-change -- Thanks, Zac
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On 03/12/2012 10:30 AM, Rich Freeman wrote: On Mon, Mar 12, 2012 at 1:01 PM, Zac Medico zmed...@gentoo.org wrote: It would be very fragile without the sanity check / feedback mechanism that's already been suggested. Another obvious check is to have repoman run a grep with the regexp and give an error if there is not exactly one match. If we want to handle every possible screwup, including stray EAPI assignments inside inherited eclasses, we still need to compare the probed value to the value that's obtained from bash. I guess you're hinting at using a non-bash ebuild format? Even if in that case, the the package manager should simply use whatever interpreter is appropriate for the probed EAPI. So, if EAPI 7 is a posix-shell format, and the probed EAPI is 7, then the package manager should source the ebuild with it's posix-shell instead of bash. If the probed EAPI is not a supported EAPI, then it should skip the sourcing entirely, and report the ebuild as having an unsupported EAPI. -- Thanks, Zac
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, 12 Mar 2012, Ciaran McCreesh wrote: On Mon, 12 Mar 2012 18:05:46 +0100 Ulrich Mueller u...@gentoo.org wrote: See above, even if we should ever move away from bash, GLEP 55 is still not needed. ...but we might as well go with GLEP 55 anyway, since GLEP 55 definitely works, whereas other solutions might work so long as we don't do something unexpected. This whole thing is just an exercise in trying to find excuses not to use GLEP 55. There are very good reasons not to embed this information in the filename. That it makes the filename harder to parse for the human eye and more difficult to type is one of them. Besides, we already have a council decision about that GLEP. Ulrich
Re: [gentoo-dev] Lastrite: lilypond and reverse dependencies
On Mon, Mar 12, 2012 at 12:29:47PM -0500, Matthew Summers wrote: On Mon, Mar 12, 2012 at 11:29 AM, Samuli Suominen ssuomi...@gentoo.org wrote: # Samuli Suominen ssuomi...@gentoo.org (12 Mar 2012) # Severely broken wrt bugs #179178, #331181, #334835, #350059, # #372839, #380155, #380627, #381055, #383515, #383553, #384687, # and #403399. Search bugzilla with keyword lilypond. Nothing # left in tree that builds. Removal in 30 days. media-sound/lilypond-2.12.4 media-sound/denemo media-sound/frescobaldi # Samuli Suominen ssuomi...@gentoo.org (12 Mar 2012) # media-sound/lilypond required for this is masked in ../package.mask # for removal app-text/asciidoc test Just curious, but is there no one interested in this, lilypond, package anymore? The latest stable is 2.14.2 and the project is pretty active. Seems like a shame to get rid of it entirely. I myself am quite interested in lilypond. I only use it occasionally and am still a novice at it, but I like the typesetting it does. Maybe next week I can find time to attack some of these bugs and rescue it, unless if someone more qualified or with more time is interested... -- binki Look out for missing or extraneous apostrophes! pgpikFikeaWP7.pgp Description: PGP signature
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, 12 Mar 2012 10:22:57 -0700 Zac Medico zmed...@gentoo.org wrote: On 03/12/2012 10:12 AM, Ciaran McCreesh wrote: On Mon, 12 Mar 2012 18:05:46 +0100 Ulrich Mueller u...@gentoo.org wrote: See above, even if we should ever move away from bash, GLEP 55 is still not needed. ...but we might as well go with GLEP 55 anyway, since GLEP 55 definitely works, whereas other solutions might work so long as we don't do something unexpected. This whole thing is just an exercise in trying to find excuses not to use GLEP 55. If we do go with a variant of GLEP 55, I'd prefer a variant that uses a constant extension (like .eb) and places the EAPI string just after the version component of the name. For example: foo-1.0-r1-eapi5.ebuild Or .eapi5.ebuild, to make it more of a suffix and less of PV part. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Lastrite: lilypond and reverse dependencies
El 12/03/12 17:29, Samuli Suominen escribió: # Samuli Suominen ssuomi...@gentoo.org (12 Mar 2012) # media-sound/lilypond required for this is masked in ../package.mask # for removal app-text/asciidoc test asciidoc only depends with the test use flag set so why don't just remove the test USE and the test function from the ebuilds instead? If somebody is willing to proxy the changes for me I can patch the tree with this fix. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, 12 Mar 2012, Zac Medico wrote: If we do go with a variant of GLEP 55, I'd prefer a variant that uses a constant extension (like .eb) and places the EAPI string just after the version component of the name. For example: foo-1.0-r1-eapi5.ebuild This is so ugly... I guess I'll retire the same day when such an abomination gets accepted. ;-) (Still better than the original variant of GLEP 55 though.) Ulrich
Re: [gentoo-dev] RFD : .ebuild is only bash
On Tue, 13 Mar 2012 04:57:04 +1300 Kent Fredric kentfred...@gmail.com wrote: On 12 March 2012 22:37, Brian Harring ferri...@gmail.com wrote: Ebuilds *are* bash. There isn't ever going to be a PMS labeled xml format that is known as ebuilds... that's just pragmatic reality since such a beast is clearly a seperate format (thus trying to call it an 'ebuild' is dumb, confusing, and counter productive). I think this notion should be concluded before we continue debating as to how best to implement EAPI declarations. Is it really so fixed that .ebuild will only ever be bash ? If thats the case, then G55 ( or something similar ) is practically guaranteed as soon as we want something non-bash. Maybe instead of per-EAPI suffix change, we'd want to prepend the suffix with something special whenever the actual format changes. In other words, if EAPI 15 introduces XML-based syntax, we start using .xml.ebuild. If EAPI 7 introduces bash4 in global scope (still don't see much reason for it), we use .bash4.ebuild. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFD : .ebuild is only bash
On 13 March 2012 06:53, Ulrich Mueller u...@gentoo.org wrote: There are very good reasons not to embed this information in the filename. That it makes the filename harder to parse for the human eye and more difficult to type is one of them. Besides, we already have a council decision about that GLEP. Difficulty in typing them is not really much of an argument, considering the present complexity with file-names already having versions encoded in them. And difficulty reading them isn't much of an argument really either. But difficulty identifying the format systematically seems a reasonable enough objection, and for this, I can see the translation of abz-123.ebuild-5 to - abz-123.eapi5.eb Being a more practical change ( or something of that nature ). At least that way, its easier to have a way to find all ebuilds without needing extension permutation. Another thought: Presently we have versions encoded in the file name. If we ever decide we need to change our versioning syntax or versioning semantics, we might be up the creek without a paddle, and EAPI being *in* the file will probably make that harder, and I'd probably prefer some sort of out-of-band location for EAPI in that situation too. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, 12 Mar 2012 19:00:32 +0100 Ulrich Mueller u...@gentoo.org wrote: On Mon, 12 Mar 2012, Zac Medico wrote: If we do go with a variant of GLEP 55, I'd prefer a variant that uses a constant extension (like .eb) and places the EAPI string just after the version component of the name. For example: foo-1.0-r1-eapi5.ebuild This is so ugly... I guess I'll retire the same day when such an abomination gets accepted. ;-) (Still better than the original variant of GLEP 55 though.) I'm sorry, we're down to it's ugly and someone already said no and I'll throw my toys out of the pram if I don't get my way as the arguments against GLEP 55 now? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, 12 Mar 2012, Ciaran McCreesh wrote: On Mon, 12 Mar 2012 19:00:32 +0100 Ulrich Mueller u...@gentoo.org wrote: On Mon, 12 Mar 2012, Zac Medico wrote: If we do go with a variant of GLEP 55, I'd prefer a variant that uses a constant extension (like .eb) and places the EAPI string just after the version component of the name. For example: foo-1.0-r1-eapi5.ebuild This is so ugly... I guess I'll retire the same day when such an abomination gets accepted. ;-) I'm sorry, we're down to it's ugly and someone already said no and I'll throw my toys out of the pram if I don't get my way as the arguments against GLEP 55 now? Note the smiley in my posting. And yes, it _is_ ugly. On Mon, 12 Mar 2012, Ciaran McCreesh wrote: The person who wrote it is one of Satan's little minions. Also, change is bad. And you think that this is better? Ulrich
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, 12 Mar 2012 19:17:31 +0100 Ulrich Mueller u...@gentoo.org wrote: The person who wrote it is one of Satan's little minions. Also, change is bad. And you think that this is better? Those *are* the arguments against GLEP 55 that we've had so far. You're adding in someone already said no (and the people who said that were discussing nonsense like using xattrs in its place, which should immediately invalidate anything they said on the matter) and it looks ugly, but not just because I don't like the people who proposed it, honest to that. The only reason this discussion is going on is because some people still think it's in their advantage politically to say no to anything seen as coming from the wrong people. GLEP 55 is simple, it solves all the problems we have (including the version issue, which everyone is conveniently ignoring), it doesn't require us to guess what's going to happen next and it can be implemented immediately. That's a rather big deal. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFD : .ebuild is only bash
On 13 March 2012 07:17, Ulrich Mueller u...@gentoo.org wrote: Note the smiley in my posting. And yes, it _is_ ugly. It may be ugly, but I'll take ugly over doesn't work and serious technical limitations any day ;) Binary executables are ugly, you don't see many people complaining ;) -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On Sun, Mar 11, 2012 at 12:49:11AM -0600, Ryan Hill wrote: We should really have some documentation on how to create a minimal initramfs that mounts /usr (if we don't already, I haven't looked). I've never needed one until now and don't have the foggiest idea how it's done. I can't be the only one. I just started the tracker [1] for the documentation changes and sent info to gentoo-doc mailinglist about it. The upcoming days, I'll have the needed updates trickle into the documents. [1] https://bugs.gentoo.org/show_bug.cgi?id=407959 Also, the handbook still endorses having a separate partition for /usr and includes it in the example setup. This should be changed now, not when stabilization time comes. It's an example, and we still endorse it. Only will we now tell users to use an initramfs with it. Wkr, Sven Vermeulen
Re: [gentoo-dev] Lastrite: lilypond and reverse dependencies
On 2012-03-12 Mon 10:54, Nathan Phillip Brink wrote: # Samuli Suominen ssuomi...@gentoo.org (12 Mar 2012) # Severely broken wrt bugs #179178, #331181, #334835, #350059, # #372839, #380155, #380627, #381055, #383515, #383553, #384687, # and #403399. Search bugzilla with keyword lilypond. Nothing # left in tree that builds. Removal in 30 days. media-sound/lilypond-2.12.4 media-sound/denemo media-sound/frescobaldi # Samuli Suominen ssuomi...@gentoo.org (12 Mar 2012) # media-sound/lilypond required for this is masked in ../package.mask # for removal app-text/asciidoc test Just curious, but is there no one interested in this, lilypond, package anymore? The latest stable is 2.14.2 and the project is pretty active. Seems like a shame to get rid of it entirely. I myself am quite interested in lilypond. I only use it occasionally and am still a novice at it, but I like the typesetting it does. Maybe next week I can find time to attack some of these bugs and rescue it, unless if someone more qualified or with more time is interested... For those not following #gentoo-dev, I already said I'd take over maintainership since I've been using it an overlay for years. Anyone is free to help close bugs and co-maintain it if they wish. Tim pgpnJL6RZXo86.pgp Description: PGP signature
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, 12 Mar 2012, Ciaran McCreesh wrote: GLEP 55 is simple, it solves all the problems we have (including the version issue, which everyone is conveniently ignoring), it doesn't require us to guess what's going to happen next and it can be implemented immediately. That's a rather big deal. The header comment solution solves all these issues too, without embedding unrelated information in the filename [1]. It can be implemented immediately, too. The argument that was always used against such solutions was that it would hurt performance. However, when the council asked for benchmarks that would prove that point, nobody could provide them. Ulrich [1] http://en.wikipedia.org/wiki/Filename The filename is metadata about a file; a string used to uniquely identify a file stored on the file system.
Re: [gentoo-dev] RFD : .ebuild is only bash
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/03/12 02:50 PM, Ulrich Mueller wrote: On Mon, 12 Mar 2012, Ciaran McCreesh wrote: GLEP 55 is simple, it solves all the problems we have (including the version issue, which everyone is conveniently ignoring), it doesn't require us to guess what's going to happen next and it can be implemented immediately. That's a rather big deal. The header comment solution solves all these issues too, without embedding unrelated information in the filename [1]. It can be implemented immediately, too. The argument that was always used against such solutions was that it would hurt performance. However, when the council asked for benchmarks that would prove that point, nobody could provide them. Ulrich Regarding the filename issue, and the potential in the future for ebuilds that get parsed with other parsers: Is there any particular reason why we would want multiple ebuilds for a package to exist for the same version, but supporting different EAPIs (ad therefore different parsers)? If the answer to this is no, that there should always be only one ebuild per package version, then chances are good that we should keep the eapi (or other identifier) out of the file name. However, if the answer is yes, then the filename method is probably the cleanest way to do this. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk9eRzkACgkQAJxUfCtlWe18WwD5AeXETH+J4X8d8P7TX76FPGPS 0vS2rrRZktpLp70TkcQA/0Cl2/OdSlfwi0CqC8IBJffsY3epXkqxhzPL8bwsNAoj =Q5aK -END PGP SIGNATURE-
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, 12 Mar 2012 19:50:36 +0100 Ulrich Mueller u...@gentoo.org wrote: On Mon, 12 Mar 2012, Ciaran McCreesh wrote: GLEP 55 is simple, it solves all the problems we have (including the version issue, which everyone is conveniently ignoring), it doesn't require us to guess what's going to happen next and it can be implemented immediately. That's a rather big deal. The header comment solution solves all these issues too, without embedding unrelated information in the filename [1]. No it doesn't. See the conveniently ignoring part you're conveniently ignoring. It can be implemented immediately, too. No it can't, since existing package managers don't handle it. The argument that was always used against such solutions was that it would hurt performance. However, when the council asked for benchmarks that would prove that point, nobody could provide them. No, the argument was that such solutions didn't solve the full problem. Performance issues were secondary, and were picked up upon as a way of avoiding the whole nothing else solves all the problems thing. [1] http://en.wikipedia.org/wiki/Filename The filename is metadata about a file; a string used to uniquely identify a file stored on the file system. By that argument, there's no point in having a .ebuild there either. Please don't continue the bad trend of posting irrelevant Wikipedia links as footnotes as though the primary issue should be anything other than a comparison of solutions to a technical problem [1]. [1] http://en.wikipedia.org/wiki/Spork -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFD : .ebuild is only bash
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 12 Mar 2012 14:58:01 -0400 Ian Stakenvicius a...@gentoo.org wrote: If the answer to this is no, that there should always be only one ebuild per package version That's already not the way things work, since different version strings can be equal versions (and it's illegal to do this), so it's not relevant to the discussion. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk9eSAwACgkQ96zL6DUtXhGpEwCfWS9u6S4oqNebnRrofwqWKFAy tGMAoNX/2T7dyBqW+sSVO+O5nSMp5NKm =Y5Tt -END PGP SIGNATURE-
Re: [gentoo-dev] Lastrite: lilypond and reverse dependencies
On 03/12/2012 07:59 PM, Francisco Blas Izquierdo Riera (klondike) wrote: El 12/03/12 17:29, Samuli Suominen escribió: # Samuli Suominenssuomi...@gentoo.org (12 Mar 2012) # media-sound/lilypond required for this is masked in ../package.mask # for removal app-text/asciidoc test asciidoc only depends with the test use flag set so why don't just remove the test USE and the test function from the ebuilds instead? If somebody is willing to proxy the changes for me I can patch the tree with this fix. I know. If you look more closely, this is from package.use.mask, not package.mask.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/jbigkit: jbigkit-2.0-r1.ebuild ChangeLog
I thought we had this discussion already. USE=static-libs is for
controlling the build of static libraries, not the install alone.
Changed it the way it was.
On 03/12/2012 07:57 PM, Tomas Chvatal (scarabeus) wrote:
scarabeus12/03/12 17:57:41
Modified: jbigkit-2.0-r1.ebuild ChangeLog
Log:
Deploy static libs only if wanted.
(Portage version: 2.2.0_alpha90/cvs/Linux x86_64)
Revision ChangesPath
1.11 media-libs/jbigkit/jbigkit-2.0-r1.ebuild
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/jbigkit/jbigkit-2.0-r1.ebuild?rev=1.11view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/jbigkit/jbigkit-2.0-r1.ebuild?rev=1.11content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/jbigkit/jbigkit-2.0-r1.ebuild?r1=1.10r2=1.11
Index: jbigkit-2.0-r1.ebuild
===
RCS file: /var/cvsroot/gentoo-x86/media-libs/jbigkit/jbigkit-2.0-r1.ebuild,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- jbigkit-2.0-r1.ebuild 5 Sep 2010 13:16:55 - 1.10
+++ jbigkit-2.0-r1.ebuild 12 Mar 2012 17:57:41 - 1.11
@@ -1,8 +1,8 @@
-# Copyright 1999-2010 Gentoo Foundation
+# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/media-libs/jbigkit/jbigkit-2.0-r1.ebuild,v
1.10 2010/09/05 13:16:55 armin76 Exp $
+# $Header: /var/cvsroot/gentoo-x86/media-libs/jbigkit/jbigkit-2.0-r1.ebuild,v
1.11 2012/03/12 17:57:41 scarabeus Exp $
-EAPI=3
+EAPI=4
inherit eutils multilib toolchain-funcs
@@ -13,7 +13,7 @@
LICENSE=GPL-2
SLOT=0
KEYWORDS=alpha amd64 arm hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86
~sparc-fbsd ~x86-fbsd ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos ~sparc-solaris
~x64-solaris ~x86-solaris
-IUSE=
+IUSE=static-libs
S=${WORKDIR}/${PN}
@@ -23,20 +23,21 @@
src_compile() {
tc-export AR CC RANLIB
- emake LIBDIR=${EPREFIX}/usr/$(get_libdir) || die
+ emake LIBDIR=${EPREFIX}/usr/$(get_libdir)
}
src_test() {
- LD_LIBRARY_PATH=${S}/libjbig make -j1 test || die
+ LD_LIBRARY_PATH=${S}/libjbig make -j1 test
}
src_install() {
- dobin pbmtools/jbgtopbm{,85} pbmtools/pbmtojbg{,85} || die
+ dobin pbmtools/jbgtopbm{,85} pbmtools/pbmtojbg{,85}
doman pbmtools/jbgtopbm.1 pbmtools/pbmtojbg.1
insinto /usr/include
- doins libjbig/*.h || die
- dolib libjbig/libjbig{,85}{.a,$(get_libname)} || die
+ doins libjbig/*.h
+ dolib libjbig/libjbig{,85}$(get_libname)
+ use static-libs dolib libjbig/libjbig{,85}.a
dodoc ANNOUNCE CHANGES TODO libjbig/*.txt
}
1.51 media-libs/jbigkit/ChangeLog
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/jbigkit/ChangeLog?rev=1.51view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/jbigkit/ChangeLog?rev=1.51content-type=text/plain
diff :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/jbigkit/ChangeLog?r1=1.50r2=1.51
Index: ChangeLog
===
RCS file: /var/cvsroot/gentoo-x86/media-libs/jbigkit/ChangeLog,v
retrieving revision 1.50
retrieving revision 1.51
diff -u -r1.50 -r1.51
--- ChangeLog 9 Oct 2011 11:59:40 - 1.50
+++ ChangeLog 12 Mar 2012 17:57:41 - 1.51
@@ -1,6 +1,9 @@
# ChangeLog for media-libs/jbigkit
-# Copyright 1999-2011 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/media-libs/jbigkit/ChangeLog,v 1.50
2011/10/09 11:59:40 ssuominen Exp $
+# Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2
+# $Header: /var/cvsroot/gentoo-x86/media-libs/jbigkit/ChangeLog,v 1.51
2012/03/12 17:57:41 scarabeus Exp $
+
+ 12 Mar 2012; Tomáš Chvátalscarab...@gentoo.org jbigkit-2.0-r1.ebuild:
+ Deploy static libs only if wanted.
09 Oct 2011; Samuli Suominenssuomi...@gentoo.org -jbigkit-1.6-r1.ebuild,
-files/jbigkit-1.6-build.patch, -files/jbigkit-1.6-respect-make.patch,
Re: [gentoo-dev] RFD: EAPI specification in ebuilds
On Mon, Mar 12, 2012 at 1:46 PM, Zac Medico zmed...@gentoo.org wrote: If we want to handle every possible screwup, including stray EAPI assignments inside inherited eclasses, we still need to compare the probed value to the value that's obtained from bash. Well, I wasn't intending to suggest that the repoman check need be the only one. However, preventing problems is at least as useful as detecting them. That said, it would probably best to have exactly one way to determine the official EAPI. If that is to parse the filename, then parse the filename. If it is to grep for a regexp and expect exactly one hit and parse it in a certain way, then do that. It might be that the one official way is to grep for a regexp and if you find it, use it, otherwise assume 0, 1, 2, 3, or 4 and source the ebuild for it. That still gives you only a single answer (well, except in situations where the current way is already broken). If people want to abuse the EAPI syntax I suppose we can generate an error, but ignoring it might be just as valid behavior. I'm not sure what happens if you define PN/etc in ebuild besides things breaking in a horrible manner. I'd put changing EAPI in the same category. Rich
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, 12 Mar 2012, Ciaran McCreesh wrote: Ulrich Mueller u...@gentoo.org wrote: The header comment solution solves all these issues too, without embedding unrelated information in the filename [1]. It can be implemented immediately, too. No it can't, since existing package managers don't handle it. It can be easily implemented in a way that existing package managers would mask the ebuild by unrecognised EAPI. At least if we stay with bash, and nobody expects that we switch to any other format within the next few years. The argument that was always used against such solutions was that it would hurt performance. However, when the council asked for benchmarks that would prove that point, nobody could provide them. No, the argument was that such solutions didn't solve the full problem. Performance issues were secondary, and were picked up upon as a way of avoiding the whole nothing else solves all the problems thing. The performance argument is in GLEP 55 itself: | Easily fetchable EAPI inside the ebuild | | Properties: |Can be used right away: no |Hurts performance: yes Ulrich
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On Mon, Mar 12, 2012 at 03:09:39PM +0100, Marc Schiffbauer wrote: The quickest initramfs, assuming that ALL kernel modules you need to boot are already compiled into your kernel: genkernel --install --no-ramdisk-modules initramfs But this will not mount /usr. At least it did not for me. Ouch, nice catch. I missed merging my commit to flip the default of mounting /usr when that file is missing. I fixed that in 3.4.25.1 now. 3.4.25-r1 also installed /etc/initramfs.mounts by default, that's where the documentation is. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, 12 Mar 2012 20:38:21 +0100 Ulrich Mueller u...@gentoo.org wrote: The performance argument is in GLEP 55 itself: | Easily fetchable EAPI inside the ebuild | | Properties: |Can be used right away: no |Hurts performance: yes Sure. And it's a benefit, if your package mangler is carefully designed to avoid doing unnecessary I/O. It's just not the primary point. The primary point is that it handles whatever we feel like doing in the future, even the conveniently ignoring stuff that you're conveniently ignoring. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, 12 Mar 2012, Ciaran McCreesh wrote: On Mon, 12 Mar 2012 14:58:01 -0400 Ian Stakenvicius a...@gentoo.org wrote: If the answer to this is no, that there should always be only one ebuild per package version Right. That's already not the way things work, since different version strings can be equal versions (and it's illegal to do this), so it's not relevant to the discussion. This is a design flaw in our versioning system, and it can only occur in some corner cases where version components have leading zeros. It would be much better if any two different version strings had a unique order relation (as for example it is the case with strverscmp(3)). But that's not an excuse for adding another such flaw to our naming scheme. Ulrich
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, 12 Mar 2012 20:49:22 +0100 Ulrich Mueller u...@gentoo.org wrote: That's already not the way things work, since different version strings can be equal versions (and it's illegal to do this), so it's not relevant to the discussion. This is a design flaw in our versioning system, and it can only occur in some corner cases where version components have leading zeros. You know, if we had GLEP 55, we could fix that. Although it's debatable whether it's a flaw, since we're trying to match upstream version formats where reasonably possible. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] RFC: Change mail-mta/msmtp to be the default in virtual/mta instead of mail-mta/ssmtp ?
ssmtp has been quiet project for quite a while, where as msmtp is maintained one. sure, ssmtp might be just mature, but msmtp is equally small and has more features. any thoughts? - Samuli
Re: [gentoo-dev] RFC: Change mail-mta/msmtp to be the default in virtual/mta instead of mail-mta/ssmtp ?
On Mon, Mar 12, 2012 at 10:07:48PM +0200, Samuli Suominen wrote: ssmtp has been quiet project for quite a while, where as msmtp is maintained one. sure, ssmtp might be just mature, but msmtp is equally small and has more features. any thoughts? +1 to getting rid of ssmtp. But I'm not sure that msmtp is the best replacement. One of the greatest things that bugs me about ssmtp is that if the mailserver is not available, it hangs for a while, and then it loses the email. Where I need a simple mail relay, I've gone with nullmailer instead, because it supports the features, and it explicitly has a lightweight daemon mode that queues mail to send. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFD : .ebuild is only bash
On 12 March 2012 20:10, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 12 Mar 2012 20:49:22 +0100 Ulrich Mueller u...@gentoo.org wrote: That's already not the way things work, since different version strings can be equal versions (and it's illegal to do this), so it's not relevant to the discussion. This is a design flaw in our versioning system, and it can only occur in some corner cases where version components have leading zeros. You know, if we had GLEP 55, we could fix that. Although it's debatable whether it's a flaw, since we're trying to match upstream version formats where reasonably possible. -- Ciaran McCreesh I'm sure that it's been considered already, but what are the arguments against embedding the EAPI on a per-package (default) or per-version basis in metadata.xml. It IS metadata after all. Something like: eapi6/eapi !-- Default EAPI unless a versioned tag exists. -- eapi version==1.2.*4/eapi eapi version=1.23/eapi Where the version attribute should presumably have the same syntax as versions in package.* already.
Re: [gentoo-dev] newsitem: unmasking udev-181
On Sun, Mar 11, 2012 at 12:26:57PM -0500, William Hubbs wrote: An initramfs which does this is created by =sys-kernel/genkernel-3.4.25 or =sys-kernel/dracut-017-r1. If you do not want to use these tools, be sure any initramfs you create pre-mounts /usr. Minor tweak: =sys-kernel/genkernel-3.4.25.1 As I missed enabling the new default. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, 12 Mar 2012, James Broadhead wrote: I'm sure that it's been considered already, but what are the arguments against embedding the EAPI on a per-package (default) or per-version basis in metadata.xml. It IS metadata after all. You can find a recent discussion in bug 402167, comment #4 and following. https://bugs.gentoo.org/show_bug.cgi?id=402167#c4 Ulrich
Re: [gentoo-dev] RFD : .ebuild is only bash
On 13 March 2012 10:14, Ulrich Mueller u...@gentoo.org wrote: On Mon, 12 Mar 2012, James Broadhead wrote: I'm sure that it's been considered already, but what are the arguments against embedding the EAPI on a per-package (default) or per-version basis in metadata.xml. It IS metadata after all. You can find a recent discussion in bug 402167, comment #4 and following. https://bugs.gentoo.org/show_bug.cgi?id=402167#c4 I note that there is a link to the council minutes, with the reason for voting no against GLEP55 being it has issues that are unsolved, but I don't see any reference to said issues. Is the actual IRC transcript available? Because I'd hate for this decision to have been made on the assumption of issues which didn't really exist. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, Mar 12, 2012 at 2:28 PM, Kent Fredric kentfred...@gmail.com wrote: On 13 March 2012 10:14, Ulrich Mueller u...@gentoo.org wrote: On Mon, 12 Mar 2012, James Broadhead wrote: I'm sure that it's been considered already, but what are the arguments against embedding the EAPI on a per-package (default) or per-version basis in metadata.xml. It IS metadata after all. You can find a recent discussion in bug 402167, comment #4 and following. https://bugs.gentoo.org/show_bug.cgi?id=402167#c4 I note that there is a link to the council minutes, with the reason for voting no against GLEP55 being it has issues that are unsolved, but I don't see any reference to said issues. Is the actual IRC transcript available? Because I'd hate for this decision to have been made on the assumption of issues which didn't really exist. The previous council's decision does not prevent this same glep from going to the council again (decisions are not forever.) Some folks seem to think that taking glep55 back to the council is not allowed somehow (or is perhaps futile, but that is a different issue ;p) Having the full notes would be helpful in determining why it was turned down back then; I'm sure a copy of the notes exist. -A -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
[gentoo-dev] Stabilization requests from users
Hello gentoo-dev team, scarabeus recently posted on his blog [1] about submission of stabilization requests from users. Since using bugzilla could be a mess of duplicated entries, I was thinking about a Stabilization Party once a month for example, in order to have a coherent list of stabilizations, and users working togheter with you developers. How does it sound? [1] http://blogs.gentoo.org/scarabeus/2012/03/05/stabilisations-and-testing/ -- Linux Registered User #401479 GPG: 0x897AF14E
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, Mar 12, 2012 at 5:49 PM, Alec Warner anta...@gentoo.org wrote: On Mon, Mar 12, 2012 at 2:28 PM, Kent Fredric kentfred...@gmail.com wrote: On 13 March 2012 10:14, Ulrich Mueller u...@gentoo.org wrote: On Mon, 12 Mar 2012, James Broadhead wrote: I'm sure that it's been considered already, but what are the arguments against embedding the EAPI on a per-package (default) or per-version basis in metadata.xml. It IS metadata after all. You can find a recent discussion in bug 402167, comment #4 and following. https://bugs.gentoo.org/show_bug.cgi?id=402167#c4 I note that there is a link to the council minutes, with the reason for voting no against GLEP55 being it has issues that are unsolved, but I don't see any reference to said issues. Is the actual IRC transcript available? Because I'd hate for this decision to have been made on the assumption of issues which didn't really exist. The previous council's decision does not prevent this same glep from going to the council again (decisions are not forever.) Some folks seem to think that taking glep55 back to the council is not allowed somehow (or is perhaps futile, but that is a different issue ;p) Having the full notes would be helpful in determining why it was turned down back then; I'm sure a copy of the notes exist. http://www.gentoo.org/proj/en/council/ http://www.gentoo.org/proj/en/council/meeting-logs/20100823.txt
Re: [gentoo-dev] RFD : .ebuild is only bash
On 12 March 2012 21:14, Ulrich Mueller u...@gentoo.org wrote: On Mon, 12 Mar 2012, James Broadhead wrote: I'm sure that it's been considered already, but what are the arguments against embedding the EAPI on a per-package (default) or per-version basis in metadata.xml. It IS metadata after all. You can find a recent discussion in bug 402167, comment #4 and following. https://bugs.gentoo.org/show_bug.cgi?id=402167#c4 Ulrich That makes sense (actually, it calls for metadata.xml to be converted to json even without bundling EAPI in there). If repoman validated metadata.json based on a clear definition in PMS, that would be a valid solution to the problem (that wouldn't require external libraries beyond python)
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, Mar 12, 2012 at 3:06 PM, James Broadhead jamesbroadh...@gmail.com wrote: On 12 March 2012 21:14, Ulrich Mueller u...@gentoo.org wrote: On Mon, 12 Mar 2012, James Broadhead wrote: I'm sure that it's been considered already, but what are the arguments against embedding the EAPI on a per-package (default) or per-version basis in metadata.xml. It IS metadata after all. You can find a recent discussion in bug 402167, comment #4 and following. https://bugs.gentoo.org/show_bug.cgi?id=402167#c4 Ulrich That makes sense (actually, it calls for metadata.xml to be converted to json even without bundling EAPI in there). If repoman validated metadata.json based on a clear definition in PMS, that would be a valid solution to the problem (that wouldn't require external libraries beyond python) I'm not really convinced 'external libraries' is a critical problem; it just seems like a nice thing to (try to) avoid. -A
Re: [gentoo-dev] RFC: Change mail-mta/msmtp to be the default in virtual/mta instead of mail-mta/ssmtp ?
On 2012-03-12 10:20 PM, Robin H. Johnson wrote: One of the greatest things that bugs me about ssmtp is that if the mailserver is not available, it hangs for a while, and then it loses the email. To be fair, a queue-less design does keep it simple. Where I need a simple mail relay, I've gone with nullmailer instead, because it supports the features, and it explicitly has a lightweight daemon mode that queues mail to send. msmtp: TLS/SSL and AUTH support. Config can be easier. No queue. nullmailer: AUTH support. No TLS/SSL. Easy to configure and use. Has a queue. I like nullmailer better but usually go with msmtp. TLS/SSL is usually mandatory for login when emails go to some central mail hub and not directly to MX hosts - which is pretty much guaranteed nowadays. I am not sure if we should install a TLS-less mailer by default. Some documantation would be nice in either case. -- Eray Aslan e...@gentoo.org signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFD : .ebuild is only bash
On 13 March 2012 11:02, Mike Gilbert flop...@gentoo.org wrote: The previous council's decision does not prevent this same glep from going to the council again (decisions are not forever.) Some folks seem to think that taking glep55 back to the council is not allowed somehow (or is perhaps futile, but that is a different issue ;p) Having the full notes would be helpful in determining why it was turned down back then; I'm sure a copy of the notes exist. http://www.gentoo.org/proj/en/council/ http://www.gentoo.org/proj/en/council/meeting-logs/20100823.txt Well that was insightful. As suspected,, there was a lot of people saying Yeaahh, I don't like it, and concluding there were problems with it, but the actual technical issues still haven't been presented to us. While they're still batting for the alternative solutions, which there are known potential issues with. Or did I read it selectively? Can somebody present a real ( or even theoretical ) problem that could arise from having the EAPI in the filename that isn't some abstract hand-waving? Not trying to be a troll here, but really, I still haven't seen any. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, Mar 12, 2012 at 3:37 PM, Kent Fredric kentfred...@gmail.com wrote: On 13 March 2012 11:02, Mike Gilbert flop...@gentoo.org wrote: The previous council's decision does not prevent this same glep from going to the council again (decisions are not forever.) Some folks seem to think that taking glep55 back to the council is not allowed somehow (or is perhaps futile, but that is a different issue ;p) Having the full notes would be helpful in determining why it was turned down back then; I'm sure a copy of the notes exist. http://www.gentoo.org/proj/en/council/ http://www.gentoo.org/proj/en/council/meeting-logs/20100823.txt Well that was insightful. As suspected,, there was a lot of people saying Yeaahh, I don't like it, and concluding there were problems with it, but the actual technical issues still haven't been presented to us. While they're still batting for the alternative solutions, which there are known potential issues with. Or did I read it selectively? Can somebody present a real ( or even theoretical ) problem that could arise from having the EAPI in the filename that isn't some abstract hand-waving? Not trying to be a troll here, but really, I still haven't seen any. In general there was the 'I don't like it crowd (I was one of these, I care less these days ;p)' There was the 'it is Ciaran crowd.' This concept is difficult to describe without a fair bit of context in how the community was being run at the time. None of the above reasons are what I would term 'technical merits.' However now (as then) not all decisions are made on their technical merits. We have adopted (and continue to adopt) solutions that are imperfect, technically silly, or otherwise lots of work because they meet some goal we are trying to accomplish. I don't think Gentoo is alone in this aspect of management. The inherent problem of course is that these merits are not provable, so one cannot 'win' an argument on 'aesthetically pleasing filenames'; thus we are doomed to discuss glep55 until someone makes a decision in favor or the proponents of the GLEP stop trying to push it (which is what happened last time.) -A -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
Re: [gentoo-dev] RFD : .ebuild is only bash
On 12 March 2012 22:37, Kent Fredric kentfred...@gmail.com wrote: Can somebody present a real ( or even theoretical ) problem that could arise from having the EAPI in the filename that isn't some abstract hand-waving? Not trying to be a troll here, but really, I still haven't seen any. This isn't a real-world problem, but we're arguably over-loading too much information into the filename already; - package name - package version - ebuild revision - (EAPI?)
Re: [gentoo-dev] RFD : .ebuild is only bash
On 03/13/12 01:12, Ciaran McCreesh wrote: On Mon, 12 Mar 2012 18:05:46 +0100 Ulrich Mueller u...@gentoo.org wrote: See above, even if we should ever move away from bash, GLEP 55 is still not needed. ...but we might as well go with GLEP 55 anyway, since GLEP 55 definitely works, whereas other solutions might work so long as we don't do something unexpected. This whole thing is just an exercise in trying to find excuses not to use GLEP 55. That kind of circular reasoning makes my head hurt. We discussed that ... topic ... to death about three times over the last 2 years, and the same arguments still apply. Put an EAPI-marker in a well-defined position near the top of the ebuild, problem solved. If it needs more it's not an ebuild anymore and we should consider fixing all the other annoying glitches we have at the same time, which causes a backwards-incompatible tree format change, which means we need to plan the whole thing properly. Trying to nail on GLEP55 is just trying to fix issues arising from not fixing issues properly, so *if* we want to change things for no apparent reason we should change them properly.
Re: [gentoo-dev] RFD : .ebuild is only bash
On 03/13/12 02:28, Ciaran McCreesh wrote: [snip lots of political rhetoric] GLEP 55 is simple, No. it solves all the problems we have No, it just tries to shove them under the carpet (including the version issue, which everyone is conveniently ignoring), Say what? it doesn't require us to guess what's going to happen next and it can be implemented immediately. So can migrating the tree to posix-only ebuilds, but at what cost, and what do we gain from it? That's a rather big deal. So is switching to Arch Linux. ... why would we want to do such things?!
[gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 03/11/2012 13:33, William Hubbs wrote:
I highly discourage moving more things to /. If you google for things
like, case for usr merge, understanding bin split, etc, you will
find much information that is very enlightening about the /usr merge and
the reasons for the /bin, /lib, /sbin - /usr/* split.
I'll start another thread about this farely soon, but for now I'll say
that even though Fedora is a strong advocate of the /usr merge, it
didn't start there. Solaris started this 15 years ago, and I think it
would be a good thing for gentoo to implement the /usr merge at some
point to make us more compatible with other unixes. Another thing to add
is that it appears that at least Fedora and Debian are doing this.
On a somewhat sarcastic note, why don't we just deprecate /usr and move
everything back to /? Isn't that, largely, what is being accomplished here?
Solaris at least keeps some kernel stuff in / off of /stand (I believe).
Linux, after this /usr thing is fully complete, about the only thing left in
/ that is of any value will be /etc. Kernels were moved into /boot ages ago.
I mean, what really is / in the literal sense? It's the first filesystem
that the kernel mounts. If you put everything into /usr, including the init
scripts and /etc, create a few stub mount points for /var, /tmp, etc
(assuming those are separate partitions), then told the kernel that /usr is
/, what's the real difference? So I think Fedora's approach, while copying
existing behavior from Solaris, is partially broken in this regard.
We should be working to getting rid of /usr and bring it all back into /,
then create temporary /usr symlinks to point programs in the right
direction. After all, /usr was originally for user data, not system data,
until someone cooked up /home (I don't know the full exact history here, so
feel free to correct me).
Heck, why not redesign the original root filesystem layout while we're at it?
/ - Root.
/boot - Kernels, bootloader.
/apps - Installed, non-system critical applications. Merges /bin,
/sbin, /usr/{bin,sbin}, /usr/local/{bin,sbin}, and /lib and
all of its multilib variants.
/core - System-critical apps needed to get the system into a MINIMAL,
usable state (core device detection, mounting disks, etc)
/conf - System configuration data.
/dev - Device nodes.
/home - User stuff.
/data - Variable data. /var's new name.
/tmp - System-wide temp dir.
/virt - virtual filesystems (proc, sys, ramfs).
/svcs - Data dir for services (Apache, LDAP, FTP, etc).
/ext - holds mount points for external devices (merges /mnt /media).
/root - Superuser's /home.
From that, for the new proposed directories:
/apps/sys/bin - System binaries. Only non-critical, system-wide binaries
go here.
/apps/sys/lib - Like /apps/sys/bin above. Except this can also be
duplicated for multilib (lib32, lib64, lib128, etc).
/apps/std/bin - Standard program binaries for all non-system, non-critical
binaries.
/apps/std/lib - Like /apps/std/bin above. Ditto for multilib.
/apps/local - If on a stand-alone system, this is a symlink to /apps/std.
otherwise, this holds a bin/lib folder that is only for apps
installed locally, while /apps/std might be a network mount
that holds apps common to multiple systems of the
same/similar type of install.
/core/bin - Critical system, binaries needed to get the system into a
minimally-usable state. Predominantly occupied by various
filesystem tools.
/core/lib - Libraries, usually static, to support /core/bin. Can be
multilib, but a system should have a single ABI that can
successfully boot the userland components of the system.
/core/inf - Holds minimal information to identify and locate
boot-critical devices, typically in the form of a small
database of some design, but which can be parsed with
no additional dependencies.
/core/init- Home of your init system of choice, including all the
information needed for various run levels, etc. Its
sub-layout is dependent on the particular init system that
is installed.
/conf - Basically a rename of /etc. The etc name doesn't
convey any useful information to a user anymore about its
true purpose. /conf, however, does. Files stored here
will largely be comprised of text files that configure
various system services. Like /etc, it's sub-layout will
probably be a complete, unrestrained mess.
/virt - Everyone loves virtual filesystems. When there was just
/proc, everything was alright. Then /sys comes along, and
now we've polluted the / namespace with two virtual
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 13 March 2012 14:22, Joshua Kinard ku...@gentoo.org wrote: I thought this up on a whim, it hasn't been tested nor vetted. It's largely meant as a joke, but also to provoke discussion on the current filesystem design and the direction we're getting pulled in with Fedora's declaration that separate /usr is broken. I don't think it is and I don't find their argument very convincing, and probably never will. Why don't we just quit with this linux nonsense and all switch to Mac, after all, it just works! /cynical remarks =p -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
[gentoo-dev] Re: newsitem: unmasking udev-181
On Mon, 12 Mar 2012 18:34:37 + Sven Vermeulen sw...@gentoo.org wrote: On Sun, Mar 11, 2012 at 12:49:11AM -0600, Ryan Hill wrote: We should really have some documentation on how to create a minimal initramfs that mounts /usr (if we don't already, I haven't looked). I've never needed one until now and don't have the foggiest idea how it's done. I can't be the only one. I just started the tracker [1] for the documentation changes and sent info to gentoo-doc mailinglist about it. The upcoming days, I'll have the needed updates trickle into the documents. [1] https://bugs.gentoo.org/show_bug.cgi?id=407959 Thanks! Also, the handbook still endorses having a separate partition for /usr and includes it in the example setup. This should be changed now, not when stabilization time comes. It's an example, and we still endorse it. Only will we now tell users to use an initramfs with it. That sounds good to me. -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Re: newsitem: unmasking udev-181
On Sun, 11 Mar 2012 21:08:47 + Robin H. Johnson robb...@gentoo.org wrote: The quickest initramfs, assuming that ALL kernel modules you need to boot are already compiled into your kernel: genkernel --install --no-ramdisk-modules initramfs Plus optionally, If you know you don't need any of these, include this to make it really get much smaller: --no-lvm --no-mdadm --no-dmraid --no-multipath --no-iscsi --no-disklabel --no-firmware --no-zfs --no-gpg --no-luks --disklabel is the one that most users will probably need, if they use LABEL= or UUID= arguments in your fstab. That will give you an initramfs of scripts + busybox. On my box, it's about 724KiB. Thank you sir. The last time I played with genkernel I had to kill the result with a crucifix. This should do the trick. -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
[gentoo-dev] Re: Stabilization requests from users
Marco Paolone posted on Mon, 12 Mar 2012 18:58:37 + as excerpted: Hello gentoo-dev team, scarabeus recently posted on his blog [1] about submission of stabilization requests from users. Since using bugzilla could be a mess of duplicated entries, I was thinking about a Stabilization Party once a month for example, in order to have a coherent list of stabilizations, and users working togheter with you developers. How does it sound? [1] http://blogs.gentoo.org/scarabeus/2012/03/05/stabilisations-and-testing/ This reminds me of the bug days they used to have, once a month or once a quarter, some years ago. I haven't read anything about that for aeons now (since before arch-testers, IIRC), I'd guess since the dev(s) coordinating them retired (?), but resurrecting that idea could be useful. The stabilization party idea would then simply be the arch side of the coin, with package bugs being the maintainer side. Either way, it takes a strong leader with a decent priority for it and the time to dedicate, to pull it off as a regular thing. Without that, there might be one or two, but it'll peter out by #3 or 4... AFAIK there used to be a bug-day keyword that could be added as well. A dev could add that to any bug he thought could use some user testing, either to nail down or pre-stabilization, and the bug-day coordinator would pick bugs, mostly from that list, that he thought fit. Of course users and devs could work on any bugs they chose on that day for their bug day points, but the list was helpful for categorizing bugs that needed more testing that deep technical skill, and/or that could probably be fixed with just a few minutes to hours of work, reasonably doable in a small enough fraction of a day to allow someone to work on several the same day, if they had the time to dedicate. Back then, user bug-day activity, IRC presence, etc, was a big door to recruitment. It seems to me that many (not all) stabilization bugs should fit right in, but the idea was then and I believe should be again, broader than simply stabilization bugs, so more folks can participate. -- 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] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 03/12/2012 21:37, Kent Fredric wrote: On 13 March 2012 14:22, Joshua Kinard ku...@gentoo.org wrote: I thought this up on a whim, it hasn't been tested nor vetted. It's largely meant as a joke, but also to provoke discussion on the current filesystem design and the direction we're getting pulled in with Fedora's declaration that separate /usr is broken. I don't think it is and I don't find their argument very convincing, and probably never will. Why don't we just quit with this linux nonsense and all switch to Mac, after all, it just works! /cynical remarks =p The problem with that, is, that the system wouldn't boot without /itunes being available, so you can't partition that one off :P -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 2012-03-12, at 9:22 PM, Joshua Kinard ku...@gentoo.org wrote: And yes, I've already tested out udev-181 on a VM with a separate /usr. With devtmpfs, the system fully boots just fine, no initramfs needed. Guess what the only piece of software to mess up is? Udev. I largely think it's a timing issue in OpenRC, however, because /usr DOES get mounted fairly quickly, but not before udevd starts. But udevd does restart itself and everything looks to work fine. If you aren't watching the terminal, you wouldn't even notice the failures. THANK YOU for testing this -- I could not forsee a reason, back when this process started, as to why openrc couldn't mount /usr before udev started. since devtmpfs should provide the source devnode anyways. It's good to have a (near) proof of that. Ian
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On Mon, Mar 12, 2012 at 11:14:23PM -0400, Joshua Kinard wrote: Yeah, I think it's an easy fix either in openrc or in an initscript somewhere. I changed nothing except my kernel (was missing devtmpfs -- it's not under Filesystems!), uninstalled module-init-tools, and installed kmod + udev-181. Then rolled back the snapshot once I had the results. When udev is linked against a library in /usr, this is not going to work anymore, because udev won't start at all. On many simple setups, yes, it's not going actually break much in my testing on pure OpenRC. udev starts in the sysinit runlevel, and /usr would normally only become available later, in the boot runlevel, when localmount runs... Consider this potential boot order: sysinit/sysfs sysinit/udev (fails without sysfs) boot/modules (after udev, so udev rules work on modprobe) boot/hwclock (needs rtc modules on some systems) boot/fsck (after devices are available) boot/root (after fsck) boot/localmount (after fsck) udev before modules is fairly critical for some hardware, so that it gets configured properly. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] RFD : .ebuild is only bash
On Mon, Mar 12, 2012 at 07:17:31PM +0100, Ulrich Mueller wrote: On Mon, 12 Mar 2012, Ciaran McCreesh wrote: On Mon, 12 Mar 2012 19:00:32 +0100 Ulrich Mueller u...@gentoo.org wrote: On Mon, 12 Mar 2012, Zac Medico wrote: If we do go with a variant of GLEP 55, I'd prefer a variant that uses a constant extension (like .eb) and places the EAPI string just after the version component of the name. For example: foo-1.0-r1-eapi5.ebuild This is so ugly... I guess I'll retire the same day when such an abomination gets accepted. ;-) I'm sorry, we're down to it's ugly and someone already said no and I'll throw my toys out of the pram if I don't get my way as the arguments against GLEP 55 now? Note the smiley in my posting. And yes, it _is_ ugly. Worse, it actually makes parsing _worse_ than it already is. What G55 had going for it was ease of filtering out unsupported eapi's. Literally just filter the readdir results. This behemoth Zac is proposing basically requires throwing regex at it, and *is* able to be tripped up since eapi's aren't strictly integers (1-prefix, 4-python, 4-eapi3 if I wanted to intentionally be a dick and break likely non-greedy implementations of the regex). Same angle, embedding it into the version space means that there can be conflicts w/ PN. Basically... embedding it into the versioning like that, besides being ugly as all hell, discards the main benefit g55 had- clear identification of EAPI. It ain't worth it. ~brian
Re: [gentoo-dev] Re: newsitem: unmasking udev-181
On 3/11/12 10:33 AM, William Hubbs wrote: On Sat, Mar 10, 2012 at 07:28:41PM -0800, Luca Barbato wrote: On 3/10/12 6:53 PM, Rich Freeman wrote: neither the genkernel nor dracut docs have specific instructions about I guess we could pour more effort in getting dracut more easy to use and/or try to figure out which are the items that should be moved to / and fix the remaining ones... I highly discourage moving more things to /. If you google for things like, case for usr merge, understanding bin split, etc, you will find much information that is very enlightening about the /usr merge and the reasons for the /bin, /lib, /sbin - /usr/* split. Our current init system doesn't have any problem with /usr being mounted later, but udev might have issues. Same could be said about bluez and dbus. I'll start another thread about this farely soon, but for now I'll say that even though Fedora is a strong advocate of the /usr merge, it didn't start there. Solaris started this 15 years ago, and I think it would be a good thing for gentoo to implement the /usr merge at some point to make us more compatible with other unixes. Another thing to add is that it appears that at least Fedora and Debian are doing this. Hurd got it first if I recall correctly. But hurd is a bit fringe I'd say. lu
Re: [gentoo-dev] RFD : .ebuild is only bash
On 13 March 2012 17:31, Brian Harring ferri...@gmail.com wrote: Worse, it actually makes parsing _worse_ than it already is. What G55 had going for it was ease of filtering out unsupported eapi's. Literally just filter the readdir results. This behemoth Zac is proposing basically requires throwing regex at it, and *is* able to be tripped up since eapi's aren't strictly integers (1-prefix, 4-python, 4-eapi3 if I wanted to intentionally be a dick and break likely non-greedy implementations of the regex). Eh? How? If you make . a forbidden character in an eapi specificiation, and make . the delimiter dev-foo/foo-bar-2.3.4.eapi5.eb How does that require regex? remove the .eb , and the last token remaining is the eapi . it doesn't clash with the existing system for 2 reasons, 1) the .eb extension and 2) eapi5 is not a valid version token Same angle, embedding it into the version space means that there can be conflicts w/ PN. I'm confused as to how, can you give one theoretical example? dev-foo/foo-bar-2.3.4.eapi5.eb -- eapi5 can't be a package name here, because its got the .eb suffix which means an EAPI *MUST* be specified and eapi5 also can't be a package name there, because then you're telling be it tokenizes as: category=dev-foo package=foo-bar-2.3.4.eapi5 version = undefined eapi = undefined Which is clearly illegal. Basically... embedding it into the versioning like that, besides being ugly as all hell, discards the main benefit g55 had- clear identification of EAPI. It still seems clear to me. -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 3/12/12 8:53 PM, Robin H. Johnson wrote: On Mon, Mar 12, 2012 at 11:14:23PM -0400, Joshua Kinard wrote: Yeah, I think it's an easy fix either in openrc or in an initscript somewhere. I changed nothing except my kernel (was missing devtmpfs -- it's not under Filesystems!), uninstalled module-init-tools, and installed kmod + udev-181. Then rolled back the snapshot once I had the results. When udev is linked against a library in /usr, this is not going to work anymore, because udev won't start at all. So you need need a smaller udev that is completely self contained and make sure anything needed for the key rules works. I wonder if the pci-ids cannot stay somewhere in /etc or /lib lu
