Re: [gentoo-dev] Parallizing ebuilds - 'trivial' ebuilds
On Jan 13, 2006, at 8:05 PM, Philippe Trottier wrote: Recipe for disaster, specially in a place like mine where sparc, alpha, x86_64 and ppc32/64 mix... not counting ia64 for a test run soon... If you really want to do this, someone has to make a rendezvous a la Apple. Where not only distcc says I am available but I am also doing the right stuff. This all is something, icecream[1] can do, i think. I am very interested in getting icecream to work with gentoo. [1] http://wiki.kde.org/icecream Philipp -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Improving Gentoo User Relations
On Apr 7, 2006, at 11:56 AM, Jakub Moc wrote: I bet there's a bug open for it. http://bugs.gentoo.org/show_bug.cgi?id=117482 . How's portage 2.1 getting along? I notice it gets frequent updates. The gentoo-portage-dev list is the place to follow this. Also, http://bugs.gentoo.org/show_bug.cgi?id=115839 On GWN there are always things "heard on foo-ML", "heard on bar-ML" or "heard on te forums. But since many information seems to be in bugzilla, wouldn't it be nice to inform the bugzilla team of importagt "tracker bugs" and have a section like "heard on bugzilla"? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Improving Gentoo User Relations
On Apr 7, 2006, at 4:47 PM, Christel Dahlskjaer wrote: On the other hand, this problem does have a solution--another level of indirection. Anybody who wishes, dev or user, could spend time tracking Gentoo development (through bugs and the mailing lists) and submit status reports to the GWN. Care to volunteer? I'd be happy to provide pointers on how to get started. I may grab you on IRC later and see if you can tell me your pointers, I like his idea and I'd like to look into it! I'm very interested in this, it would be very nice if you could write some type of document with some of the ideas, hints and pointers in it. Thanks, Philipp -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] better support for binary packages
Good morning, I want to talk about improved binary package support for Gentoo. About 1-2 months ago there already was a discussion about this on gentoo-soc@ and on bugzilla [1]. If I remember correctly, there were no devs involved in the discussion, so I thought I'll post my thoughts here. I know, that Gentoo is a source-based distribution or meta-distribution, and I don't want to make Gentoo another Fedora or Ubuntu, but I think there are some things we can learn from them. The current situation: Binary packages are (usually) stored in /usr/portage/packages/$category/$package-$version.tbz2. The package consists of the "real binary package" and the metadata (combined using xpak or whatever). Problems I see with this: 1) If a binary package is built because it needs to be linked against a new library, because the USE-flags change or because the ebuild changes without a revision bump, the "old" binary package is overwritten. This also means that there is no support to store multiple packages with different USE-flags without, well, using different directories. 2) To find out which USE-flags a package is built with, one needs to download the package and look at the metadata. Today I discoveres a file called "Packages" which looks like a metadata cache, but I did not find more information about it (only tried "man portage"). So, how can we address this? First we should do something about 2), I think: I want to propost the following scheme: Binary packages are stored in $arch/$description/$category/$package/$package-$version-$ev-$use-$bv.tbz2. $arch: This is x86, ppc or whatever you put into ACCEPT_KEYWORDS minus the '~'. It does not make sense to make a distinction here. $description: Something like pentium3, core2quad, G4, or whatever. Pentium3-uclibc, Pentium3-solaris-prefix are also possible. $category, $package and $version should be clear. $ev: The "ebuild version". See below. $bv: The "binary version". See below. $use: The USE-flags. See below. About ebuild version, USE-flags and binary version: I would like to encode the USE-flags into the filename. This enables us to have binary packages of the same version built with different USE-flags in the same repository. Some wanted to have this in the directory, some say it is ok to have it in the xpak only and some prefer the "Packages"-like file. I think, USE-flags can be set per package and therefore should be stored per package, not per $description or whatever. Having it only in the xpak allows no distinction between multiple binary packages, same version, differen USE-flags and the same is true for the Packages file. This would also be created, downloaded all the time and so on. Therefore I think the cleanest solution is having USE-flags in the filename. There are different methods to store it there. a) A checksum (of the USE-flags, the USE-flag string, the ebuild and the USE-flag string, whatever). b) List the enabled USE-flags in the filename, use a) if the string gets too long. c) Use a packed binary vector. I don't like a), because it is not easily reversible. You could always download the Packages file or the binary package and look into the xpak metadata, but that's too much effort. b) also has the problems i mentioned for a). Also, you'd need some system to distinguish ebuilds with the same version but different USE-flags. You also need that for c), so b) has no advantages ofer c) in my eyes. For c) I think of the following: Sort the USE-flags in some defined way (ASCII code, whatever) and make a vector with a 1 for every enabled USE-flag and a 0 for every disabled USE-flag. Compress that vector: If you use HEX code, you need 1 character for every 4 bits, but it should be possible to find 64 different characters, then you need 1 character for every 6 bits. PHP has 106 USE.flags, that would make a USE-string with about 18-27 characters. Packages with lots of USE-expand stuff like languages would need more, but not too much, I think. Problems: The string might get long, you get big problems with USE-flag renames, USE-flag additions or removals. That's where the ebuild version is needed. Or not. We have 3 possibilities: a) Change policy: USE-flag changes in an ebuild need a version bump. b) Use a checksum of the ebuild. c) Use the version given by the version control system. The problem with a) is, that is a change in policy and probably hard to do. Increasing the revision for a (trivial) change leads to a lot of unnecessary rebuilds for users. It also means, that USE-flag changes in eclasses are difficult, the eclass should probably copied over to a new name with version and only ebuilds with a new version (revision) are allowed to use it. The problem with b) is, that it is not ordered. You don't know, which is the newest version. If you have an ebuild with a version where there is no binary package for, it gets difficult/ugly. c) also has problems: When using cvs, there are versions easily available. The same is true for svn
Re: [gentoo-dev] Re: better support for binary packages
Hi Duncan, I don't see the connection between the email Fabio wrote and your answer. Do you want to say, that you agree that he's doing what i described and that it works the way i described it? I doubt it. If you really care, could you answer my first email and state there the problems you see with the approach and why you think this is making Gentoo worse? On Mon, 2009-05-25 at 11:43 +, Duncan wrote: > Gentoo is in general a from-source metadistribution. There's limited > support for binary packages in at least one of the package managers > (portage), but honestly, that's not what Gentoo's best at, and I don't > believe that will ever change without making it significantly worse at > what it IS best at now, the normal from-source Gentoo we know and love. But how would you make it worse? It already has the functionality to add repositories for binpackages, why not improve it? Why leave it the way it is? > Better to leave the serious distribution level binary repackaging to the > Gentoo-based distributions like Sabayon. Let them do what they do best, > and let Gentoo continue doing what it does best. By definition, binary > packaging isn't broken and doesn't need fixed, as that's not part of what > defines Gentoo, so don't fix what ain't broken! =:^) Well actually, some time ago Gentoo was by definition running a linux kernel or a BSD kernel and now it runs in a prefix on Windows and AIX and Solaris. Some time ago there was some guy called drobbins who was kind of the leader of Gentoo and now we have a council. If you really don't want changes, you could stop running emerge --sync. > That said, I could envision an eselect like "binary profile" switcher, > that subject to settings in a config file, changes USE flags, CFLAGS, gcc- > configs an appropriate gcc version, etc, changing PKGDIR appropriately as > well, so one could easily enough create as many "binary profiles" as > desired and as the use case dictated. It's likely various reasonably > large Gentoo deployments are already doing something like this as it > could certainly be scripted, but an emergable package to make it easy for > ordinary joe Gentoo user would be useful, and I believe appreciated by > many. > > (Here, I'd put it to use when testing new gcc versions, making it easy to > swap out PKGDIRs and revert to the old version either per-package or > system-wide, if the new version was breaking too much.) > > So here: No to the whole big complicated let's fix Gentoo binaries > thing. There's already Gentoo-based binary solutions like Sabayon for > those so interested, and I can't see Gentoo doing better than they're > doing, at least not without breaking the from-source that Gentoo's good > at. But yes to anyone interested in developing a nice new "binary > profile" switcher to make managing binary package sets easier for those > Gentoo admins that would find such a thing useful. Whether they then > start making those profiles public and whether anyone else chooses to use > them is entirely up to the individual admins whose systems would be > affected. Not sure, what the binary profile switcher really would change here. What I was talking about were mostly USE-flags and packages, and I guess your binary profile switcher doesn't change too much, there. It would be ok to do all this stuff in an extra project, without Gentoo. But there are some downsides: You are not Gentoo anymore. The communication channels get longer and more complicated. In my first post i described some things that would need to be changed. Either in portage or in the policy how packages are dealt with. Well, the last is a little bit impossible outside of Gentoo (I don't want to fork the tree) and I also don't want to fork portage, so the first is complicated, too. And all this layer thing Fabio was talking about. I did not try it and I did not read the code, but I think it makes things much more complicated. See also the discussion about mixing package managers between Gentoo and Sabayon. I do not want these problems. Philipp
Re: [gentoo-dev] Re: better support for binary packages
On Tue, 2009-05-26 at 11:27 +0200, lx...@sabayonlinux.org wrote: > On Tue, May 26, 2009 at 9:05 AM, Philipp Riegger > wrote: > > And all this layer thing Fabio was talking about. I did not try it and I > > did not read the code, but I think it makes things much more > > complicated. See also the discussion about mixing package managers > > between Gentoo and Sabayon. I do not want these problems. > incorrect. Give it a spin ;) I'll do, if i find the time. > Problems we have were *only* related to Portage world file handling, > fixed some time ago. I am sorry to say that the issue reported here > doesn't seem to be valid. Of course, if you mix both, you need to pay > attention to not change USE flags (for eg.) that trigger libraries > compilation, but that's a known binary-world problem. You're talking about binary-world problems here that Gentoo as a source based distribution does not have, I assume. This is a strength of Gentoo and I think we can keep it for binary packages by a good design. If you emerge a package in Gentoo it gets build from source. If you use a binary distribution, you cannot influence, what flags were used for building the package. But with a hybrid approach (I was aming for that one in my proposal), you would simply have the choice to either install a binary package and be restricted, if it's not available in the way you want it, or install it from source. And it would work together, because you don't have 2 package managers that need to interface, talk, share, work together, whatever, but you have 1 package manager that does it all and can keep it consistent. > I agree with you that there could be some more room for improvements > here and there (especially in kernel module ebuilds), but with EAPI=2 > we're going in the right direction. Kernel packages and kernel modules are not really of interest for me. I would keep them as source packages. My aim is not to make thigns easier, but to provide the user with the tools to save 8 hours of compiling openoffice or something like that. Not a binary distribution, but some kind of -bin packages, just packaged by Gentoo and better. Philipp
Re: [gentoo-dev] Re: better support for binary packages
On Tue, 2009-05-26 at 08:48 +, Duncan wrote: > Philipp Riegger posted > 1243321504.9661.14.ca...@hspc30.informatik.uni-stuttgart.de, excerpted > below, on Tue, 26 May 2009 09:05:03 +0200: > > > I don't see the connection between the email Fabio wrote and your > > answer. Do you want to say, that you agree that he's doing what i > > described and that it works the way i described it? I doubt it. If you > > really care, could you answer my first email and state there the > > problems you see with the approach and why you think this is making > > Gentoo worse? > > I agree that an independent approach is the way to go. Gentoo (or > rather, its PMs, package managers, all three of them, of which portage is > only one) doesn't do binaries really well, certainly, but I really don't > see that changing within Gentoo itself, except at the expense of from- > source, which it does quite well indeed. Again, I see this as completely independent "features". Binary packages would only support the building from source and binary packages could never be created without ebuilds. This might even improve the quality of the ebuilds in the tree, because they would get built from time to time, build failures would get reported and all that. > > But how would you make it worse? It already has the functionality to add > > repositories for binpackages, why not improve it? Why leave it the way > > it is? > > Sure, improve it, but what you are talking about isn't a simple > improvement, but a massive rearchitecting. That's not easily doable > without a chance of focus. It's that change of focus that would > eventually kill the quality from-source support we have and that > continues to develop, now. Are you sure? How code would it take to look for a binary package in a different path than now? 1 additional line or 1 line exchanged? How much code would it take to create this packed bit vector out of the USE-flags? 5-10 lines? Changing portage to _also_ support the new kind of binary packages might be done in 1 day. And this is the first step. > >> That said, I could envision an eselect like "binary profile" switcher, > >> that subject to settings in a config file, changes USE flags, CFLAGS, > >> gcc- configs an appropriate gcc version, etc, changing PKGDIR > >> appropriately as well, so one could easily enough create as many > >> "binary profiles" as desired and as the use case dictated. > > > Not sure, what the binary profile switcher really would change here. > > What I was talking about were mostly USE-flags and packages, and I guess > > your binary profile switcher doesn't change too much, there. > > Sure it does, but incrementally. Basically, your proposal laid out a > complicated tree based on metadata, a tree the package manager would have > to understand and support, what I'm proposing is to allow the same thing, > but not by adding all that complication to the package manager, but > rather, by using a newly created application to switch among the branches > of that tree on request. Which might work, but would lead to a really strange package tree with really big restrictions and disadvantages (no package sharing, no way of finding out if an update is necessary,...). > Portage (or other PM) would use its configured > PKGDIR and wouldn't understand the tree, but it wouldn't need to, because > the switcher would manage switching between the branches according to its > configuration. And there the flexibility goes. If you want to emerge PHP and there is a binary package with the same USE-flage but also cli enabled or something like that, it would really get complicated to inform you (the user) that a simple and probably not too important change for you might save you an hour of compilation. > The result would be that in a large enough deployment to have build- > servers, the build server(s) could build a particular set of CFLAGS/USE- > flags/gcc-version/arch/whatever, then switch to another branch and build > that set. Individual package clients could simply point at the > appropriate tree and get most of their packages, at least the common > ones, that way. > > Now this wouldn't directly give you the flexibility of the package name > changes you proposed, but it could do so indirectly, putting that > information in the directory tree if configured to do so. Clients may > need to use the binprofile switcher as well, for individual packages they > chose to build outside their normal USE profile, but the process could be > automated once properly configured, using PM hooks as appropriate. And as soon as you use PM hooks, you ask yourself, why you did it
Re: [gentoo-dev] New app-eselect category?
Hello world! On Tue, 2009-05-26 at 16:24 +0200, Tiziano Müller wrote: > Am Dienstag, den 26.05.2009, 09:04 +0200 schrieb Ulrich Mueller: > > As of today, app-admin contains 179 packages. > > We could move the 27 eselect-* packages to a new app-eselect category > > (eselect itself would stay in app-admin). > > > > Opinions? > > Yes in general. Maybe think about what happens when the Universal Select > Tool gets released/used. Possible alternative: app-select? How will that tool be called? Maybe uselect? Another alternative: app-xselect. Philipp
Re: [gentoo-dev] Packages maintained by trapni need a co-maintainer
On Sat, 14 Apr 2012 14:24:25 +0300 Samuli Suominen wrote: > On 04/14/2012 02:16 PM, Pacho Ramos wrote: > > Due long devaway, his packages need a co-maintainer, feel free to > > add to metadata if you want. Thanks: > > dev-util/ciabot-svn > > media-sound/teamspeak-client-bin > > media-sound/teamspeak-server-bin > > sys-apps/newrelic-sysmond > > > > I believe it's time to lastrite teamspeak* because they link against > mysql libraries with SONAME we don't ship anymore > Therefore rendering the packages useless Can you elaborate on this? I have these ebuilds in my local overlay, renamed to install the latest versions. So maybe a (really simple) version bump would be enough. Philipp --
Re: [gentoo-dev] news item: upgrading to postfix-2.9
On 17.07.2012 16:49, Michael Orlitzky wrote: After changing these for years, I finally realized that the defaults are correct: # postconf -d readme_directory html_directory readme_directory = /usr/share/doc/postfix-2.8.9/readme html_directory = /usr/share/doc/postfix-2.8.9/html Do we really need to include them in main.cf? It would be great to remove it from main.cf. Also: "home_mailbox" is set at the bottom of the file. Why not set it directly below the examples for that parameter? Philipp
Re: [gentoo-dev] Moving our/portage stuff to var
On 17.12.2012 11:23, Diego Elio Pettenò wrote:
On 17/12/2012 11:19, Tomáš Chvátal wrote:
I've always myself override these defaults in make.conf to point for
/var/portage/ (not /var/lib because I never bothered enough how to
make world and config files to be put elsewhere :P).
I would say let's work on that so that portage can keep them there.
Although I'm more for /var/cache/portage myself, as both distfiles and
tree can be re-generated.
With this change distfiles and packages could be moved to a directory
which is not a subdir of portage. Something like
/var/cache/{portage,distfiles,packages}
or
/var/cache/portage/{tree,distfiles,packages}
since the file types and storage requirements are so different. At least
I prefer not to have too many filesystems mounted inside each other.
Philipp
Re: [gentoo-dev] User support system
On Aug 16, 2006, at 4:04 PM, Mike Bonar wrote: On the plus side it would be much easier to find duplicate bugs since the titles would be uniform. I think this is an interesting point. I'd like to have something like a specialised bug system for ebuilds, where you have to enter the package category, package name, package version and where the bug happens (configure, compile, test, install, execution). Then it would be much easier to look up for example all bugs concerning test errors or all bugs of glibc with compile errors. If a bug belongs to several categories, it should be able to post it in several categories. But at the moment there are some things you shouldn't have to search for because there are too many bugs with that name in the topic or somewhere else which have nothing to do with that specific package (unfortunately i cannot tell an example, but that happend to me more than once, i always filed a new bug then because i did not find anyting and sometimes t was a duplicate). Philipp -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] User support system
On Aug 23, 2006, at 3:54 PM, Alec Warner wrote: On the plus side it would be much easier to find duplicate bugs since the titles would be uniform. I think this is an interesting point. I'd like to have something like a specialised bug system for ebuilds, where you have to enter the package category, package name, package version and where the bug happens (configure, compile, test, install, execution). Everyone has good ideas, no one has a good implementation. aka, implement it :P I'm not that familiar with bugzilla. The easiest way could be to haev just another field like the email field for caterory/packagename (or with specific version if it is not a general bug) and another one for the ebuild phase in which the bug occured. I don't know how flexible bugzilla is with such modifications. Maybe some infra people could comment on this? Philipp -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Christian Marie (pingu)
On 19.12.2006, at 12:07, Mark Kowarsky wrote: We are currently dominating the southern hemisphere (with our army of 5), but world domination is still a very distant prospect. But lot's of world dominations started with domination in australia. So don't give up. :-) Philipp -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tr1 dependencies
On 30.01.2007, at 09:36, Ciaran McCreesh wrote: | * have the application bundle a static implementation and switch to | system on at configure time as done for other libs? At something like five megs of code per application? If you make that decidable by a USE-flag like minimal? Philipp -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tr1 dependencies
On 30.01.2007, at 11:40, Ciaran McCreesh wrote: | > | * have the application bundle a static implementation and switch | > | to system on at configure time as done for other libs? | > | > At something like five megs of code per application? | | If you make that decidable by a USE-flag like minimal? Which solves what, for your average user? If the user decides to have a minimal installation, he has to take care not to break it. BTW, doesn't revdep-rebuild find the problems in such a minimal installation? Philipp -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tests
On 02.05.2007, at 02:32, Marius Mauch wrote: a) cost (in terms of runtime, resource usage, additional deps) Tools for this could be implemented in the package manager. The package has to be installed and tested by the developer, so if portage would show the times for each stage or the times for the test and the rest or something like that, the developer could get an idea: If test time is smaller than build time (or less than half of complete time), than it's not that much cost. It test time is less then 1 hour (or whatever), than it's not that much cost. In any other case it's much cost. b) effectiveness (does a failing/working test mean the package is broken/working?) To figure this out before releasing a package to the tree might be lots of work. so this could be figured out later. If there are bugs about tests failing, try to reproduce it or ask the reporter to do some tests if everything is working as expected. c) importance (is there a realistic chance for the test to be useful?) This can easily be decided, as mentioned in other posts (scientific packages, core packages, cryptographic packages,...) d) correctness (does the test match the implementation? overlaps a bit with effectiveness) This might be a lot of work. I think this cannot be tested in a sane way for every package. So it's probably up to the maintainer/herd or upstream to decide if he/they sould take care of this Philipp -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Pending death of mail-filter/spamassassin-ruledujour
On Fri, 2007-08-03 at 12:48 -0700, Drake Wyrm wrote: > It's not a vulnerability in Rules du Jour. It's a bunch of spammers > attacking the Rules du Jour servers and ISP. SARE has also been down a > whole bunch over the last couple of months due to the same attack. Which will probably never happen to gentoo, because of the rather bg mirroring system. So, would it be possible to host daily (or hourly) snapshots of these rule files (or something like that) and tell the world that we do so and that they can download these in the nightly cronjob? That migth solve a problem and i don't see it becoming a problem for the gentoo mirror infrastructure. Philipp -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Fri, 2007-08-03 at 15:06 -0700, Chris Gianelloni wrote: > So, what do you guys think? One problem i see is changing versions in the tree but not puting the changes to the wip ebuilds in an overlay or somewhere else. Is there a system to email any changes done to ebuilds maintained by developer X to developer X? Like... selective commit mailinglist? Philipp -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Sat, 2007-08-04 at 01:34 +0300, Petteri Räty wrote: > >> So, what do you guys think? > > > > One problem i see is changing versions in the tree but not puting the > > changes to the wip ebuilds in an overlay or somewhere else. Is there a > > system to email any changes done to ebuilds maintained by developer X to > > developer X? Like... selective commit mailinglist? > > No. Might that be an interesting feature for helping devs keep up to date with their maintained packages? Or are there reasons against this? This could of course be muteable... Philipp -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Fri, 2007-08-31 at 18:13 +0200, Tobias Klausmann wrote: > I find the persisten-net-generator.rules particularly annoying > (for various reasons including, but not limited to system images > and system cloning). > > So I have an empty file of that name and happily nuke whatever > comes along with udev updates. I could of course unmask that > file if it were to be masked in the future. INSTALL_MASK = [space delimited list of file names] Use this variable if you want to selectively prevent certain files from being copied into your file system tree. This does not work on symlinks, but only on actual files. Useful if you wish to filter out files like HACKING.gz and TODO.gz. Philipp -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Managing users and groups
On Sun, 2007-09-09 at 06:14 +0200, Daniel Pielmeier wrote: > A group/user is created when no other ebuild has the dependency and is > removed when the last ebuild has been removed which needs it? This blows up if you have to uninstall and reinstall a package, caused by blockers or whatever. Files exist that still belong to the user/group, new user/group have different ids. So either make sure the uids and gids stay the same or just leave them be. Usually you have an extra user for security reasons with minimal access rights. There is absolutely no harm in that. I would prefer this to be another eclean function or something like that, which scans passwd, shadow, group, package database and all the files and dirs for owners. Philipp -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Building custom package for multi-arch/system
On Thu, 28 Jan 2010 16:17:41 +0100 Beber wrote: > So, I did a wrapper to emerge --buildpkg to create tbz2 with SHA1 in > names function of USE, like : > CHOST="x86_64-pc-linux-gnu" > ACCEPT_KEYWORDS="amd64" > tcpdump > > USE="+chroot +ipv6 -ssl -test -samba -smi" > is placed > under > /data/pkg/amd64/x86_64-pc-linux-gnu/net-analyzer/tcpdump-4.0.1_pre20090709+2bf4bfffad82d4ae519f76770b4f7db7b4416738.tbz2 > > USE="+chroot +ipv6 +ssl -test +samba -smi" > is placed > under > /data/pkg/amd64/x86_64-pc-linux-gnu/net-analyzer/tcpdump-4.0.1_pre20090709+5e099e8337e4cadfceda6ccf4c881fbb495980bd.tbz2 > So these are the SHA1 sums of the packages? Nice. I would like to see something like this: With different CFLAGS, CHOST etc. the user should set a seperate PKGDIR. USE-flags are encoded in the filename: Sort USE-flags alphabetically, use a 1 for every enabled and a 0 for every disabled USE-flag, make this array smaller using hex code ore base64. > USE="+chroot +ipv6 -ssl -test -samba -smi" 11 tcpdump-4.0.1_pre20090709+c0.tbz2 > USE="+chroot +ipv6 +ssl -test +samba -smi" 111010 tcpdump-4.0.1_pre20090709+e2.tbz2 Problem with this is, if anything with the USEflags as we see it from outside changes (USE-flags are added, deletes, renamed and therefore change position), this gets none-unique, which can be fixed in several ways. Philipp
Re: [gentoo-dev] Building custom package for multi-arch/system
On Thu, 28 Jan 2010 22:31:04 + "Robin H. Johnson" wrote: > But if you built and linked against openssl-0.9.7*, then upgraded to > openssl-0.9.8, you can expect breakage. But can't this be kind of ignored and solves the Gentoo way? If the binpkg does not work, don't install it and simply rebuild it (if not stated otherwise on the command line)? Philipp
Re: [gentoo-dev] Re: New global use flag: vpx or vp8
On Fri, 13 Aug 2010 10:11:32 +0200 Peter Hjalmarsson wrote: > So I think a USE="vp8" or USE="webm" (probably the first) to enable > decoding, and USE="vpx" should be used to fine tune what > implementation to use. Having USE="vp8" (no USE="vpx" specified) in > make.conf should give you support for vp8 in all packages and the > implementation should be the maintainers preference for that package. +1 Philipp
Re: [gentoo-dev] rejecting unsigned commits
On Sun, 27 Mar 2011 17:04:56 -0500 Jeremy Olexa wrote: > > this is especially important for the people doing arch keywording > > since they make a ton of commits. i'm looking at you armin76. > > One thing I don't get amidst this whole conversation is why I should > sign a Manifest file when committing KEYWORDS or something equally as > trivial like deleting ebuilds. By signing the Manifest, I interpret > that as "yes, I committed this Manifest file and yes I trust every > hash in this Manifest file" when in reality, I have no clue if the > Manifest file is correct because I didn't inspect anything. > > Am I missing something? You sign, that you did this. More or less. The guy before you did the same. If there is an error all previous revisions of the tree are available and you can check, whose mistake it was. Nothing really changes, but I can check whether a gentoo dev committed the change and who it was (and that it was not anybody who hacked some rsync mirror). Philipp --
