[gentoo-dev] Last Rites: app-vim/conky-syntax
# David Shakaryan [EMAIL PROTECTED] (22 Apr 2008) # Masked for removal in 30 days. (bug #208878) # Dropping conky-syntax in favour of upstream syntax script. # Please enable the vim-syntax flag for conky instead. app-vim/conky-syntax -- David Shakaryan -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Sat, 19 Apr 2008 00:43:08 -0700 Chris Gianelloni [EMAIL PROTECTED] wrote: I would agree that RDEPEND should likely be installed prior to pkg_preinst to satisfy the dependency. After all, PDEPEND is good enough for doing packages that aren't required at pkg_preinst/pkg_postinst. It's likely to, but not guaranteed to be. We definitely don't want to install DEPEND at the pkg_* stages, so I'd say the requirement there, if you're asking, is prior to src_*, if that matters. If the alternatives are not being able to install from a binary at all due to circular dependencies, or being able to install from a binary using DEPEND to satisfy circular dependencies, which would you take? I'd love to have some kind of functionality to allow some kind of optional dependencies. The only real way that I could see this working is if we tracked what was installed as an optional dependency, and not reinstall it if it has been removed the next time the depending package is merged. Sort of like what kdebuild has for suggested dependencies, but less strong? -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] retirement
Hi folks, I've decided to retire as a Gentoo dev. I've been a dev for almost exactly 3 years as part of the Haskell team. I was team leader for a year or so. I managed to recruit kolmodin a couple years ago and handed team leadership over to him a few months ago. It's now his turn to recruit some more people to keep the Haskell team well staffed. My decision is based on real world time commitments. I'm in the late stages of writing up my PhD thesis and I've recently started a Haskell consultancy company shameless-plug href=www.well-typed.com/. I don't intend to do much less work packaging but I intend to shift my focus from Gentoo packaging to the central Haskell packaging infrastructure http://hackage.haskell.org/. All QA improvements there benefit Gentoo. I'll still have commit access to the haskell overlay and to the hackport tool for automatically converting packages hackage-portage. I'll still be in #gentoo-haskell if you want to find me. I'd like to thank everyone for being welcoming and friendly and answering my stupid questions. Thanks especially to the arch teams for all the time they put in for us in testing and stabilising Haskell packages on such a wide range of platforms. I feel I should also apologise to jer for constantly breaking ghc on hppa ;-). Thanks also to jakub for his work filtering and redirecting bugs to us, along with the occasional helpful insight. Best of luck everyone. -- Duncan Coutts : (ex-)Gentoo Developer (Haskell team) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] retirement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hiya Duncs, Sorry to hear your time constraints have gotten the better of you finally. Best of luck with well-typed, I hope it proves interesting and that you bring much Haskelly joy to the world... 5;) Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkgNxccACgkQu7rWomwgFXpiQgCgnQuYSH3lwN8UkPfJy+DQaFwW 57MAn2yeN2Ck4jC3OgIoGngg2eMW9aKL =umiM -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] lastrite: sys-apps/systrace (security/treecleaners)
Mon, 21 Apr 2008 22:34:30 +0200 Santiago M. Mola [EMAIL PROTECTED] kirjoitti: On Mon, Apr 21, 2008 at 9:01 PM, Samuli Suominen [EMAIL PROTECTED] wrote: # Samuli Suominen [EMAIL PROTECTED] (21 Apr 2008) # Masked for removal in 30 days. Doesn't build # wrt bug 178036 and has open CVE-2007-4773 wrt # security bug 203195. sys-apps/systrace -- gentoo-dev@lists.gentoo.org mailing list http://www.citi.umich.edu/u/provos/systrace/systrace-1.6e.tar.gz 1.6e solves the security problem. Just in case someone wants to fix it. It fails the same way the current ebuilds in tree. It was the first thing I've tried, obviosly. Besides, that's what lastrites are for, heads up. - drac -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Last rites: profiles/hppa/2006.1
All, As per discussions with Guy Martin (gmsoft), the hppa/2006.1 profile has been marked as deprecated and will be removed in 30 days time. -- Doug Goldstein Gentoo Linux -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] retirement
On Tue, 22 Apr 2008 11:22:14 +0100 Duncan Coutts [EMAIL PROTECTED] wrote: Thanks especially to the arch teams for all the time they put in for us in testing and stabilising Haskell packages on such a wide range of platforms. I feel I should also apologise to jer for constantly breaking ghc on hppa ;-). That's OK. I like to think we were having fun. :) Kind regards, JeR -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
On Tue, 2008-04-22 at 08:09 +0100, Ciaran McCreesh wrote: We definitely don't want to install DEPEND at the pkg_* stages, so I'd say the requirement there, if you're asking, is prior to src_*, if that matters. If the alternatives are not being able to install from a binary at all due to circular dependencies, or being able to install from a binary using DEPEND to satisfy circular dependencies, which would you take? Given the trouble that we have every release with trying to cram everything our users want into a limited space, I'd rather the damned thing not install than pull in a bunch of packages we don't need, just to satisfy a dependency that isn't even used during execution of the package. I'd love to have some kind of functionality to allow some kind of optional dependencies. The only real way that I could see this working is if we tracked what was installed as an optional dependency, and not reinstall it if it has been removed the next time the depending package is merged. Sort of like what kdebuild has for suggested dependencies, but less strong? Pretty much, yeah. The main difference that I would see from the current *DEPEND variables, besides what was said above, would be that a lack of visibility wouldn't stop the package merge. If sys-apps/foo had ODEPEND=dev-libs/bar and dev-libs/bar was masked, it simply wouldn't be installed. -- Chris Gianelloni Release Engineering Strategic Lead Games Developer -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
Ciaran McCreesh wrote:
On Sat, 19 Apr 2008 18:38:06 +0200
Marijn Schouten (hkBst) [EMAIL PROTECTED] wrote:
Every package dependency in DEPEND is installed and usable before
src_unpack starts, right? So is the question here whether or not they
can be uninstalled right before pkg_{pre,post}inst starts?
If we're using binaries, DEPEND is usually ignored.
But if we're using binaries then src_unpack isn't called so this is a
moot statement and the O.P.'s statement is correct.
I don't know what the general use of pkg_preinst is, but in
pkg_postinst the package itself should be runnable, so its RDEPENDS
should be installed and usable at this point. So perhaps we should
define that usable means each of its RDEPENDs is installed and has
had its pkg_postinst function run. The recursion of that definition
then comes from the requirement that RDEPENDs should be usable before
pkg_postinst starts running.
No good. That prevents RDEPEND - RDEPEND cycles from being solved,
and the package manager has to be able to solve that.
Can you give a concrete example? Not a foo and bar or a and b example.
But a real package example. Because there are a few packages in the tree
which call themselves in pkg_postinst
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Dependencies that're available at pkg_*inst
Ciaran McCreesh wrote: On Fri, 18 Apr 2008 21:45:13 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: I'd go with RDEPEND only. Any other interpretation results in installing build-time-only packages along with a binpkg, which doesn't seem to make sense. That's definitely not what we want. Only a package's DEPENDs have to be installed and usable when that package is built. Its RDEPENDs don't have to be installed until that package is treated as usable. For why this matters: cat/a-1: RDEPEND cat/b cat/b-1: RDEPEND cat/a This is solvable. If package managers can't solve this, they can't install Gnome off a stage 3... I think Donnie (and I) are both looking for concrete examples here. You're claiming GNOME can't be installed so please give us an example with in-tree packages where this breaks. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Re: Re: Re: New global USE flag: keyring
Jeroen Roovers wrote: On Mon, 21 Apr 2008 15:02:29 +0100 Steve Long [EMAIL PROTECTED] wrote: Sorry to get technical but how difficult is it really to change USE flag names? I appreciate that users are out of sync yadda yadda, but could this kind of thing not be considered out of band data similar to news? I accept that portage has to maintain compatibility but aiui the old way of doing this was simply depending on a version of portage that had the capability. Since we're only talking about ~10 packages, is that so much of a hardship? After all, I'm sure the other manglers don't lag behind emerge, based on the hyperbole. Do they? I'm deeply sorry. I read all of that three times and while it seemed to make sense the first time, by the third time I saw the error of my ways. You've lost me; if I've caused you offence somehow please accept my apology and mail me off-list to tell me how. Regards, Steve. -- gentoo-dev@lists.gentoo.org mailing list
