Re: [gentoo-dev] problems crosscompiling libXt
On Saturday 17 December 2005 18:20, David Thomas wrote: > Here is a fix for libXt, similar to the problems I had with libX11 > last week. I don't see an obvious way to patch the Makefile.am. > Please send comments. you should startup a bug for this if one hasnt been already -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: disallowing multiple votes per person in council meetings
On Thursday 15 December 2005 15:20, Ciaran McCreesh wrote: > one of the following two clauses: > > Each person at a council meeting may represent only one voting role. > > Or: > > A proxy must not be an existing council member, and any single person > > may not be a proxy for more than one person at any given meeting. i'm for the latter version > * It makes it harder for council members to all go "oops, can't make > it, so vapier is my proxy" at the last minute. well, i could proxy for three of them and SpanKY could proxy for the other three ... i bet we'd put on a good show > On the same subject, I'd also like to see the "meeting participants" > table updated to explicitly list proxies, for example in the form > "jaervosz (for koon)". i pointed out that we were already going to do this and it was done earlier this weekend ... however, i did "koon (proxied by jaervosz)" ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] glep 42 (news) round six
On Sun, Dec 18, 2005 at 04:52:23PM +, Ciaran McCreesh wrote: > On Sat, 17 Dec 2005 23:27:32 -0800 Brian Harring <[EMAIL PROTECTED]> > wrote: > | To head off the "don't make features that are easily screwed up", > | this isn't one of them- this is expecting code to behave correctly > | from the path standpoint. > > Hrm, so will we be allowing spaces in package and category names too? No, due to atoms in *depend being seperated by whitespace. Wouldn't work without introducing escaping into it- beyond that the cat/pkg standard is in place already. Your repo_id however, is not, thus it's mallable. It's irrevelant either way- as I stated, your code *needs to be* space safe. Existing repo label'ing code in saviour _already_ allows spaces (it's just a fricking name), dissallowing spaces due to a concern that someone might screw up is daft. So... don't point at other things that are already set in stone and disallow spaces for their own reasons; state why it must be disallowed here, or merely state "I hate spaces". Like I said a couple of emails back, block spaces in repo_id if you like, either way the code involved has to be space safe for paths, so it's an arbitrary restriction... Dunno. Either way, path handling *must* be space safe anyways- if you restrict repo_id to lack spaces, your choice, still going to allow external aliasing of the repo_id to have spaces. > | > I don't want to introduce any signing requirements that we don't > | > have already. When signing for everything else becomes mandatory, > | > signing for news would be too. If I make this a 'must', someone > | > will ask me to specify how we're handling the Gentoo keyring... > | > | Pawn the keyring off on others. The issues isn't an established > | trust ring, it's required signing- yes, a trust ring makes things a > | helluva lot easier on the user front, but it's useless without a > | required signing policy. > | > | We've already had this conversation also btw, in the > | beginning of glep42 iirc. Obviously I don't agree > | with your reasoning "I'll do it when it's required I do it". It's > | useful now, it becomes massively more useful when a trust ring is > | available. > > Ok, how about I change it to "must", and add a note under Backwards > Compatibility along the lines of: > > At the time of writing, there is no standardised mechanism for handling > GPG signatures in Gentoo. Until such a mechanism exists, GPG signing > cannot be considered mandatory. And provisions for going back and signing everything that was _not_ signed while you delaying waiting for a keyring? That's why I'm pushing it. Mandate it as required now, keyring down the line just makes it more useful. Make it 'suggested' (which this is, you've changed nothing but words), you've left a mess that needs to be addressed when keyring comes about. Same scenario as before, think forward- force it from the get go, less crap to deal with down the line. Mandate it, no mess- just the pre-existing problem of getting a keyring collected. Delay it, keyring + going back and trying to get folk to re-sign their releases. That and any unsigned material released during that period cannot be verified, because we're waiting for a keyring. See the gains? Might be unpalatable, but it is the path of least work long term. > Ok, how's this? > > ``Revision:`` > Initially 1. Should be incremented every time a change is made to > the news item. Changes that require a re-read of the news item (for > example, most changes that are not spelling or formatting related) > should instead use a new news item. Mandatory. Works, thank you. > | > | This isn't incredibly useful if ranged versions are ever > | > | introduced. Ammending the glep for that seems stupid, looser > | > | language might be wise. > | > > | > What's the syntax for ranged versions? And how do they differ from > | > SLOT versions? > | > | >=kde-base/kde-libs-3.0 <=kde-base/kde-libs-4.0 > | > | It's not syntax as much as a boolean and of atoms. > > Hrm, ok. Wouldn't this resolve as true if you have kde-libs-2.0 and > kde-libs-5.0 installed (assuming SLOTted kde-libs)? Note I said boolean and. Resolution of that string *should* result in 3-4 via portage processing of it; doesn't handle it perfectly, but the reason I brought it up is that via limiting it to a single atom, you block (if/when) ranged versions. > | Any signed item would need to be verified also, although fortunately > | this chunk can be done in parallel to regen run. > > Hrm, is signing verification done for tree items? *If* a component was fully signed, verification prior to dissemination should occur. Reliant on a keyring to automate it however, plus some voodoo to make as much as possible go in parallel (so as not to overrun the window). > | > | You haven't stated how the 'package manager' will trigger the > | > | user's reader of choice for these targets. Should also extend > | > | this
[gentoo-dev] Last rites for kde-base/kmobile
I've masked kde-base/kmobile pending removal, for a series of reasons: - it's not built by default - it's not useful, because it's incomplete - it's even broken on 3.5 and required patching to build, so the 3.5.0 never appeared - it's still unstable creating up&down problems to people having it installed You can see at https://bugs.gentoo.org/show_bug.cgi?id=115980 a summary report. The dependency from kdepim-meta was already dropped time ago, so it's not even a problem from that side. If nobody has reasons to let it still leave, I'll drop it entirely in a week. -- Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpdLwFrv4ldI.pgp Description: PGP signature
Re: [gentoo-dev] glep 42 (news) round six
On Sun, 18 Dec 2005 12:18:16 +0200 Marius Mauch <[EMAIL PROTECTED]> wrote: | Another new issue nobody has mentioned yet: | The GLEP doesn't say anything about file permissions/ownership as in | who will/should be able to a) read news and b) modify the news-* | files. Without thinking too much about it I'd say a) users in portage | group and b) root. My prototype hack has the news files as 664, so even non-Portage-group users can read things -- they just can't update the news-*.read files. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] glep 42 (news) round six
On Sat, 17 Dec 2005 23:27:32 -0800 Brian Harring <[EMAIL PROTECTED]> wrote: | To head off the "don't make features that are easily screwed up", | this isn't one of them- this is expecting code to behave correctly | from the path standpoint. Hrm, so will we be allowing spaces in package and category names too? | > I don't want to introduce any signing requirements that we don't | > have already. When signing for everything else becomes mandatory, | > signing for news would be too. If I make this a 'must', someone | > will ask me to specify how we're handling the Gentoo keyring... | | Pawn the keyring off on others. The issues isn't an established | trust ring, it's required signing- yes, a trust ring makes things a | helluva lot easier on the user front, but it's useless without a | required signing policy. | | We've already had this conversation also btw, in the | beginning of glep42 iirc. Obviously I don't agree | with your reasoning "I'll do it when it's required I do it". It's | useful now, it becomes massively more useful when a trust ring is | available. Ok, how about I change it to "must", and add a note under Backwards Compatibility along the lines of: At the time of writing, there is no standardised mechanism for handling GPG signatures in Gentoo. Until such a mechanism exists, GPG signing cannot be considered mandatory. | > | > ``Revision:`` | > | > Initially 1. Incremented every time a non-trivial change is | > | > made. Changes which require a re-read of the news item should | > | > instead use a new news item file. Mandatory. | > | | > | non-trivial changes that don't require a re-read sounds like a | > | contradiction. Clarify, especially since portage will mark this | > | as read _once_ and only once. | > | > Hrm, word it as "Changes other than minor formatting tweaks", or | > remove "non-trivial"? | | It's not a wording thing, I'm pointing out sans spelling corrections | and trivial word mangling, any new info jammed in requires a new item | bump so readers can display the changes. | | In light of that, wording above needs correction. Ok, how's this? ``Revision:`` Initially 1. Should be incremented every time a change is made to the news item. Changes that require a re-read of the news item (for example, most changes that are not spelling or formatting related) should instead use a new news item. Mandatory. | > | This isn't incredibly useful if ranged versions are ever | > | introduced. Ammending the glep for that seems stupid, looser | > | language might be wise. | > | > What's the syntax for ranged versions? And how do they differ from | > SLOT versions? | | >=kde-base/kde-libs-3.0 <=kde-base/kde-libs-4.0 | | It's not syntax as much as a boolean and of atoms. Hrm, ok. Wouldn't this resolve as true if you have kde-libs-2.0 and kde-libs-5.0 installed (assuming SLOTted kde-libs)? | > Once an hour would work fine. On the other hand, the merge is just | > copying a few small files -- time-wise, it's less than generating | > the cache for a couple of ebuilds. | | More then a couple; this beast will bloat up to hundred or so files | I'd expect (remember translation serves as a multiplier). Yup, but it's just a case of copying a few small text files. | Any signed item would need to be verified also, although fortunately | this chunk can be done in parallel to regen run. Hrm, is signing verification done for tree items? | > | You haven't stated how the 'package manager' will trigger the | > | user's reader of choice for these targets. Should also extend | > | this to allow a way to disable any news notices, lest someone's | > | cronjob get hung displaying news (feature or not, it's needed). | > | > The same way the package manager handles updating config files: it | > won't. It'll just tell the user that some news items need reading. | | And you'll personally handle all of the bug spam from feature | requests that --ask trigger $news_reader? | | It's a logical extension, thus people will ask for it. What does emerge --ask do currently for config files? | We expire updates? If so, someone might want to look at the updates | from 3 years back... Yes. Once a year, Seemant shows up and says "hey, does anyone ever expire really really old updates entries?". | > | > There is an existing automated tool [#forums-glsa]_ for posting | > | > GLSAs to the forums. A similar tool can be used for these news | > | > items. | > | | > | Pawned it off on someone, or something you'll be doing? | > | > Hopefully the former. I have it on reasonably good authority that it | > won't take more than half an hour if I end up having to do it | > though... | | Get cracking then (regardless if it's pawning or coding). Eh, that one can be left until the last minute. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] glep 42 (news) round six
On Sun, 2005-12-18 at 09:57 -0500, Philip Webb wrote: > > You are encouraged to reply to this thread > > saying "I agree with ciaranm > > that repository IDs should not be allowed to contain spaces". > > No problem at all there (smile): spaces in names are A Bad Thing for Unix, > as they conflict with the basic format of the command-line > & were introduced by M$ (Mac ?) to make things easier for idiots. So you're saying long filenames were invented by Microsoft for Windows 95? ;-) As long as programmers don't assume that filenames won't have spaces I don't see the problem > The proper procedure for Unix-type systems is to use an underline symbol. Which "standard" says that, and how silly is that? We're past the 80s, there's no reason to limit filenames to alphanumeric (as I think with the same reasoning you'd forbid unicode ...) > > Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) > Does your brain really contain that many viruses ... ? Only because it runs Windows ;-) -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] glep 42 (news) round six
051218 Ciaran McCreesh wrote: > * Change to -mm-dd for GLEP 45 compatibility. Good to see Gentoo adopting correct international date format. > You are encouraged to reply to this thread > saying "I agree with ciaranm > that repository IDs should not be allowed to contain spaces". No problem at all there (smile): spaces in names are A Bad Thing for Unix, as they conflict with the basic format of the command-line & were introduced by M$ (Mac ?) to make things easier for idiots. The proper procedure for Unix-type systems is to use an underline symbol. > Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Does your brain really contain that many viruses ... ? -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: glep 42 (news) round six
John Myers posted <[EMAIL PROTECTED]>, excerpted below, on Sat, 17 Dec 2005 21:18:57 -0800: > On Saturday 17 December 2005 20:57, Ciaran McCreesh wrote: >> On Sat, 17 Dec 2005 20:50:43 -0800 John Myers >> >> <[EMAIL PROTECTED]> wrote: >> | GLEP 42 wrote: >> | > * Before an ``emerge --ask `` sequence >> | >> | What, exactly, does this mean? I'm guessing it means between the >> | package list and the prompt, but it's not quite clear. >> >> I dunno, I refuse to use emerge --ask for religious reasons. Feel free >> to rewrite that bullet point. >> > How about > > * During ``emerge --ask``, the same as for ``emerge --pretend`` (i.e. > after the package list) > > ? I had mentioned this earlier. +1 -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Multiple Repo Support
Zac Medico posted <[EMAIL PROTECTED]>, excerpted below, on Sat, 17 Dec 2005 13:16:04 -0800: > Off hand, perhaps portageq could provide a query that > returns some type of UUID for a package, such as a hash of the ebuild. > That way, the hash from /var/db/pkg could be compared to the hash from the > repo that has the news item. If the hashes don't match, then the news > item is irrelevant. Ebuild hashes certainly would /not/ work, because existing ebuilds are routinely changed (thereby changing the hash) after initial appearance in the tree, while keeping the same ebuild -rX number (thus, the same filename, the same ebuild). Policy (as understood here, noting that I'm not a dev) is that the revision can remain the same if it's not something that's going to majorly effect users who have already merged the existing version. Thus, for example, changes to the ebuild that only fix bugs that kept it from building on specific system configurations don't warrant a revision bump, because that doesn't affect those who /were/ able to merge it. Creating a revision bump in that case simply forces them to do more unnecessary updating (assuming they keep reasonably updated in the first place). Of course, a security revision or patch that adds functionality for existing users, should normally get a -rX bump, while upstream bumps of course correspond to bumps as well. Brian's comment that news should be repository specific makes the most sense to me, thereby eliminating the need for ebuild UUIDs for the purposes of news, anyway. However, were they to be needed, they would almost certainly be implemented as yet another variable in the ebuild, as that would at once separate ebuild changes from UUID changes, and be relatively simple to implement, given the number of other variables already parsed. -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Maintainer's guides?
On 11/30/05, Diego 'Flameeyes' Pettenò <[EMAIL PROTECTED]> wrote: > On Monday 28 November 2005 21:01, Curtis Napier wrote: > > A seperate tag like , as > > someone mentioned earlier, would also be a huge help but would still > > give you the homepage info as well. > Seems like we are all ok for the tag in metadata then... should this > require a GLEP or it's a simple change? Who can take care of that? Paul? When will this tag be added to dtd? -- Bi Cờ Lao -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] glep 42 (news) round six
On Sun, Dec 18, 2005 at 12:18:16PM +0200, Marius Mauch wrote: > Brian Harring wrote: > >On Sun, Dec 18, 2005 at 06:23:55AM +, Ciaran McCreesh wrote: > > > >>On Sat, 17 Dec 2005 21:50:47 -0800 Brian Harring <[EMAIL PROTECTED]> > >>| You haven't stated how the 'package manager' will trigger the user's > >>| reader of choice for these targets. Should also extend this to allow > >>| a way to disable any news notices, lest someone's cronjob get hung > >>| displaying news (feature or not, it's needed). > >> > >>The same way the package manager handles updating config files: it > >>won't. It'll just tell the user that some news items need reading. > > > > > >And you'll personally handle all of the bug spam from feature requests > >that --ask trigger $news_reader? > > > >It's a logical extension, thus people will ask for it. > > I don't think so. > How many people have asked for etc-update integration? etc-update style notices are at exit of emerge. This proposal has news item warnings prior to the merge actually occuring (no specification of sleep however). Different scenario, thus etc-update isn't a good indicator. > To quote myself: > "Granted race conditions might be an issue (where the solution > complicates tools), but that's so minor I wouldn't really care about > it." > That I wouldn't care about it isn't a general recommendation to ignore > the issue. Yes, for a perfect solution it is required, but do we aim for > a perfect solution? We do if it potentially allows for 'critical' news to be unseen, at least imo. > Another new issue nobody has mentioned yet: > The GLEP doesn't say anything about file permissions/ownership as in who > will/should be able to a) read news and b) modify the news-* files. > Without thinking too much about it I'd say a) users in portage group and > b) root. *cough* good point. ;) ~harring pgpacHFQeelTO.pgp Description: PGP signature
Re: [gentoo-dev] glep 42 (news) round six
Brian Harring wrote: On Sun, Dec 18, 2005 at 06:23:55AM +, Ciaran McCreesh wrote: On Sat, 17 Dec 2005 21:50:47 -0800 Brian Harring <[EMAIL PROTECTED]> | You haven't stated how the 'package manager' will trigger the user's | reader of choice for these targets. Should also extend this to allow | a way to disable any news notices, lest someone's cronjob get hung | displaying news (feature or not, it's needed). The same way the package manager handles updating config files: it won't. It'll just tell the user that some news items need reading. And you'll personally handle all of the bug spam from feature requests that --ask trigger $news_reader? It's a logical extension, thus people will ask for it. I don't think so. How many people have asked for etc-update integration? | implementation issue; you need locking on this. If portage has to | farm out to the users reader of choice, then it needs to lock the | file to keep readers/writers from screwing with each other. We do? Marius told me it wasn't worth it. I disagree. It's mainly contingent upon $news_reader being spawned via --ask, although it *also* matters heavily if the user is flipping through their news while a sync in the background is running- if the utility updates on the way out, unless their is some advisorial locking involved, you've just lost all of the new synced unread news. To quote myself: "Granted race conditions might be an issue (where the solution complicates tools), but that's so minor I wouldn't really care about it." That I wouldn't care about it isn't a general recommendation to ignore the issue. Yes, for a perfect solution it is required, but do we aim for a perfect solution? | > News items can be removed (by removing the news file from the main | > tree) when they are no longer relevant, if they are made obsolete | > by a future news item or after a long period of time. This is the | > same as the method used for ``updates`` entries. | | implementation issue; updating unread/skip crap so it doesn't bloat | is required, but time frame also matters (crap sync resulting in news | getting removed, yet it still being valid, just missing from the | local tree). Hrm. We can't take the same approach here as we do with expiring updates entries? We expire updates? If so, someone might want to look at the updates from 3 years back... Yeah, mainly me dropping old files sometimes (happened two times so far IIRC), so not a general policy documented anywhere (just doing it when I get annoyed by portage re-applying ancient entries). Another new issue nobody has mentioned yet: The GLEP doesn't say anything about file permissions/ownership as in who will/should be able to a) read news and b) modify the news-* files. Without thinking too much about it I'd say a) users in portage group and b) root. Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] last rites for net-im/sim
On Saturday 17 December 2005 20:54, Carsten Lohrke wrote: > When you are interested in sim and willing to fix all bugs¹ and takeover > maintainership) speak now. Christmas morning I'll crucify it. > > > Carsten > > > [1] https://bugs.gentoo.org/show_bug.cgi?id=110241 For moving over to the forked sim on berlios (http://sim-im.berlios.de/wiki/Main_Page), is it better to keep sim masked in portage and then continue with the forked releases once they come up, or just restart from zero? >From user point of view I guess the continuity option may be better... Bruno -- gentoo-dev@gentoo.org mailing list
