[gentoo-dev] File counter
Ok I was a bit quiet lately but that's only because I was vocal elsewhere (irc) ;).. You can find attached a little script I wrote last night to get a count of files in $FILESDIR for packages to make sure they just are the few needed, as I'm moving the patches for packages which needs 2 or more patches every versions in patchset tarballs which get downloaded only when requested. It's a probably-wrong, dirty, bad-looking bash script, but it works fine here. It must run from a portage basedir (it should work also on a personal overlay anyway), and accepts two parameters: the first is the name of the category if you want to check just one, the other one is the minimum number of files to report, the default is 1, I usually make it 3. Hope this can be useful. -- Diego Flameeyes Pettenò Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ countfiles.sh Description: application/shellscript pgpDNT3Aqs8wm.pgp Description: PGP signature
Re: [gentoo-dev] OpenLDAP 2.2 series
On Sat, 2005-04-30 at 19:00 -0500, Grant Goodyear wrote: Thanks for the note. My personal opinion is that this sort of news item is the sort of thing that we need to do a better job of announcing widely. I'm going to CC the GWN folks on this e-mail as well as our PR folks, to see if either of those groups want it. I know this might not be the most popular thing, but shouldn't we also post this stuff on the front page (or at *least* a sub-page) of www.g.o? I think that anything that is potentially compatibility or functionality breaking with a package upgrade *really* needs as much exposure as possible, to keep the complaints down and to increase the probability of somebody finding out about the changes before they go in and wreak havoc on their already-working system. -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Mon, 02 May 2005 14:22:15 +0200 Michael Haubenwallner [EMAIL PROTECTED] wrote: | Hi ebuild devs, | | Here's a glep draft now for (a part of) the long-term portage-goal | act as a secondary package manager ... Why did you post this without addressing the problems I pointed out to you previously? Writing something up as a GLEP doesn't magically fix all the holes in it. Oh, and by the way, we don't follow FHS. -- Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, shell tools) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpE4zkosCpXz.pgp Description: PGP signature
Re: [gentoo-dev] gnome repoman
On Monday 02 May 2005 10:47 am, Michael Sterrett -Mr. Bones.- wrote: Here's the repoman from this morning with the word gnome on the line: i fixed the hppa crap last nite and started ia64 -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Cutting down on non-cascaded profiles
Stephen P. Becker wrote: Portage should have been warning such users about using a deprecated profile for some time now. So, they should have updated to a new profile by now. Surely most people have synced portage sometime recently and done an emerge -uD world. If somebody is using a portage snapshot from two years ago, they have more problems than a deprecated profile. What is bad about doing *only* `emerge --sync` and security updates? This is not my case so it's quite possible that no such users exist (so the gentoo-dev ml isn't probably the best place to ask if they exist, btw), but if you do something that will prevent *everyone* who is so late with upgrades from continuing, you'll introduce (IMHO dangerous) precedence about backward compatibility. So I'm just asking if those users (even if nobody like that exist) have an ability to upgrade or at least to carry on with their security upgrades (which could of course require update of sys-apps/portage, this is perfectly correct). Good thing is that `emerge --sync` produces warning about using deprecated profile, so it will probably catch the attention. You do realize that for the most part, gentoo versions don't mean very much, right? A gentoo install is as current as the portage tree, no matter what installer was used. Sure. TIA, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Cutting down on non-cascaded profiles
Stephen P. Becker wrote: This is really getting into a whole different discussion altogether about having a security update only tree, but there has been talk of this a few times before...search the mailing list archives. Yep, of course I know; I wasn't asking for stable tree. Removing old profiles will do nothing other than forcing them to set a new profile. Changing the profile won't stop people from doing security only updates. Okay, as long as changing the profile won't affect people *much* (I mean if it doesn't break their boxes), it is perfectly correct. I asked just to make sure that broken /etc/make.profile won't completely screw up Portage or so :-). -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
Michael Haubenwallner wrote: Hi ebuild devs, Here's a glep draft now for (a part of) the long-term portage-goal act as a secondary package manager ... Comments welcome, haubi It's fancy, but what about ROOT? You don't like it just because you'd have /usr/local/usr/bin/foo? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Cutting down on non-cascaded profiles
Jan Kundrt wrote: Stephen P. Becker wrote: Removing old profiles will do nothing other than forcing them to set a new profile. Changing the profile won't stop people from doing security only updates. Okay, as long as changing the profile won't affect people *much* (I mean if it doesn't break their boxes), it is perfectly correct. I asked just to make sure that broken /etc/make.profile won't completely screw up Portage or so :-). Actually... things are more likely to break if you leave the system as-is. The toolchain and libs will be getting quite old, and while the updated packages should be backward compatable, they may not be. Anyway, wouldn't security updates include the core system, rather than just things like Apache? -- +-+ | Stuart Longland -oOo- http://stuartl.longlandclan.hopto.org | | Atomic Linux Project -oOo-http://atomicl.berlios.de | | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | | I haven't lost my mind - it's backed up on a tape somewhere | +-+ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Cutting down on non-cascaded profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The only dish I have is what if a new profile doesn't support what they are attempting to do? If something is profile masked ( gcc fex ) there is no way currently for a user to unmask it, even in /etc/portage. In the end they just might symlink make.profile to /etc/portage/profile and just make their own, although again it seems rather hackish. Is there documentation guides for modifying ones own profile? Certainly the portage support is mostly there ( if one points make.profile to /etc/portage/profile it technically is all there ). I guess as a user it would be nice to see a migration/setup guide for a profile setup, perhaps I will write one ;) Stuart Longland wrote: Jan Kundrt wrote: Stephen P. Becker wrote: Removing old profiles will do nothing other than forcing them to set a new profile. Changing the profile won't stop people from doing security only updates. Okay, as long as changing the profile won't affect people *much* (I mean if it doesn't break their boxes), it is perfectly correct. I asked just to make sure that broken /etc/make.profile won't completely screw up Portage or so :-). Actually... things are more likely to break if you leave the system as-is. The toolchain and libs will be getting quite old, and while the updated packages should be backward compatable, they may not be. Anyway, wouldn't security updates include the core system, rather than just things like Apache? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQnbJuGzglR5RwbyYAQJNNQ/+Ofcg2B5tDlACAlYs3tIlSFOs21Q6PzyQ Nvw5w7qah7lm7goF3qygwGqi7NQwGY04hB3Qp2yIEEhR1gBQkUuh8s9dXrRjobU5 OGhJ4tOyK60L9/RPZw0cy4oLZkVJCYnMYlBa710zzQ9sbJMJPYeR8on8rDhmXsNw aPTRHhE1EFB2VRELwkbfl3FXp/UzJb0INBab4D61HEtPz4Ie2YTCVN2lGiSt7MYm ywFR6NInOrnxeB0TSeult+E4WE6CTuaLdIfhcekt+UgPUNrqb70f3Vnr4i08pAb4 1MTT/DeP31CxkWvNT5Jhw4bh4gEBqJm+lMjh2pomKDorJm/P5jGb0rK/a4YLn0A8 VIm3Wkha/wTdhSMUU07JQcAMmjFVruU/usHeWEvCNM1+b7bWRYVwS0iuPu1wVHKc bHH67oWYYZsN24cX+BOTwiInx51z84OxWxeJf1SDBLu5kDtGj5+wIdE0hxPuBoAR QnHWIgB6P2iQpAXlpi2KdeO/9ZhxBvRgu54e/3JSHpISVL1zQ2Ok95F+3/DGKXtG DoDOVSMMLTtpXZR6SlTIAjKr5dULAnNBPd2egDHDNxLPWZNJZP+cL+Hxl80dgmnI O0taYtrsFaXQ/25HDyjEn6Tn3DtFcrmGWBkPA6salKRNxfGlTQasjkpSVPZGMThc 2qMTbZpY2jQ= =Briz -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Jackson wrote: Michael Haubenwallner wrote: Hi ebuild devs, Here's a glep draft now for (a part of) the long-term portage-goal act as a secondary package manager ... Comments welcome, haubi It's fancy, but what about ROOT? You don't like it just because you'd have /usr/local/usr/bin/foo? ROOT doens't work for DEPENDS, only [R,P]DEPENDS which means I can't install everything for pkg FOO in ROOT=/opt fex. Mostly useful for alt arches when /usr is taken by the primary OS and you need portage's DEPEND packages to go somewhere else. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQnbMxWzglR5RwbyYAQJR7BAAmi8n2DGmN+icAJODkYQQYhLDmK+AJe86 aGS2sp2gtVufZEIjDWixtmOvxnNb4i5WSwxHCFI3sRK0WdtshFjMOVaPDoajnnUk QAEsExe90DLiwQQN55BABjC3x5kKLhuyEpH3MYMQOrv1lGOclD3j/jRRoVgakBJF YF7o0LIEZNSeby9cqTWzBx9G+4WgLVtAFBkKc7NqvqusYuyEWr2MI7eI0D8WuEXT BZfB1uJtKbLXBbtUNbOYAxYOnGvQieKTVErlg+Of+7qsoX3fiYn9Y09ERIK5qRQ0 k4lIwZ+75bRiANvgfBQM90G87fUTgJsIuXmVhrVc0Z4L4tfIcFuVvV16w9efiY91 JVxkUCrb8ZJPI8ScIv/sPUWAkzSKYL66xtMaVhzyeT4E6ZPD7mZcNGFu4D/oNL1Z CpDlrkuIuBWTJOCz3vlG4bm4x9HWFi44ukq8bFMr0iiimPicJW+QoTpvZKhnMaSC mdy7Z/rAcsIvnwcQRgcmJeCAmQQ1xVz/h/X4AyMMApAwVAFgzFvEWC7AWnxCAGMd EVTX7D5paNA3yia9nDkEcJ1ryNhjEEQ83lFwtcRnlXNDuRQ/9bk/XzLBPXONMhye n8rK8v+xcn0bGgjG9s2wwiMSxTQWxibqY4CB0DZR43KsL+jw3MD0B34HAbTBPE19 +mxWlsBDV+U= =8uFj -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Cutting down on non-cascaded profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: On Monday 02 May 2005 08:45 pm, Alec Warner wrote: The only dish I have is what if a new profile doesn't support what they are attempting to do? If something is profile masked ( gcc fex ) there is no way currently for a user to unmask it, even in /etc/portage. yes there is, you just didnt read enough in `man portage` -mike apparently I didn't ;) *goes off to unmask things* -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQnbUX2zglR5RwbyYAQIm9Q/9Hm+1y5sQv+sDturHheKQCANN4l/tXARP Kr+5H8WMkD895VeiRQPZdae1fjyul6wmY0hjYYP+pXnKLe48Cn5CygwRDkqajgzN j3n012hXeJXF3c8cXh1XvMeaXt5llVT5LKfOaLp0hoXAPb7JzXdfacUFbRdHIGaS 000vJFyssP6e9+ZyNQOcDhJr0YS6+pB0Mk/+WZEBg4mDFckQ+kgNrLTXgp2r1QMz jH/sharmAPDUJQfU+BbD34f0X1XgMQRCjIsSdapxOnTRaaOmrUQWyU9s0jgS4w// yktqNdUNn4vLsz3ROuXWZU7Ju0nkhbMbHb4PwA/vH+tIryt3AeJNTUTMbhTbQuhP KoE1gMuPhk/rXZQ8wM5fseqC+Z50jZZ54o7OtQoGk3Ol09aiBpCfB7EP9IJXGGFl +2PqoIAf3bNDkej6nyCEK21weDB7uiiwVBtx/EWV4oLgb2tdDjB1o0A/nsh5Oe0E /OCBZI7JtmO3CY7WhZ/7AyHs/2TFVXReIjywHHcpwx9wQpkoqBXuIWkHjfFuKKab p6nXrUpDMojvyRk5Cw09+/XZmrE9wFqley/HPnLnciygtyeEXrq07neZaZY9ZtQX ZUuumrwfpsk8kRXJETDy5KuK8os83MKoohGSRKONTPxs1fVJNT2h/FD47RDNjXDq M5yepQ3SsPg= =Iitj -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Mon, 2005-05-02 at 20:58 -0400, Alec Warner wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Jackson wrote: Michael Haubenwallner wrote: Hi ebuild devs, Here's a glep draft now for (a part of) the long-term portage-goal act as a secondary package manager ... Comments welcome, haubi It's fancy, but what about ROOT? You don't like it just because you'd have /usr/local/usr/bin/foo? ROOT doens't work for DEPENDS, only [R,P]DEPENDS which means I can't install everything for pkg FOO in ROOT=/opt fex. Mostly useful for alt arches when /usr is taken by the primary OS and you need portage's DEPEND packages to go somewhere else. Well, I've got a bug open to have a different variable like ROOT that portage would read config files from. Maybe you could jump on that bandwagon, and see if you can make things work that way. I just don't see the uptake to fix a very large portion of the tree for something that I'd guess most devs think is pointless. That's also the reason the enterprise tree hasn't taken off. People working in their free time couldn't give a crap about people thinking Gentoo isn't suitable for enterprise applications. In fact, I'd bet there are even some people that already do or would sabotage such an effort. If you want to use portage, use Gentoo. If you want some package manager for your solaris/x86 box(just an example!), go talk to the people that do openembedded. They are geared toward using it as a secondary package manager on a system. --Iggy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new glep draft: Portage as a secondary package manager
On Mon, May 02, 2005 at 09:11:03PM -0500, Brian Jackson wrote: Well, I've got a bug open to have a different variable like ROOT that portage would read config files from. Maybe you could jump on that bandwagon, and see if you can make things work that way. Assuming you're referencing CONFIG_ROOT, it frankly isn't much of a solution for his needs. The problem with CONFIG_ROOT is you would have to set it for every emerge invocation. His intention is to have portage function from a variable prefix, and install to a build time defined prefix. IOW, portage using different paths on an installed box, not portage installed to it's normal location, and hacked up via an environment variable to try and change the behaviour. I'm not much for config_root, obviously. The intention of it, and varying root (imo) is a hack around portage's expectations about it's configuration and repos. It's not much of a proper solution. I just don't see the uptake to fix a very large portion of the tree for something that I'd guess most devs think is pointless. Aparently people didn't notice the multilib changes passing through the tree the last few months? Same type of wide spread change, yet it's being done, and ebuilds are being migrated. Things break, but the party/person interested in adding the support is doing the work. Sidenote re: fixing a large portion of the tree, eclasses and portage's base template for ebuilds would be the first start in terms of changes. That 'very large' portion of the tree arguement would be ixnayed via that, what would remain is a collection of pissy packages that need manual tweaking. That's also the reason the enterprise tree hasn't taken off. People working in their free time couldn't give a crap about people thinking Gentoo isn't suitable for enterprise applications. The reason for the enterprise tree not being ready/finished, or even *accepted* (it _still_ is a draft after all) is frankly no ones fault but those who want such a tree. The reason glep25 (my own glep) isn't implemented is again, no ones fault but those pushing it (read: me). Might want to clarify what you're asserting, cause I'm not seeing the validity in it... So... yeah, the enterprise angle imo is slightly daft. If you're arguing that their are more 'important' things to do rather then this, state it as such, or please clarify... If you want to use portage, use Gentoo. That should be or put in the grunt work to support it. If I recall correctly, you're working on gentoo embedded. The arguements you're leveling above could just as easily be used against expanding the tree to support uclibc, or a slightly saner example, dropping osx support (portage _is_ the secondary manager there). Hell, y'all are in a similar boat, for actual device updating you'll be using emerge.c, which _isn't_ portage, just compatible with the binpkg support. Either way, my point is that portage/gentoo will flow into the niche's people care to expand it into. It's pointless telling them not to do it, because they _will_ do it anyways if it makes sense to them. So point out the failings, or better solutions. Yeah, time for me to step down from the soapbox I think... If you want some package manager for your solaris/x86 box(just an example!), go talk to the people that do openembedded. Clarify why portage, which _does_ function as a secondary pkg manager (collision-protect wouldn't exist otherwise) wouldn't suffice if someone gave enough of a damn to do the work? So yeah, anyone care to comment about the proposal's specifics, rather then piss off, no... ? :) ~brian pgpk97ief0kMp.pgp Description: PGP signature
