[gentoo-dev] Re: base packages up for grabs
Mike Frysinger wrote: > working here is no longer fun * HUGZ * -- where to now? if i had to guess dirtyepic gentoo orgi'm afraid to say antarctica's next 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [gentoo-core] Tears of unfathomable sorrow
Alec Warner wrote: > Much to the joy of many I am now retiring from Gentoo. I've already done > most of the work (sorry to burden you kloeri I think just the tree-bits > are left). > > Many will wonder why; but this has been a while in coming. I don't get > along with many like I used to and in many cases I don't find myself > agreeing with the direction of things. Those who know me know I always > bitched about how I didn't do enough for Gentoo and that too is a reason > for leaving. > > I expect to still file patches for portage and I expect to hang out in > gentoo-dev-help on irc and I expect to mentor for this years summer of > code. > > For TreeCleaners I'm sorry that this is out of the blue; I hope you guys > continue to nuke broken crap from the tree. > > For everyone who still loves working in their little window in gentoo, for > all the devs that only read core and not -dev, for all the devs who made > gentoo what it was when I started; thanks. It was a fun ride. > > -Alec > NO :...( -- where to now? if i had to guess dirtyepic gentoo orgi'm afraid to say antarctica's next 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: *DEVELOPMENT* mail list, right?
Michael Cummings wrote: > So, fellow devs, what's new with development? For those interested, genlop has > migrated into gentoo as a project with the permission of upstream, which no > longer maintain it. Um...any new tools or projects people are working on? I just finished overhauling our wxWidgets support. I managed to replicate the old broken wxwidgets.eclass behaviour for the time being so we won't have to do a painful drawn-out transition. This weekend I have to test that it doesn't break anything already in the tree. Then I'll run it by leio and see what the wxWidgets developer community thinks about it. We also have to drop kick wxGTK-2.4 from of the tree already. Anyone maintaining packages that use wxGTK or wxpython, _please_ make sure you're using versions 2.6. I'm also tinkering with the newly released pcsx2-0.9.3 because i would love to play FFXII on the road. -- where to now? if i had to guess dirtyepic gentoo orgi'm afraid to say antarctica's next 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: /lib/rcscripts or /$(get_libdir)/rcscripts?
Mike Frysinger wrote: > perhaps we should write a new func ... `dorcaddon` ... That immediately looks like "dork addon" to me. --dirtypics -- where to now? if i had to guess dirtyepic gentoo orgi'm afraid to say antarctica's next 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [last rites] virtual/x11
Ryan Hill wrote: > Michael Sterrett -Mr. Bones.- wrote: >> I commented this out of package.mask. x11-libs/fox-1.2.6-r2 still uses it. >> Need to fix that up before masking it. > I'll have a look. Okay, x11-libs/fox-1.2.6-r3 was added to the tree which fixed the virtual/x11 and GCC 4.1 compile issues. It was marked stable on all archs except alpha. Someone doing some cleanup accidentally removed it from the tree instead of the broken -r2. We could restore -r3, but considering nothing in the tree depends on 1.2.6 and the number of months gone by without anyone even noticing -r2 doesn't build, I think it might be better to just remove it along with virtual/x11. fox fell into treecleaner territory until recently but it looks like mabi has taken over as maintainer, so it's up to him. ;) -- where to now? if i had to guess dirtyepic gentoo orgi'm afraid to say antarctica's next 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [last rites] virtual/x11
Ciaran McCreesh wrote: > Well, if it's reached the "take drastic action" stage (which, let's > face it, it has at this point), why not go and fix the tree? It's a > better solution than breaking it, and anyone who moans now isn't going > to get any sympathy from anyone. I'm fixing it now. The breakage wasn't intentional since it looks like this issue was known and fixed and later regressed. -- where to now? if i had to guess dirtyepic gentoo orgi'm afraid to say antarctica's next 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [last rites] virtual/x11
Michael Sterrett -Mr. Bones.- wrote: > I commented this out of package.mask. x11-libs/fox-1.2.6-r2 still uses it. > Need to fix that up before masking it. It doesn't seem to build. FXColorSelector.cpp: In member function 'long int FX::FXColorSelector::onUpdAlphaText(FX::FXObject*, FX::FXSelector, void*)': FXColorSelector.cpp:446: error: 'FXStringVal' was not declared in this scope FXColorSelector.cpp: In member function 'long int FX::FXColorSelector::onUpdRGBText(FX::FXObject*, FX::FXSelector, void*)': FXColorSelector.cpp:551: error: 'FXStringVal' was not declared in this scope FXColorSelector.cpp: In member function 'long int FX::FXColorSelector::onUpdHSVText(FX::FXObject*, FX::FXSelector, void*)': FXColorSelector.cpp:597: error: 'FXStringVal' was not declared in this scope FXColorSelector.cpp: In member function 'long int FX::FXColorSelector::onUpdCMYText(FX::FXObject*, FX::FXSelector, void*)': FXColorSelector.cpp:642: error: 'FXStringVal' was not declared in this scope I'll have a look. -- where to now? if i had to guess dirtyepic gentoo orgi'm afraid to say antarctica's next 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Suggestion: INVALID -> NOCHANGE in bugzilla
Marius Mauch wrote: > "Kevin F. Quinn" <[EMAIL PROTECTED]> wrote: > >> Arguably no bug is invalid in the normal sense - if someone raises an >> issue, they have an issue, regardless what we think of it. To that >> end I'd like to propose bugzilla be reconfigured to use the phrase >> "NOCHANGE" instead of "INVALID". NOCHANGE would indicate that >> whatever the original issue, no change is needed on our part to >> resolve the issue. > > _If_ it's changed then please to something else, NOCHANGE would overlap > with other values (WONTFIX, CANTFIX, WORKSFORME) and isn't that obvious > to me at least. A fake resolution that's mentioned on IRC from time to > time is NOTABUG which would fit better here. I like freedesktop.org's bugzilla, which has INVALID, NOTABUG and NOTOURBUG. ;) But yeah, NOTABUG is used by a few different projects and seems to work. -- where to now? if i had to guess dirtyepic gentoo orgi'm afraid to say antarctica's next 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Something positive! (was Re: Client-serve flags (again ;))
> The people who get all bent out of shape about a simple joke like that > are either homosexual themselves (not a bad thing) or homophobes > (definitely a bad thing). Not only is this completely off-topic for a technical ml, but one of the most shockingly stupid things one could say in an international public forum. This would get you fired on the spot from any job. Please keep in mind you representing Gentoo here and keep your personal views on political issues to yourself. I'm speaking to everyone here. We have enough trouble getting along without this kind of shit. -- where to now? if i had to guess, dirtyepic gentoo org i'm afraid to say antarctica's next. 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Some council topics for March meeting
Ciaran McCreesh wrote: > I was kicked for suggesting that a) ppc-macos was breaking the tree, > staffed by people who don't know what they're doing, a QA nightmare and > damaging to the project, b) that pathspec was vapourware and > conceptually completely broken, c) that the forums were encouraging > ricing by letting users discuss insane kernel patchsets and absurd > CFLAGS in the main fora, and d) that Portage development has by and > large stagnated and that Portage can't deliver the things people > require. I like to think you were kicked for incessantly trolling, repeatedly insulting developers and users, turning every other thread on -dev into a 150 post flamefest, and generally creating a working environment that no one wanted to be a part of. Obviously none of this has changed. -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: What do you think about removing gtk-1.2 theme engines from tree?
Andrej Kacian wrote: > It makes sense slowly removing *applications* depending on gtk1. Themes should > go last, along with gtk1 itself. > > Gtk1 is already ugly enough, do you want it to be even more ugly? Point, set, and match. -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: What do you think about removing gtk-1.2 theme engines from tree?
Samuli Suominen wrote: > What do YOU think about removing these from tree? *I* think it's a great idea, but *I* may be heavily medicated at the moment. Seriously, IMHO the less we have depending on GTK+-1 the better. Others will disagree loudly. > Related picture, > http://www.acc.umu.se/~zqad/cats/?view=1163919784-cat-detonator.jpg Oh noes! -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [RFC] custom-cflags global USE
Carsten Lohrke wrote: > And I'd be fond of having all the -ffast-math filtering ripped out of the > tree > as well. Please include -ftree-vectorize and -ftree-loop-linear along with that. I've yet to see a GCC release where they work correctly, including 4.2. -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: let's clear things up (was Slacker archs)
Steve Long wrote: > Stephen P. Becker wrote: >> All of that said, how about we clear up all of the misinformation about >> how arch keywording really works, how deps get wrongly dropped, and then >> explain why mips has generally fallen behind. This isn't an excuse, >> but is merely a statement of facts which describe the situation. >> > Thanks for the clear explanation of the process; it helps to put this in > context for non-devs. Not only non-devs. Well done. -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Install locations for doc packages
Zac Medico wrote: > The DOC_SYMLINKS_DIR variable is intended to solve that problem (new > in portage-2.1.2). It is documented in `man make.conf`. Thanks, that's exactly what I was looking for. -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Install locations for doc packages
Hey guys.
There are a bunch of ebuilds (mostly in app-doc) that install stuff like
HOWTOs, guides, reference manuals, books published under Creative
Commons, etc. Currently the majority of these are installed into
/usr/share/doc/${PF}. The problem with this is every time one of these
packages gets a version bump it breaks any bookmarks or links one may
have made for quick handy-dandy access.
Should we:
- install into /usr/share/doc/${PF} and symlink to /usr/share/doc/${PN}
- install straight into /usr/share/doc/${PN}
- install into /usr/share/doc/${PF} and symlink to some universal
decided-on location (eg. /usr/docs/${PN}) just to keep stuff from
getting lost in the sea of /usr/share/doc
There's a bit of each in the tree right now, so i'd like to make it
consistent. I like the third option personally.
Also, anyone interested in an app-doc herd?
--
by design, by neglect
dirtyepic gentoo orgfor a fact or just for effect
9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8)
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: Automated Package Removal and Addition Tracker, for the week ending 2007-02-18 23h59 UTC
Robin H. Johnson wrote: > The attached list notes all of the packages that were added or removed > from the tree, for the week ending 2007-02-18 23h59 UTC. Y'know, before these started getting posted, i had the distinct impression the tree was getting lighter. :P -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Monthly Gentoo Council Reminder for February
Mike Frysinger wrote: > This is your monthly friendly reminder ! Same bat time (typically the > 2nd Thursday at 2000 UTC), same bat channel (#gentoo-council @ > irc.freenode.net) ! Reply-to and SPF docs? Isn't this the third month now? Also the infra doc on dev email still says not to use d.g.o as a relay server. I can't remember if this was first brought up in a council meeting or on core though. Just a friendly poke. ;) -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: new herd suggestion: religion
Steve Dibb wrote: > @devs, > > I'd like to propose a new herd: religion. The herd would take care of > the Bible and religious software along with any genealogy programs in > the tree, which there actually are a few of. Sword, gnomesword, sword > modules, bibletime, gramps would all fall under the responsibilty of the > herd. > > I talked to squinky86 who was previously maintaining most of these, and > since he is temporarily retiring I've assumed ownership of the packages > in his absence. A herd would of course let anyone else interested work > on them, and be recognized as joint maintainers as well. > > Any comments? Anything that makes it easier to identify and work on packages you're interested in seems okay to me. Maybe emacs, vim, kde, and gnome could be added. ;P -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Monthly Gentoo Council Reminder for February
Kevin F. Quinn wrote: >> It would but having some kind of deadline after which you are for >> example free to take over the package if you want to would be nice. > > That's going too far; there's certainly no need to take over a package > just to get a fix in. If you want to take over a package, asking the > current maintainer has to be the first step, not to quietly wait for a > timeout then just grab it. Similarly asking the current maintainer if > they mind you putting a fix in. That's of course a given. I think the question here relates to non-responsive maintainers or herds. I have been in the situation many many times with gcc-porting where I file a bug with a simple patch (say removing extra qualification) to get a package to build with GCC 4.1, and get no response for months from the maintainer despite multiple pings. In that case, i'll apply the fix myself. I always try to wait a month or more before going ahead and always ping at least once. So far i've not received any major complaints, but i'm just waiting for the day someone will get territorial about their packages and decide rip me a new one. It'd be nice to have some kind of asshole insurance. This also affects things like treecleaners. How long does a herd team or maintainer have to be unresponsive to warrant the package falling into maintainer-needed? Right now the most common way we find these packages is when Jakub gets annoyed enough with the accumulating bugs and lack of response to CC us. ;P I personally think that for bug fixes a month is a long enough wait to allow someone to respond. Keep in mind that's to respond, not to fix the bug. A simple "yep, i'll get to this later" is enough. -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: GPL-2 vs GPL-2+
Diego 'Flameeyes' Petten wrote: > What I propose is to copy licenses/GPL-2 to license/GPL-2+ and adding the > following notes at the start of the two files: > > GPL-2: > Note: this license states that the software is licensed under GNU General > Public License version 2, and you might not be able to consider it licensed > under any later version. > > GPL-2+: > Note: this license explicitly allows licensing under GNU General Public > License version 2 or, at your option, any later version. Was there ever a consensus on this? I think it's an important issue and am willing to help with an audit. -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [RFC] Ideas for projects...
sanchan wrote: > missing -fno-strict-aliasing wherever there are bad programming > practices and so on; IIUC, GCC's current -Wstrict-aliasing implementation has a number of flaws. According to a recent thread[i] on the GCC ml.. > The current implementation of -Wstrict-aliasing looks at a single expression > at once. Although it does OK given the limited scope, it has several > drawbacks. > First, it produces false positives, i.e., it warns when it should not. > For instance, it warns about pointer conversions even when the pointers > are never dereferenced. > Second, it has many false negatives, i.e., it does not warn when it should. > It does not warn when an address is not taken, for instance: > float *f = ... > int *i = (int*)f; > Third, it does not display the name or type of the aliased objects, which > makes the warnings hard to understand in templates or macros. Until that improves it might be a good idea to take strict aliasing warnings with a grain of salt. [i] http://permalink.gmane.org/gmane.comp.gcc.patches/131449 -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: New developer: Vic Fryzel (shellsage)
Christian Heim wrote: > Please welcome Vic as a new fellow developer among us ! Yay! Welcome to Gentoo. -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [RFC] Ideas for projects...
Chris Gianelloni wrote: > Submit your ideas here, so we can discuss them. I will be choosing one > idea that we think we can accomplish to test out the idea of > Council-driven projects. How far was Curtis from finishing www-redesign? -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
Chris Gianelloni wrote: > Imagine you have userpriv in FEATURES. If an ebuild has > RESTRICT=userpriv, it *WILL* disable userpriv, no matter what the user > does. Adding ACCEPT_RESTRICT allows the user to not list userpriv (or > -userpriv if userpriv is on by default) and the ebuild WILL NOT RUN if > it requires userpriv be disabled. What should it do then? Does emerge error out, or is there some kind of indication or message that the package going to be ignored? Does nomerge get some colored letters when you do emerge -Dtvp world? Do we show this in the deptree or when it's time for the package to be built? I don't like that portage will override a user's FEATURES, especially if it's something explicitly specified and silently ignored. I don't think ACCEPT_RESTRICT is the way to handle it though. I would rather portage display a message explaining the restriction and then a) continue if the package is part of a larger target (ie. emerge -DtvuNp world) and currently installed, or b) error if the package was specified on the command line or is not currently installed. Honestly, that would be scratching an itch of mine with fetch-restricted ebuilds killing an unattended emerge world, but it might serve as a model for future stuff like RESTRICT=unattended too. -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: New developer: Raúl Porcel (armin76)
Petteri Räty wrote: > It's my pleasure to introduce to you Raúl "armin76" Porcel. He is > joining us to put maintainer-wanted stuff to the tree and remove stuff > via treecleaners. The teams he targets now are net-p2p, mozilla and > treecleaners. Welcome, Raúl! -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: metadatabase
Robert Buchholz wrote: > I don't want to sound negative and I like the idea a lot, but two things > are on my mind about this: > > It should also sync with changes in the tree, like package removals, > additions and package moves. For sure. > When you're talking about it on ebuild base: When a version bump is out, > will it inherit the flags of the version before? I'd say no. The flags could easily change from version to version, even from revbump to revbump. For example, a bump could introduce some kind of QA violation not present in the previous ebuild or fail 'make test' where the last version worked. Depends on what you're tracking I guess. -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: metadatabase (was: Dependencies on system packages)
Steve Long wrote: > Robert Buchholz wrote: > I understand that it's hard to distinguish a pkg that hasn't been checked, > but might need the C-compiler, from a pkg that doesn't need the compiler > but just hasn't been checked. That's where I was going with the database > stuff. >> Since the tree itself is the best database of the packages available, >> anything else would be a lot more overhead. > I really don't agree, altho I could well be missing something. Surely there > should be a maintenance/QA database which tracks the tree and where you > could put information like this (ie a boolean flag for this instance) which > simply shouldn't be exposed to users. There's no need for it, it doesn't > effect them, and why should it go in the ebuilds where a maintainer might > delete it? I just use a local db to keep track of stuff like this, but haven't thought of a way to turn this into a service and i don't think it's really doable. I think you'd need an entry for every ebuild in portage, times the number of archs, times an unlimited number of arbitrary fields (one for each thing you're tracking). Something like, say, checking every package in the tree for GPL-2 or GPL-2+ licenses doesn't need the separate arch entries of course, but stuff like GCC testing definitely does. Even if you did manage to set this up, I wouldn't want to maintain it. -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [rfc] transition system loggers to 'adm' user/group
Petteri Räty wrote: > Diego 'Flameeyes' Pettenò kirjoitti: >> It would be really nice, especially if the adm group could be used to be >> able >> to read the logs without using root login :) > Why not use the wheel group? adm is the standard unix group used to access system logs. there's a few good reasons you might want to give someone those permissions without full wheel access. -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Removal Announcements (or, "Bring out yer dead")
i'm just browsing the forums, and it seems there's still some complaints about not getting enough notice about packages being removed. i know, there's always going to be someone complaining, but i think there's a couple things we could do to improve the situation. one, the treecleaner team has decided to extend the pmasking period for packages we remove from 30 to 60 days. we hope this'll lessen the surprise factor for those people who do monthly upgrades. this only affects maintainer-needed ebuilds of course. two, we have a perfectly good announce ML that right now is only used for GLSAs, and an announcement forum that is used for GLSAs and major announcements. what do people think about posting last rites to these places, maybe in one post on a weekly basis like the package moves section in the GWN (which BTW is a very welcome addition ;)). what would we have to do to have this happen? i remember during the news GLEP there was discussion about how to get stuff posted to the announce lists, but i'm fuzzy on the details. thoughts, rants, zombie mobs? by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: New developer: Robert Buchholz (rbu)
Petteri Räty wrote: > So please give rbu the usual warm welcome. ...rbu roasting on an open fiiire... welcome rbu! =D -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Dependencies on system packages
Alec Warner <[EMAIL PROTECTED]> wrote: > Hrm, I thought I wrote about this a while ago but I don't see it on > archives.g.o so lets try again. > > > If your package is 'not important' meaning it will never be in > > 'system' for any profile, you should not depend on anything in > > 'system', as > stuff in system should already be installed in a given (sane) > configuration. > > > > If your package may be in 'system' in a given profile, you need to > ensure your package builds in the proper order, with regards to other > system packages. The classic example is zlib; if you need zlib to > uncompress something, then you should put zlib in the deps; that way > when someone is building say, a stage1, your package will build after > zlib, instead of before it. > > > > You have to be careful in deciding what to specify, as doing > > things > incorrectly in this case can often cause dependency loops which are > sometimes fun to debug; perl and openssl were infamous back in the > day for this. > > > > Enterprising users would specify the 'doc' useflag. openssl > > requires > perl to generate its docs and perl requires openssl for some > encryption stuff. Users would then complain about perl or openssl > not building, or portage getting really pissed at them; the solution > being to build openssl twice, once with USE="-doc" and then build > perl, and then rebuild openssl with USE="doc". This certainly wasn't > the only case where this occurred (see ML thread about shadow and > it's dep on some other package I can't remember, although that was a > while back as well). > > > > In conclusion, you need domain knowledge of system packages and > portage behavior to make good choices here ;) > > Wow that pasted nastily; hopefully it shows up ok ;) > > In any case I'm sure there are some other exceptions but these are > the main ones. Cool, that's exactly what I was looking for. thanks ;d signature.asc Description: PGP signature
[gentoo-dev] Re: Dependencies on system packages
Ryan Hill <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > > It's quite simple. You don't do it unless you are fully aware of the > > consequences. If you have to ask, you aren't fully aware of the > > consequences so you mustn't do it. > > That's a flawed argument. Not knowing doesn't prevent you from > asking, and asking will inform you of the consequences, assuming the > asked isn't a complete tool. Let me try this more diplomatically. How are we supposed to know if a package that's depending on a system package is a bug or an exception if we have no idea what the exception(s) is/are? Stephen Bennett wrote: > If you don't know about the unwritten yet near universal exception > clause then you shouldn't be invoking it. If it's universal, then why isn't it written somewhere? After all this, we *still* haven't gotten an answer to why some packages outside of the system target are depending on zlib. Is this a bug? If not, what's the reason it's there? Let's document this reason, so we don't have to go through this again in the future. It's that simple. signature.asc Description: PGP signature
[gentoo-dev] Re: [RFC] USE_EXPAND variable to choose ALSA PCM plugins
"Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote: > On Saturday 16 December 2006 22:18, Luca Barbato wrote: > > Not really I think as usual none == all ^^ > Yes, but I also plan to make all of them in the default set. I withdraw my objection then. ;d signature.asc Description: PGP signature
[gentoo-dev] Re: Dependencies on system packages
Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Sat, 16 Dec 2006 12:46:30 -0600 Ryan Hill <[EMAIL PROTECTED]> > wrote: > | Can we skip the sekrit rulez crap and just spell it out? Really, > | how does this help anyone? > > It's quite simple. You don't do it unless you are fully aware of the > consequences. If you have to ask, you aren't fully aware of the > consequences so you mustn't do it. That's a flawed argument. Not knowing doesn't prevent you from asking, and asking will inform you of the consequences, assuming the asked isn't a complete tool. signature.asc Description: PGP signature
[gentoo-dev] Re: [RFC] USE_EXPAND variable to choose ALSA PCM plugins
"Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote: > Not sure if anybody here knows, but alsa-plugins is not the only set > of plugins an user installs in its system, many others are installed > by alsa-lib itself, they are the basic plugins like dmix, dsnoop, > iec958, plug... the ones that many asoundrc already make use of. > > Now of course, most of the users need them, and disabling them would > be pretty bad, but again, there are reasons to disable some of them > at least, especially when targetting small embedded devices. > > If nobody has anything against this, I'll add an ALSA_PCM_PLUGINS > variable where users can choose the plugins they want built, to > reduce the amount of code installed by alsa-lib: > > Calculating dependencies... done! > [ebuild R ] media-libs/alsa-lib-1.0.14_rc1 USE="-alisp -debug > -doc -midi" ALSA_PCM_PLUGINS="-adpcm -alaw -asym -copy -dmix -dshare > -dsnoop -empty -extplug -file -hooks iec958 -ioplug -ladspa -lfloat > -linear -meter -mulaw -multi -null plug -rate -route -share -shm > -softvol" 0 kB I don't think the average user, even the average Gentoo user, has any idea what any of these plug-ins do, how they work, and which ones they need. This is getting a bit too complicated. Is there any way to install everything as we've always done but still provide some way for embedded to do their thing? Keeping the ALSA_PCM_PLUGINS around but putting it in USE_EXPAND_HIDDEN might work. People who want the ability to turn off alsa-lib plug-ins could then do so in make.conf without confusing the hell out of everyone else. ;) signature.asc Description: PGP signature
[gentoo-dev] Re: Dependencies on system packages
Stephen Bennett <[EMAIL PROTECTED]> wrote: > > Could you spell out that exception clause, please? > > It doesn't translate well into words, but we'll go with something > like "Unless you know exactly why the rule is there, understand > fully the implications of breaking it, and know why it's a > good idea in this particular case." > > However, if you're in a position to be invoking that clause, you > should know about it anyway. Can we skip the sekrit rulez crap and just spell it out? Really, how does this help anyone? signature.asc Description: PGP signature
[gentoo-dev] Re: adopt an orphan
Donnie Berkholz <[EMAIL PROTECTED]> wrote: > Ryan Hill wrote: > > I don't know what to do with unstaffed herds (eg. app-benchmarks). > > I guess it'd be better to get the packages into the herd rather > > than just leave them in maintainer-needed. > > I disagree, being in a herd gives people the impression that it's > maintained. True enough. I'll leave them alone. signature.asc Description: PGP signature
[gentoo-dev] adopt an orphan
I went through the list of packages currently in maintainer-needed status and matched them up with possible homes. If your team is interested in picking them up, feel free or just let me know and I'll take care of it for you. I don't know what to do with unstaffed herds (eg. app-benchmarks). I guess it'd be better to get the packages into the herd rather than just leave them in maintainer-needed. Thanks ;d app-backup (lisa robbat2) app-backup/furball app-backup/reoback app-benchmarks (ka0ttic) app-benchmarks/acovea app-benchmarks/contest app-benchmarks/dbench cluster (dberkholz ribosome tantive voxus xmerlin) sys-cluster/pvm-povray sys-cluster/saru sys-cluster/tentakel sys-cluster/wulfstat sys-cluster/xmlsysd crypto (alonbl dragonheart jokey method pfeifer robbat2 strerror trapni vanquirius) app-crypt/aes-crypt app-crypt/bcrypt app-crypt/cli-crypt app-crypt/cryptoapi app-crypt/keylookup app-crypt/keynote app-crypt/ssh-multiadd app-crypt/stan app-crypt/steghide graphics (g2boojum lu_zero malverian reb sekretarz vanquirius) media-gfx/DFBPoint media-gfx/aview media-gfx/crwinfo media-gfx/cthumb media-gfx/figurine media-gfx/flphoto media-gfx/gozer media-gfx/icon-slicer media-gfx/icoutils media-gfx/igal media-gfx/imgseek media-gfx/imlib2_tools media-gfx/jpeginfo media-gfx/megapov media-gfx/mkgallery media-gfx/photopc media-gfx/pngcrush media-gfx/pngrewrite media-gfx/pngtoico media-gfx/povray media-gfx/propaganda media-gfx/tgif media-gfx/videorbits media-gfx/xfig media-gfx/xli media-gfx/zgv java (betelgeuse caster gurligebis karltk nelchael nichoj sanchan wltjr) dev-java/bluej-bin media-optical (beandog metalgod pylon) app-cdr/kover app-cdr/qpxtool mobile (betelgeuse cardoe compnerd genstef latexer liquidx peper phreak sekretarz steev) app-laptop/configure-thinkpad app-laptop/lphdisk net-ftp (humpback uberlord) net-ftp/atftp net-ftp/axyftp net-ftp/deadftp net-ftp/easyftp net-ftp/ftpd net-ftp/glftpd net-ftp/gtkfxp net-ftp/netkit-tftp net-ftp/profxp net-ftp/swiftfxp net-ftp/tftp-hpa net-ftp/yafc net-im (chainsaw gothgirl humpback reb sekretarz tester) net-im/ccmsn net-im/gyach net-im/linpopup net-im/ntame net-mail (ferdy g2boojum hansmi hattya langthang lcars nakano robbat2 slarti st_lim strerror ticho tove) mail-client/mutt-vc-query mail-mta/courier net-news (swegener) net-news/amphetadesk net-nntp/nget net-p2p (betelgeuse graaff kang malverian mkay sekretarz squinky86) net-p2p/qtorrent pda (chriswhite liquidx peper) app-pda/iripdb app-pda/malsync app-pda/synce-multisync_plugin app-pda/synce-rra perl (chriswhite ian mcummings superlag yuval) dev-perl/adocman ruby (caleb flameeyes mattm pclouds pythonhead twp usata) dev-ruby/color-tools dev-ruby/needle dev-ruby/rubyfilter scheme (mkennedy) dev-scheme/mit-scheme tcltk (matsuu ming) dev-tcltk/Tk_Theme dev-tcltk/blt dev-tcltk/bwidget dev-tcltk/ck dev-tcltk/expect dev-tcltk/iwidgets dev-tcltk/scwoop dev-tcltk/tcl-debug dev-tcltk/tcldom dev-tcltk/tcllib dev-tcltk/tclperl dev-tcltk/tclpython dev-tcltk/tclreadline dev-tcltk/tclxml dev-tcltk/tclxml-expat dev-tcltk/tix dev-tcltk/tkTheme dev-tcltk/tkXwin dev-tcltk/tkpiechart dev-tcltk/tktable dev-tcltk/tls tools-portage (fuzzyray genone johnm karltk tercel) app-portage/portage-prefpane wine (vapier) app-emulation/winex www-servers (bangert bass beu ka0ttic stuart) www-servers/aolserver www-servers/publicfile x11 (azarah battousai dberkholz eradicator joshuabaergen lu_zero) x11-base/xdirectfb That's enough for now. signature.asc Description: PGP signature
[gentoo-dev] Re: missing metadata.xml
[EMAIL PROTECTED] (Christian Faulhammer) wrote: > Donnie Berkholz schrieb: > > Christian Faulhammer wrote: > >> Nice idea, but you should really add no-herd as this > >> is required if there is only a "maintainer". > > Really? isn't valid? I'd rather see that than adding a > > "fake" herd. > > I though I read about it being mandatory with "no-herd"...yes Alec > Warner wrote that (implicitly). But I am not really sure. At least, > herd tag is mandatory, in whatever way. http://devmanual.gentoo.org/ebuild-writing/misc-files/metadata/index.html http://www.gentoo.org/proj/en/metastructure/herds/index.xml signature.asc Description: PGP signature
[gentoo-dev] Re: last rites for app-antivirus/vlnx
Timothy Redaelli <[EMAIL PROTECTED]> wrote: > can't fix rpath, application check its checksum Bug #? signature.asc Description: PGP signature
[gentoo-dev] Re: spamc standalone package
Enrico Weigelt <[EMAIL PROTECTED]> wrote: > is anyone else working on an standalone spamc package ? > I've got several machines where I don't want to have the whole > spamassassin installed - they're just calling an remote machine > to do this work. Sounds like a good question for the Networking forum and/or gentoo-user ML. -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: PGP signature
[gentoo-dev] Re: FEATURES to cut the excess in portage
Enrico Weigelt <[EMAIL PROTECTED]> wrote: > Can those flags be used in dependencies ? Not as far as I know. They're FEATURES, not flags, and are global. > Let's say, some package needs certain tools (ie. TeX) for building > its documentation, it would be stupid to build the whole docs > and so require these tools, if docs are not wanted at all. That's what the doc USE flag is for. ;) -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: PGP signature
[gentoo-dev] Re: [ANNOUNCE] Anonymous CVS and SVN now available
Robin H. Johnson wrote: > KingTaco and I are pleased to announce that we've completed > setting up and testing the anonymous read-only CVS and SVN > services for Gentoo repositories, and that they are now > available for use. > Thanks go to: kengland, robbat2, kingtaco, ramereth, and > several others for helping this to happen. Thanks to everyone who put their time and effort into this. :D -- by design, by neglect [EMAIL PROTECTED]for a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Ignoring/overwriting IUSE from an eclass
Ryan Hill wrote: > I'm sorry, but is anyone else sick and disgusted with Ciaran talking to > people like this? This isn't called for and shouldn't be tolerated. After sleeping on it, I've decided my problem is personal, so i've just taken my own advice and set up a simple mail filter so I don't have to listen to this crap anymore. Unless, of course people respond, which is inevitable. But, I encourage anyone else tired of the bullshit to do the same, and maybe we can get the signal to noise ratio down to a reasonable level. Sorry for the noise. -- by design, by neglect [EMAIL PROTECTED]for a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Ignoring/overwriting IUSE from an eclass
Ciaran McCreesh wrote: > On Mon, 30 Oct 2006 19:21:46 +0100 Piotr Jaroszyński <[EMAIL PROTECTED]> > wrote: > | > And it doesn't work. > | > | Wanna bet? Of course you must put it in the x-modular.eclass, but I > | thought that's quite obvious as spyderous was talking about adding > | IUSE="" to that eclass. > > Yes, I do want to bet. You don't have a clue what you're talking about > and you don't have a clue how to use bash substitution correctly. > > Just what do you think will happen when another eclass sets IUSE="X" and > it's supposed to be kept? > > Just what do you think will happen when another eclass sets > IUSE="Xaw3d"? > > Just what do you think will happen when Portage internals change? This > has happened several times with those variables? > > Your solution is approximately on par with fixing a wobbly chair by > sawing off all four legs and then attaching what's left to a crocodile. > With the kind of idiocy you're spewing, do you really wonder why people > have no faith in Sunrise? I'm sorry, but is anyone else sick and disgusted with Ciaran talking to people like this? This isn't called for and shouldn't be tolerated. -- by design, by neglect [EMAIL PROTECTED]for a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: jpeg-mmx is dead
Mike Frysinger wrote: > upstream says it's dead and they dont want people using it ... considering > the > problems we've seen that sounds just peachy > > p.masked now > -mike oh thank god. -- by design, by neglect [EMAIL PROTECTED]for a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Global USE flags (Was: mplayer global use flag)
Caleb Cushing wrote: > maybe it would be a lot of work. to even develop the tools. but it > would be nice if a global use flag could have a detailed option. this has been discussed a few times before. i think there's even a bug for it (don't remember the #). > example. > > euse -i mplayer [+ C ] mplayer - Enable mplayer support for playback > or encoding > > is what we currently get. > > add a -d option for --descriptive euse -id mplayer could show > something like [+ C ] mplayer - Enable mplayer support for playback > or encoding media-video/kmplayer - adds the ability to play back > media using the mplayer engine euse already does this actually. ;) $ grep "^doc" /usr/portage/gentoo-x86/profiles/use.desc doc - Adds extra documentation (API, Javadoc, etc) $ grep ":doc" /usr/portage/gentoo-x86/profiles/use.local.desc dummy-cat/fakepkg:doc - This is a package specific USE description. $ euse -i doc global use flags (searching: doc) [-] doc - Adds extra documentation (API, Javadoc, etc) local use flags (searching: doc) [-] doc (dummy-cat/fakepkg): This is a package specific USE description. i keep meaning to look at how other USE-type utils handle it. -- by design, by neglect [EMAIL PROTECTED]for a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: firefox-2.0
Michal Kurgan wrote: > Recently new firefox-2.0 was released. > I (and probably many other users) am interested when this new version would > be unmasked and stabilized. If there are any problems, what are they and what > to expect if i would force installation now? Is there any roadmap or timeline > for stabilization already? Did you try, maybe, looking in bugzilla? -- by design, by neglect [EMAIL PROTECTED]for a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: New developer: Christian Faulhammer (opfer)
Christian Heim wrote: > Its my pleasure to introduce to you Christian Faulhammer (also known as > opfer), our latest addition helping with xemacs and the x86 monkeys. Woo hoo! :D -- by design, by neglect [EMAIL PROTECTED]for a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: New developer: Ryan Hill (dirtyepic)
Petteri Räty wrote: > It's my pleasure to introduce to you Ryan "dirtyepic" Hill. He is > joining us to help with the endless x86 testing effort, treecleaners, > and gcc-porting. You might remember him for the work he did for getting > gcc 4.1 marked stable. > > He hails from a town that most can't pronounce correctly, namely > Saskatchewan, Canada. He has an interesting day job. He writes about it > as follows: "My day job is legal land surveying for the oil and gas > industry, which sounds important but amounts to spending most of my time > nose deep in a canola field strapped to a GPS mapping unit." > > His hobbies are quite interesting too: " When I'm not enjoying the > -40/+40C Canadian weather or dodging lightning, I like messing > with GCC, watching something from the Whedon-verse on DVD, listening to > The Tragically Hip, and playing Neverwinter on my laptop, usually all at > the same time. If you're wondering about the nick, > http://www.discogs.com/release/3237 ;)" > > So please give dirtyepic the usual warm welcome. Thanks everybody. :D -- by design, by neglect [EMAIL PROTECTED]for a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: RFC: Gentoo Commitfests
Ilya A. Volynets-Evenbakh wrote: > So, are you proposing to encourage people to do commits for > the sake of commits? Make people do revbumps/keywording > just to get their commits in, without doing proper testing? > Or to hold on number of commits till commitfest? I would hope that people would be mature enough to enjoy this as a community event and have some fun, not game the system just to see their name on a graph. --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: RFC: per-package default USE flags
Jakub Moc wrote: > Ciaran McCreesh napsal(a): > >> The profiles change over time. Currently, when the profiles change, the >> only thing that has to be checked for conflicting USE behaviour is >> subprofiles. With IUSE defaults, the person making the change will also >> have to do a sanity check over the entire tree. > > Uh, what kind of conflicting behaviour and what sanity checks are you > talking about here? Did you _really_ miss the whole point of this feature? Jakub, just put him in your killfile and move on. It's not worth it. -de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Recommended -march settings [was: Re: CFLAGS paragraph submission for the GWN]
Mike Frysinger wrote: > On Saturday 14 October 2006 04:49, Sebastian Bergmann wrote: >>CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" > here's a good reason why gentoo-wiki is not official ... this is wrong. the > duo cpu's are not based on the pentium4 which is what the prescott is That was put there by me. The thing is, while the Core CPUs have more in common with the Pentium-M micro-architecture, -march=pentium-m highly favors generating x87 over SSE/SSE2 instructions, since on a Pentium-M doing SSE/SSE2 was somewhere in the neighbourhood of 30% slower. Core chips have improved decoding and use micro-op fusion to combine up to four SSE instructions. Also, with code doing fp to int conversion or single precision division, SSE scalar ops are the win on Core (though not as big as Netburst) since x87 instructions have to write data to memory and read it again to reduce precision. Based on that I've been doing benchmarks with GCC 4.1 and trunk and I usually find '-march=prescott -mfpmath=sse' to do a bit better than '-march=pentium-m -mfpmath=sse -msse3', and just plain '-march=prescott' to be near identical to plain '-march=pentium-m' (for those ebuilds that call strip-flags ;), though the latter is on average <=1% faster. '-march=pentium-m -msse3' has actually been the worst performer, though I have no idea why it's slower than just '-march=pentium-m'. To be honest I don't really trust GCC's SSE3 support in it's current state. I've looked hard and long for an official answer to this but no one seems to be able to give a concrete reason why one is better than the other, other than "it's based on the Pentium-M". It _is_, but it's still a very different animal. Until I got one I thought it'd be best to document both. --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [RFC] CFLAGS paragraph for the GWN
Duncan wrote: > Could you point me at some info on this one (-ftree-vectorize)? It came > up on the amd64 list a week or so ago, when someone asked what I thought > of it and why I didn't have it in my cflags (which I had just explained). > I said I didn't know enough about it to make a case either way, and as > such, didn't choose to use it. However, after a bit of discussion, I > decided to add it to my cflags on a very experimental basis. I haven't > experienced any issues with it, but then I haven't done any major > compiling since then either, only the routine updates. http://tinyurl.com/l75we They've fixed quite a few of the ICE's since last I looked, though there's more than a couple that went in after 4.1.1. 4.2 is a little better, but I'm having enough trouble getting it to build things properly _without_ using any fancy flags right now. ;p See http://tinyurl.com/rt3aa for some real-world examples. > Or does the problem not necessarily apply to amd64? Even knowing that > would be useful. I simply don't know anything much at all about it, beyond > a generally vague idea that it means using mmx/sse/whatever vector > instructions to parallelize loops. I'd say that there's more ICE's on i686-pc-linux-gnu than x86_64-*-linux-gnu, but there's still enough. Luckily Halcy0n was really good for reducing testcases and pushing them upstream, so a lot of these issues got fixed at the source. --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [RFC] CFLAGS paragraph for the GWN
Lionel Bouton wrote: > I'll wait and see if other devs are aware of common CFLAGS gotchas > plaguing bugzilla. Flags such as -fforce-addr and -fweb that change the way registers are handled can often cause errors when compiling hand-optimised ASM on architectures with a very limited number of registers (ie. x86). This turns up a lot in video libraries or graphic processing apps like ffmpeg, xine-lib, or avidemux. --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [RFC] CFLAGS paragraph for the GWN
Robin H. Johnson wrote: > On Sat, Sep 30, 2006 at 03:48:53PM -0600, Ryan Hill wrote: >> Lionel Bouton wrote: >>> There are already good resources (http://gentoo-wiki.com/CFLAGS_matrix >>> was mentioned to me by robbat2) but they may not be advertised enough. >> Most of the info on that page is wrong. > The items on there that note breakages are reasonably correct. > -fvisibility=hidden and -ffast-math DO cause breakages. > > -ftree-loop-linear likewise is broken on GCC4.1 last I checked. I thought he wanted flags that broke upgrading between GCC 3.4 and 4.1. tree-loop-linear wasn't in 3.4. If you want flags that just break stuff with 4.1 you can include -ftree-vectorize. >>> I'd like to propose a paragraph to the GWN editor which presents some >>> gotchas and good references on the subject. >> Honestly, the only good reference is the Safe CFLAGS page. > The objective here was mainly to point out some things that users are > doing that are causing breakages, leading to bugs that are ultimately > marked INVALID after much tracing. Like using CFLAGS not on the Safe CFLAGS page? ;) Monsieur Spanky wrote: > no way will our documentation link to gentoo-wiki.com It's not documentation, it's the GWN, which has linked to gentoo-wiki before. --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [RFC] CFLAGS paragraph for the GWN
Lionel Bouton wrote: > There are already good resources (http://gentoo-wiki.com/CFLAGS_matrix > was mentioned to me by robbat2) but they may not be advertised enough. Most of the info on that page is wrong. > I'd like to propose a paragraph to the GWN editor which presents some > gotchas and good references on the subject. Honestly, the only good reference is the Safe CFLAGS page. > If possible, I'd like to expand the list of 3.4.6 -> 4.1.1 upgrade > problems which are linked to experimental CFLAGS. If you want to expand > the subject to cover other tuning/stability gotchas that recent updates > might have brought into the light, please feel free to do so. As English > is not my native tongue, feel free to spell check too. The english and speeling seem fine. --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: New Developer: Jim Ramsay (lack)
Christian Heim wrote: > Its my pleasure to introduce to you lack, our recent addition joining us to > take care of the rox-related ebuilds. > > He hails from Saskatoon, Saskatchewan, Canada. When he's unplugged from his > computer, he tries to play some guitar and write songs (he even plays in two > bands). He also has another hobby, called marriage (so far it has lasted for > 5 years according to Jim). Mwahaha. The Saskatchewan conspiracy has begun. --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: New dev: dev-zero
Simon Stelling wrote: > Hi all, > > It is with great pleasure that I announce the devification of Tiziano > 'dev-zero' M�ller. He writes us: > > "I'm from Zurich, Switzerland. Born here and still living here :-) > I'm studying physics at the University of Zurich and working > in a small company as IT responsabilitee and software engineer. > > I also worked on a subproject of the LHC (Large Hadron Collider), called > LHCb. I'm responsible for the database design and implementation > (postgresql) for the sensor test database. > > Besides that I'm working as a freelance software consultant for a couple > of private customers. > > If I'm not working, I'm playing the violin or watching movies." > > With this addition, the Swiss conspiracy soon will be powerful enough to > bribe everybody else with chocolate, so you better watch out. > > Everybody please give Tiziano a warm welcome! He's worked for a project that at one time had people concerned of the possibility of creating a stable micro black hole and you want to bribe people with chocolate? Think big! ;) Welcome Tiziano! --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: New dev: dev-zero
Simon Stelling wrote: > Hi all, > > It is with great pleasure that I announce the devification of Tiziano > 'dev-zero' M�ller. He writes us: > > "I'm from Zurich, Switzerland. Born here and still living here :-) > I'm studying physics at the University of Zurich and working > in a small company as IT responsabilitee and software engineer. > > I also worked on a subproject of the LHC (Large Hadron Collider), called > LHCb. I'm responsible for the database design and implementation > (postgresql) for the sensor test database. > > Besides that I'm working as a freelance software consultant for a couple > of private customers. > > If I'm not working, I'm playing the violin or watching movies." > > With this addition, the Swiss conspiracy soon will be powerful enough to > bribe everybody else with chocolate, so you better watch out. > > Everybody please give Tiziano a warm welcome! He's worked for a project that at one time had people concerned of the possibility of creating a stable micro black hole and you want to bribe people with chocolate? Think big! ;) Welcome Tiziano! --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: The Seed Project - Try 2
Lance Albertson wrote: > From my point of view, it would have been nice to have at least been > asked what infra could do to host these tarballs down the road. That > way, we have a sound plan of doing a good release when they're ready. I > don't like the idea of them springing a release and then asking us to > host it in a week. Things like this need to be planned from an infra > point of view, just like releases from releng are. "Dear Infra. Some time in the distant future, we might need some kind of space to hold some kind of media. We have no idea how large or small it will be, nor the format, nor what the audience will be, since all we have at the moment is a project page and a concept. We're not sure when we'll need this indeterminate media hosted, or for how long. Please let us know what you can do to accommodate us." XOXOX Random Dev ;) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: GLEP 52 - GLEP 23 revisited
Simon Stelling wrote: > Hello all, > > I would like you to share your comments on the attached GLEP with me. > > Thanks in advance! I think I agree with the others. Excellent idea though; thanks for giving this issue your attention. --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: default USE flags in profiles (oss)
Mike Frysinger wrote: > oss is dead, why bother going with it in default USE anymore ? alsa forever ! i think the standard argument is games. i've never needed it though. --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Why you use Gentoo
So, wondering why people use Gentoo. Put [dev] or something if you're an actual gentoo dev and [user] if you're a user. Doesn't need to be fancy, you can put "community" or something if that's all you want. All responses off list please. Thanks. I use Gentoo because of its intelligent user community that reads messages all the way through and actually understands simple directions like "all responses off list" before firing off their knee-jerk canned fanboy responses, especially when they're repeated three times. --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Paid support
Curtis Napier wrote: I know christel is consulting with an accountant about adpot-a-dev, Now there's a project we can get behind. QA might fall a bit though. --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [RFC] Required Features for $package_manager to Aid... Development!
Elfyn McBratney wrote: I've been inspired by the local/global USE flag threads recently posted by Doug (Cardoe), and it got me to thinking... I've recently joined the pkgcore development effort, and was asked by Brian (ferringb) what I'd like to hack on/what my niggles with portage are. My personal one is why updates/ and binpkg mangling takes so long in portage-$current. But I'd like to know, what are everyone elses? I've been thinking about this lately too. I think it would be a good idea to come up with as many different use cases as we can think of and figure out what we can already do, what we would like to do, and the best way to do it. I know that this topic have been rehashed since the dawn of time^Wgentoo-dev, but these things get lost, opinions change... and since last year, new and viable alternate package managers have cropped up. So, basically I'd like to ask all on this list: - what package manager features would make *your* life easier? - current pet peeve is some way of dealing with SRC_URI's that use dynamic redirects to the source files (eg. http://nwvault.ign.com/fms/Download.php?id=57167 -> http://someserver.com/randomlygeneratedhashthatchangeseveryhour/the_HeX_coda_01_v1.3.zip). Since the name of the file fetched (the_HeX_coda_01_v1.3.zip) != the one in SRC_URI (Download.php?id=57167) portage bombs. right now i have to use RESTRICT="fetch" which sucks. --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: The Age of the Universe
Chris Gianelloni wrote: > On Sat, 2006-09-02 at 23:11 -0600, Ryan Hill wrote: >> I'd have to agree with you on that. I understand the appeal of exciting press releases but there were over 75 GCC 4.1 bugs still open for problems in *~arch* when the decision was made to go stable. Even now there's more than 50 left, with an equal and growing number of stable bugs. > > It had nothing to do with press releases and more to do with the fact > that 50 or even 75 out of > 10,000 is beans. Also, most of that stuff > is in packages that are either unmaintained, or the maintainers are > focusing efforts in other places. Having a bug report open for 2 months > *should* be *plenty* of time for maintainers to fix their packages. Great to hear that. I'll be with the rest of the x86 team working this afternoon and most of tonight fixing those beans. We actually need a games maintainer, considering about half the bugs fall under that category. See you there. :) --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: packages going into the tree with non-gentoo maintainers
Kevin F. Quinn wrote: If you don't care whether a package is stable or not, just let the arch team go ahead and do what they need to do to stabilise when they wish to. The role of package maintainer has nothing to do with stabilisation, which is the preserve of the arch teams. Um, sure it does. We're not going to stabilize something without attempting to contact the maintainer first. If it's maintainer-needed we'll just go ahead though. --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Gentoo 2006.1
Stuart Herbert wrote: GCC I suspect is surrounded by more confusion. Either the package maintainers or the arch teams could have made an announcement giving fair warning; alas, neither did. It was announced on June 27th and was in more than one issue of the GWN since then. --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Monthly Gentoo Council Reminder for September
Alec Warner wrote: needs as far as QA. Last year Halcy0n petitioned for power for the QA team; it was quite like a ball crushing power (fix it or we will) and it seemed to have all kinds of frictional issues. This being a global issue I would like to hear thoughts on how this could be done better; or we can abandon the idea of a QA team. I don't recall that it was that heavy handed at all. It said that the QA team would work with maintainers to improve the quality of the tree, and only in *emergency* situations would be empowered to take necessary measures to address the issue. The major point of contention seemed to concern the situation where QA and maintainers strongly disagreed on whether or not a QA problem actually exists and were unable to come to a resolution between themselves. In that case, the issue would be appealed to the council for judgement. Now it also stated that the QA team had veto power over the maintainer until the council can come to a decision. I personally don't agree with this at all, except in the case of security related issues. Even so, I think this falls more under the umbrella of the security team rather than QA. I do believe the QA team should have the ability to make trivial changes to ebuilds (such as obvious typos and other minor issues), but all effort should probably be made to first discuss these issues with the maintainers themselves. Veto power *needs* to be the absolute last resource, and should very rarely, if ever, be necessary. --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: The Age of the Universe
Carsten Lohrke wrote: we're understaffed, partly - and this is my very personal opinion - the problem is that releasing with GCC 4.x has been rushed I'd have to agree with you on that. I understand the appeal of exciting press releases but there were over 75 GCC 4.1 bugs still open for problems in *~arch* when the decision was made to go stable. Even now there's more than 50 left, with an equal and growing number of stable bugs. On the other hand, the (misinformed?) perception that Gentoo was trailing further and further behind the other distros in terms of version numbers had been raised more than a couple times in the last six months, so i can see the reasoning behind wanting to make a statement. --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GLEP 39 compliance
Wernfried Haas wrote: As far i am concerned, i find seperate sections quite good as it's a clear solution as it's easy to see who is an official Gentoo monkey who did all the quiz stuff etc. May be subject to personal taste though. Some of the unofficial monkeys have also done the quiz stuff etc. ;) But yeah, I like the dev / contributor separation myself. --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] GCC 4.1 Reminder and Update
Just a reminder that GCC 4.1 will be going stable on x86 and amd64 very shortly (according to GWN at least), and is already stable on PPC. If you have any bugs blocking bug #140707 [i] please have a look and CC the relevant arch teams for stabilization. I'll be pinging bugs that haven't seen any progress tonight and would like to set a deadline of Sept 1st to respond after which archs will be CCed by us. Does this sound acceptable? I'd also like to note that even if your team has no interest whatsoever in GCC 4.1, it's still worth it to have a quick look. We've uncovered a lot of obscure crap that can really use an update. ;) Currently, there are 55 open stabilization bugs, out of 82 total. Not all these are actually blockers as there are a few bugs that are resolved for x86, amd64, and PPC and just waiting for other archs. There are also 46 bugs still open on bug #117482 [ii] out of 299 total. These are issues which haven't yet been fixed in ~arch. Thanks to everyone that worked on this, especially the arch teams for putting up with the flood of bugs and my relative inexperience ;). --de. [i] https://bugs.gentoo.org/show_bug.cgi?id=140707 [ii] https://bugs.gentoo.org/show_bug.cgi?id=117482 -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: RFC: AT emerge info cruft > attachments on bugs.g.o
Jeroen Roovers wrote: On a minor note, I'd also like to see bug reporters use canonical package names in bug descriptions, including the category (and preferably the specific version, not some >=foo-3*!!!one, not to mention specifying no version at all). Including the category means arch devs won't need to guess/discover which of a few hundred categories a package is meant to reside in. Yeah, this should be standard. I like to also put the current stable in the comment (when there's not a pantload of arches at different stable versions at least). Doubt it matters but, meh.. --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: RFC: AT emerge info cruft > attachments on bugs.g.o
Duncan wrote:
Matti Bickel <[EMAIL PROTECTED]> posted [EMAIL PROTECTED],
excerpted below, on Thu, 10 Aug 2006 23:59:51 +0200:
Thomas Cort <[EMAIL PROTECTED]> wrote:
Why do arch testers need to post `emerge --info` if everything works?
Shouldn't we be able to trust that they have sane CFLAGS, proper
FEATURES, and an up to date system?
Once there was the idea of putting AT testing system specs somewhere, so arch
devs could actually see what we're running. Is this still needed or is the
number of ATs small enough to keep that in head-RAM?
Anyways, I agree that posting emerge --info to a highly frequented stable bug
is annoying and should be abolished.
Even back before it became the "in" thing, I was posting emerge --info as
attachments, because it simply fit the bill -- bugzy /says/ to put long
stuff as attachments. I never did quite understand why all that
admittedly often useful high-volume spew was tolerated in the bug comments
themselves.
bugzy also says "('emerge --info' goes here)" above Description and
"(this is where you put 'emerge --info') above Comments. ;) you're
right, it does say make it an attachment if it's too long, but how long
is too long?
--de.
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: RFC: AT emerge info cruft > attachments to [STABLE] bugs
Chris Gianelloni wrote: No. It really should be inline. I'm sorry if you think that 5K seems like a lot of "spam" but having to open a browser just to look at "emerge --info" is a complete waste of time. *ding* it's also nice to have that information actually _in_ my mailbox and not of at the end of some attachment URL, considering i'm offline 5 days of the week. i've been in this situation a few times now, where i've needed an attachment from a bug i'm working on and had to wait half a week to do anything with it. yeah i'm a corner case, and needing an AT's emerge --info isn't that common, but why cut these corners when we don't have to? especially since the reason for doing so is to save someone from having to actually scroll a mouse wheel or hit delete, or be bothered with getting an email when a AT posts their info in a comment (which you'll still get if they do it as an attachment anyways). --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: app-doc/chmlib - call for maintainer
Raphael Marichez wrote: > app-doc/chmlib is without an active ebuild maintainer and has an open > security > bug [1] > > Anyone willing to take care of this package in the future, please update > metadata.xml and CC yourself on the bug. > > [1] https://bugs.gentoo.org/show_bug.cgi?id=143181 if no one else takes it (and i sneak by the recruiters ;)) i can. i use it daily and follow the ml. --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Resignation
Ciaran McCreesh wrote: On Sun, 30 Jul 2006 23:22:33 -0600 Ryan Hill <[EMAIL PROTECTED]> | Ciaran McCreesh wrote: | > Did you look at *which* actual Gentoo developers are on the list? | | You know, that was a completely unnecessary personal attack. God | forbid anyone take the time to attempt something they think may be | beneficial to the community. If you in all your elitist wisdom think | you can do better then try helping out. If not, then please fuck off. Good intentions and trying to be helpful don't keep users or developers. Screwups lose users and developers. Would you stick a bunch of war evacuees on a plane piloted by Britney Spears if she said she was doing it because she wanted to be helpful? Britney Spears being the Sunrise Developers and the evacuees being.. a bunch of packages that have no relevance whatsoever since they're copies of ebuilds already in bugzilla? When Britney crashes and burns the ebuilds aren't vapourized into a fine red mist. If Sunrise bombs we're back to the status quo with nothing lost. | > Even that aside, if a couple of hundred developers can't handle | > doing QA for all those maintainer-wanted ebuilds, what makes you | > think four people can? | | If a couple of hundred developers actually paid any attention | whatsoever to maintainer-wanted ebuilds then there wouldn't have to | be any such project in the first place. A couple of hundred developers can barely handle the main tree... True. Some of them want to focus on the nastier bits of it though. Why should we stop them? Hostility aside, do you have any alternate ideas? --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Resignation
Ciaran McCreesh wrote: On Sun, 30 Jul 2006 23:20:16 -0500 "Alex Tarkovsky" | This "no QA" accusation is a complete myth. QA led by actual Gentoo | developers is indeed in place at Sunrise [1]. Did you look at *which* actual Gentoo developers are on the list? You know, that was a completely unnecessary personal attack. God forbid anyone take the time to attempt something they think may be beneficial to the community. If you in all your elitist wisdom think you can do better then try helping out. If not, then please fuck off. Even that aside, if a couple of hundred developers can't handle doing QA for all those maintainer-wanted ebuilds, what makes you think four people can? If a couple of hundred developers actually paid any attention whatsoever to maintainer-wanted ebuilds then there wouldn't have to be any such project in the first place. --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Stable Staleness (mostly toolchain)
Alec Warner wrote: I'm not sure if I'm misreading here, I'm not advocating we dump older gcc versions. Moreso I'm advocating we dump code that doesn't compile with newer gcc/toolchain versions that no one is willing to fix. We have had devs in the past bring in far too many packages and then just leave, so half of them get picked up by other devs, and the other half sit there and rot. Mostly once again, maintainer-needed packages :0 Sorry, for some reason I reversed the entire meaning of your message to refer to packages that build with the current toolchain but not an older one. I blame the hangover and the strangely persuasive goat people. Right now I'm in the middle (well, okay, maybe first quarter) of getting everything in stable working with GCC-4.1.1. If (when) I encounter anything that makes me run away arms flailing in horror I will be happy to CC tree-cleaners (misery loves company) ;). --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Stable Staleness (mostly toolchain)
Alec Warner wrote: Another class of packages I wish to discuss (not remove quite yet, just talking ;) ) are older packages with stable markings. By Stable I mean debian stable, IE we stabled it in 2004 and no one has touched it since. Do these packages still work with a current system (linux 2.4/2.6, glibc-2.3/2.4, >=gcc-3.4, etc... So partially this is a question for gcc porting, how many *known broken* apps don't get fixed when we upgrade and stable a gcc version. Depends how much notice we get ahead of time. Things like 'btw we want 4.1 stable for 2006.1' two weeks in advance tend to create more havoc than usual. Do these stay in the tree, and do they have deps on older versions of gcc (effectively masking them, since old versions of gcc generally get masked by profile eventually). Most major archs have at least some version of 3.3 and 3.4 available in stable. Sometimes even 2.95, and some lucky winners have 4.1 in ~arch. amd64 has 3.3 masked for some reason i don't understand, and other arches might too. i'm just going off of what eshowkw tells me. Unless there's a very good reason, older GCC versions shouldn't be punted because it's extremely useful to be able to test your code on a variety of different compilers. How many apps are just sitting in the tree and no one knows if they compile at all with a recent system? Once I'm through with them, hopefully none. ;) I know of a couple packages that won't compile with GCC 3.3, but for most I have a patch or workaround. libmpeg3 is one, can't remember any others off the top of my head. I think also that genone's Gentoo-Stats project would be a great information aggregator as we could identify packages that no one uses anymore. +1 Anyway, these were just some thoughts I had about trimming the tree a bit; feel free to rip em apart as always :0 BTW, I'm interested in joining the Tree Cleaners project once my dev stuff goes through, if it's cool with you. --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: proxy-dev (an alternative to sunrise?)
Luis Francisco Araujo wrote: The 'modus-operandi' would go like this: 1 - We setup a mailing list (yes, yet another one, but this one is gonna be useful!) , call it , [EMAIL PROTECTED] , or [EMAIL PROTECTED] 2 - Developers interested to serve as a proxy , subscribe to the list. 3 - Users ask on this mailing list if there exist any developer interested to include X, or Y ebuild into the tree. (Probably we could create a template for this?) 4 - An interested developer says 'yes' on the list (so the rest of devel can see him too) , and from there on, the developer and the user work off-list. Or a developer can say 'no'. Explaining the reason (if any) of why this ebuild shouldn't be included into the tree. So far the only difference between this and doing a query on b.g.o for maintainer-wanted is that it's on mailing list. Now .. most of you must already be thinking, "well .. isn't this the same that going and picking maintainer-wanted ebuilds after all?" Yep. ;) Here it comes the trick or 'trap' ;-) The user _has_ to compromise to take care of those previous commented three points that some of us might be afraid of, besides of giving us a centralized way of keeping informed about new ebuilds. _Has_ to? How do we enforce that? The users explicitly compromise to (just to make it clear): 1 - To fix *all* bugs and problems of the package: The user will need to take care of all the bugs and problems of the specific package. Including all dependencies if needed, in the case that the package need dependencies that are not in the tree yet. (All these requirements should of course be explicitly stated in the user request email) 2 - To keep track of upstream: The user needs to know the package's project, and all the communication with upstream should be responsibility of the user. we also sometimes find developers of a specific project who would like to cooperate with gentoo , in my opinion this model would give them an easy and organized opportunity to do so either. 3 - This will give us a nice way to officially include into the tree those packages that are more interesting for our users community. After all they are the ones maintaining them. 4 - These users will need to keep constant and fluent communication with the developers , you can even call it a 'team' , where the gentoo developer is the official representation of the project. This also would give a nice 'isolated' environment , where Gentoo as a project only would see one developer , so we don't need any internal changes to our current way of working. /me knock infra doors :-) So basically, the user does all the work in exchange for the ebuild being in portage. Once it's in they disappear off the face of the earth. I still don't see how this is any different than the status quo. This evidently brings some developers responsibilities too, we will need to review, and test the ebuilds. we sometimes will have to check with upstream, and comment on the ebuild, or fixing some details. But it should be a far minimimal effort than the developer taking care of the package(s) by his own, in the better of the cases, he even shouldn't do anything but to test, review and commit, from there on, the ebuild will be under the standard procedures of maintenance (arch testing to stabilize, bug reports to notify problems, etc). The developer should also take care of any internal developer communication if needed. Right, just like now. You also can see, how we would be growing the seeds for future developers right? I know there already exist some developers working as proxy, well, i appreciate if they got any comment or observation about this idea. This is just a way of giving some organization to this kind of cooperative mechanism at some degree. And an 'official' representation inside Gentoo if we agree with it. I don't think it's necessary to formalize it. If you find a user who wants to help then great. Go ahead. You're free to define whatever relationships that work for you. It doesn't have to be officially stamped and sealed, it's just everyday social interaction. --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
Richard Fish wrote: On 7/27/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote: The "majority" of packages are also the ones that need more extensive testing. Sure, we could probably stabilize a bunch of the fringe packages that hardly anyone uses and it wouldn't affect anything. The majority of Aliz's database seems to be made up of these "fringe" packages. Many of which are stable on at least one arch already, or have only a single version in the tree anyway. Stabilizing these on the remaining archs that they support should not have any significant impact on the perceived overall quality of Gentoo. I was planning on working through the list some time in the near future. I have to finish filing GCC 4.1 stabilization bugs for half the tree first. ;) --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
Chris Gianelloni wrote: > (stuff) "Me too!" Seriously, you nailed it on the head. How many times have you had this conversation: u: "Why is it taking so *!#$!@ long to get KDE/Gnome/XFCE stabilized?! Fedora/Debian/Ubuntu got it a whole week ago! OMG!!1!" d: "It'll be stabilized once it's actually stable. If you want that version now, you could always keyword it ~arch." u: "But I can't use ~arch! It's unstable!" --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: making the firefox USE flag a global one
Simon Stelling wrote: > Hi all, > > I just noticed that the USE flag 'firefox' is a local one. I think it should > be > global, though: If this happens, could you also close https://bugs.gentoo.org/show_bug.cgi?id=96473 :) --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: GCC 4.1.1 testing/stablization and glibc 2.4
Ryan Hill wrote: > Just an update - I've finished most major desktop stuff for x86 without any > problems. I'm moving onto stuff that's already on the tracker and is fixed in > testing but not stable. Rather than open and track a ton of new bugs, I'd > like > to reopen the original ~arch bugs and request a backport or stabilization at > the > maintainer's discretion. I changed my mind. Reopening these just creates too much random bugspam. --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.
Paul de Vrieze wrote: > My argument is that we must not filter -ffast-math or any other dangerous > cflags. The reason being that people will request more filters for all > packages that don't work with it. Many users will either ignore or miss the > warning messages. Filtering the flag basically tells them that even though > the message says it is dangerous, their use of the flag is still more or less > supported, while it is not. Okay, I agree with this if it's considered acceptable to die during pkg_setup. I was under the impression it's not. >> Right, but how are people supposed to learn something is dangerous if all >> the sharp edges have been filed off? And how can you decide which flags >> are "bad" and "good" on a global level when for the most part compiler >> parameters are akin to black magic? > > In this case the compiler documentation itself says it is dangerous. That > should be enough. Agreed. Anything but global filtering. --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: GCC 4.1.1 testing/stablization and glibc 2.4
Chris Gianelloni wrote: > On Sat, 2006-07-01 at 12:18 -0600, Ryan Hill wrote: >> Should arch testers start working with 4.1.1 then? And do you want bugs to >> block #117482? > Arch testers should contact their architecture's leads or Release > Engineering Architecture Coordinator. As for bug reports, yes. Just an update - I've finished most major desktop stuff for x86 without any problems. I'm moving onto stuff that's already on the tracker and is fixed in testing but not stable. Rather than open and track a ton of new bugs, I'd like to reopen the original ~arch bugs and request a backport or stabilization at the maintainer's discretion. Is this okay, or would people rather get a shiny new bug? Keep in mind there are already 290 bugs on the tracker. Alternatively, would it be better to just start a new tracker bug for stabilization? https://bugs.gentoo.org/show_bug.cgi?id=117482 --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.
Ryan Hill wrote: > 2.95.3, 3.1.1, 3.2.2, 3.2.3, 3.3.2, 3.3.5, 3.3.6, 3.4.1, 3.4.4, 3.4.5, 3.4.6, My bad, 3.2.2 is masked for everyone ATM. --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.
Denis Dupeyron wrote: > Well yes, but an ebuild that dies, whatever the reason, hasn't much to > do with interactivity. Fine. Call it the don't-kill-the-emerge-for-silly-reasons philosophy if you like. I personally don't prefer it, but a lot of people think it's a good idea. > What will follow isn't only for you. You guys are focusing on the > die/filter alternative. Maybe you haven't noticed but I have never > stated that I'd prefer ebuilds to die or filter. What I wanted to > discuss is can't we do something globally to avoid these bugs coming > in, so that we can focus on something else. I don't care yet if it's > filtering or dying. And never did I talk about educating the masses. Well, your first two questions asked whether ebuilds should die rather than filter, and what other flags ebuilds should die on, so go figure that we're talking about filtering and dying. :o Is there a way to do this globally across X architectures and Y GCC versions with Z number of flags across 11191 packages? That's not even taking into account multiple flags and their influence on each other. Trying to find and filter every combination of the above is like trying to make a list of every single thing on earth you shouldn't stick up your nose. It doesn't work that way. You just say "hey, don't stick things up your nose. if you do, you live with the consequences". Once in a while someone decides not to listen and does something stupid. We all laugh at them, and go about our day. > I explained I was talking about a global system, with a possibility > for ebuilds/users that wanted/needed it to opt out. It's much easier > to "unblock" --fast-math for libao than going through idontknowhowmany > bugs about the same number of packages that break with --fast-math, > for example. You're missing my point. Flags that are harmful to some codebases are beneficial or even essential to others. This is my question to you: tell me how you're going decide what options are going to be blacklisted when all of them have a specific purpose and use, however corner-case that use could be. There are no "bad" and "good" flags. There are broken flags, of course. Every GCC release we get to guess which ones don't work right any more. ;) What it sounds like you're interested in is a whitelist. We already have strip-flags (see setup-allowed-flags in flag-o-matic.eclass). Turning that on globally however would incite rioting. I suppose a way to match flag and GCC version number against a list of known broken flags (ie. _not_ flags that can break things, but flags that are broken themselves. note the difference.) wouldn't be too bad. It's generally known that, say, -frename-registers is broken in 4.0 or -fnew-ra in 3.x just doesn't work. The number wouldn't be too high. Still, I don't know if it would be worth it. It's still much easier just to fix breakage if it happens, and INVALID anyone who files ricer bugs. > Let's count together the number of GCC versions we should really care > about. 3.4, 4.1, any others ? 2.95.3, 3.1.1, 3.2.2, 3.2.3, 3.3.2, 3.3.5, 3.3.6, 3.4.1, 3.4.4, 3.4.5, 3.4.6, 4.0.2, 4.1.0, 4.1.1, 4.2, 4.3, 4.x, 5.x, and etc. You wouldn't propose a short-term solution that doesn't include all compilers supported by Gentoo, would you? ;) Yes, minor bumps have changed flag behaviour in the past. >> Mad props to the bug-wranglers, but I don't think it'll be a cakewalk to >> automate this in any sane way. > > Automate what ? Whatever this vague global mechanism you're talking about that's supposed to end CFLAG bugs, save us so much time, and prevent users from ever doing stupid things. I mean, if it wasn't automagickal, how would it be any different than what we're doing now? > Since when is being a learning tool one of the goals of Gentoo ? ... I can't reply to this without being rude, so I'll leave it alone. --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.
Denis Dupeyron wrote: > Correct me if I'm wrong, but this has nothing to do with being > interactive or not. To me, an ebuild that dies (intentionally or due > to a build error) isn't interactive at all. Their phrase, not mine. ;) I think the idea is you should be able to emerge -e world and walk away and not have anything interrupt the process thus requiring the user interact with the system. I'm personally for dying as soon as possible, like before the actual compiling starts, but I don't think that's possible yet. > If a package is known not to work with a certain flag, being able to > emerge it won't change the fact that it doesn't run. If a package is known to not work with a certain flag it should be filtered so it does run. > Plus, if the > solution is considered good for python, I don't understand why it > wouldn't be good for any other package. Are you saying that Paul's > proposition of having the python ebuild die on use of --fast-math > isn't good ? Yes. If yes, why ? And what is your better idea ? I prefer a filter-flags with a ewarn (or elog, haven't read that thread yet ;)) message. * The -ffast-math option is known to break this package and has been filtered from your CFLAGS. Link to Safe CFLAGS wiki page, blah blah blah. I like this better because it informs me of what I did wrong, what was done to correct it, and how I can correct it for myself in the future if I choose to. I don't like artificial barriers and things not working without immediate attention. Call me lazy but it's annoying when you know what you're doing yet you have to jump through hoops to get it done. > Which is exactly the reason why we could benefit of something that > enables us to manage this in a clean and safe way. I'm not saying I > have a candidate for that "something", but I wanted to discuss if > there was an interest in it. > > Let's take again the example of -ftracer which can be enabled by the > -fprofile-use meta-flag. Imagine we have a mechanism somewhere (again, > the reason I'm being vague is that my point isn't to discuss > implementation just yet) that adds -fno-tracer to CFLAGS. In this > case, you're covered wether -ftracer was added directly on indirectly > by fprofile-use, which actually simplifies the number of flags that > you need to blacklist. Thus ebuilds don't have to take care of it, > bugs don't pour into bugzie, and Jakub can avoid overheating. Do you mean for ebuilds that knowingly break with -ftracer, or for everything? There are packages that expect to be built with certain flags; not -ftracer, but others. Fex, libao needs -ffast-math ;). Also, what about ebuilds that do use -fprofile, like gcc itself? I know toolchain.eclass strips all flags, I'm just using it as an example. If you mean just for packages that break with certain flags then absolutely. But such a mechanism would have to be maintained for every different GCC version, since -fprofile might not invoke -ftracer in every version, and indeed some versions might not even recognize -fno-tracer and bail with an error. >> Users playing with CFLAGS get to keep the pieces. Trying to >> dummy-proof the >> system doesn't help anyone but the dummies. ;) > > I'm one of those devs who care for our users. I think it's dangerous > to try and categorize users in, for example, dummies and non-dummies, > as you say. Who are we to judge this or that user is a dummy ? Plus, > we all are the dummy of somebody else. Okay, bad joke aside, there are always going to be users who tweak GCC flags. This has to be expected, as they're mysterious, and technical, and kinda cool. I like the tweaker crowd and I am a dummy, so no offense was intended to either groups. I meant that if you safety-proof a complex system, people never learn that they're doing anything wrong in the first place. > Anyway, I was thinking more in terms of making the job of developers, > bug wranglers, and poor old bugzilla easier, cleaner, safer. How many > bugs do we have that are due to dangerous flags ? Mad props to the bug-wranglers, but I don't think it'll be a cakewalk to automate this in any sane way. > How much time and > effort could we save if we didn't have those ? Also, I was thinking > that if a good solution was found to deal with a dangerous flag in a > certain package, maybe it was a good idea to extend this solution to > other packages. And finally, if said solution becomes common, maybe > it's a good idea to make it system-wide with a possibility to override > the setting by the user or the ebuild. It seems we already have > per-package CFLAGS, so part of this, at least, is already implemented. Right, but how are people supposed to learn something is dangerous if all the sharp edges have been filed off? And how can you decide which flags are "bad" and "good" on a global level when for the most part compiler parameters are akin to black magic? I guess in the end it comes down to personal philosophies on how to handle this, and I'm
[gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.
Denis Dupeyron wrote: > In bug #139412, I ask Paul de Vriese why he thinks python should die > on --fast-math instead of just filtering it. Here's his answer : > > "Denis, quite simple. -ffast-math is broken and short-sighted for a > global flag. > Filtering gives the shortsighted message that it works globally, while > it is > not suited for any package not specifically tested for it. As it breaks > python, > dieing makes people understand that it does not work on python. It is > better > than the alternative of not looking for it at all." Ebuilds shouldn't die on anything according to the non-interactive portage philosophy. I don't know how official that philosophy is though. > This, for me, triggers 3 questions that are gentoo-dev@ material : > > 1) Should all ebuilds that currently filter --fast-math die on its > presence instead of filtering it ? No, that would be a major pain in the ass for anyone wanting to use -fast-math, which does have legitimate uses. > 2) If yes, are there any other flags that ebuilds should die on ? There's a million, and they're constantly changing. For example, -frename-registers is generally safe on GCC 3.4, broken in 4.0, and enabled by default on 4.1. > 3) Suppose that -ftracer, for example, is one of those, and knowing > that enabling -fprofile-use enables -ftracer, shouldn't ebuilds also > die on use of -fprofile-use ? It's only an example, this situation > will exist for other pairs of flags. > > The hidden question behind these three is : shouldn't we have a > "something" that enables us to safely handle this kind of situations ? > Like some kind of system- and/or architecture-wide flag mask that > could be overriden by the ebuild and/or the user (at his own risk) ? > This could potentialy reduce the number of bugs that poor old bugzie > has to cope with, and simplify ebuild writing and maintenance. Users playing with CFLAGS get to keep the pieces. Trying to dummy-proof the system doesn't help anyone but the dummies. ;) --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: GCC 4.1.1 testing/stablization and glibc 2.4
Chris Gianelloni wrote: > OK, guys, I was speaking with vapier earlier about the possibility of > getting gcc 4.1.1 stable for the 2006.1 release. We've managed to build > some release media with it, and are planning on doing more testing with > it. What we really need is for more people to test this on various > platforms and to get all of the bugs worked out that we can. We're > already ramping up our release cycle, and would like to get this > included, so we don't have to wait until 2007 for a release with >= GCC > 4.1 in it. Should arch testers start working with 4.1.1 then? And do you want bugs to block #117482? --de. https://bugs.gentoo.org/show_bug.cgi?id=117482 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: gentoo-dev-announce list
Donnie Berkholz wrote: > My options are either missing important announcements or creating this > list. I would prefer the list. What important announcements are you expecting to find at the bottom 50-100 posts of random relevance? The announcements are at the top, being the thing that triggered the discussion. :P Any conclusions that are accidentally stumbled over during this process are (at least they should be) posted as a new thread, so the fun can begin again. --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [RFC] Useflags: qt, qt3, qt4?
Harald van Dijk wrote: > On Wed, Jun 21, 2006 at 05:20:47PM +0200, Carsten Lohrke wrote: >> On Wednesday 21 June 2006 15:44, Stefan Schweizer wrote: >>> qt3 - enable optional qt3 support >>> qt4 - enable optional qt4 support >> That will be a mess to support in the long run. > > Why? Ditto. Can anyone explain why this is bad? I simply don't want QT 4 on my system at this time. Just like I don't want GTK+-1 on my system. Already I've had to start adding packages to package.use with -qt to avoid pulling in qt4 (right next to all my -gtk entries). I don't see how it helps anyone to have a single 'qt' flag that changes meanings depending on the package it's used with. Dan Meltzer wrote: > When do you propose qt4 hits make.defaults? When kde4 hits p.mask, > when it hits ~arch, or when it hits arch? When it hits arch I guess. KDE itself won't be affected by the flag since it's not an optional dependency, and anyone building packages with optional KDE support should be using the kde flag, not qt, so I don't really see how this is relevant. But anyone building packages with optional KDE support will be expecting them to work with the latest stable version. --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Masking perl-core/ExtUtils-MakeMaker, eventual removal
Michael Cummings wrote: > OK, I attempted this in November of 05 (then forgot?), but since no one > responded to my last round, it has been removed. Happy gentoo'ing, *yay* --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: June Council meeting summary + log
Mike Frysinger wrote: > unadulterated log of the meeting will be synced out to the servers in a bit: > http://www.gentoo.org/proj/en/council/meeting-logs/20060616.txt I got http://www.gentoo.org/proj/en/council/meeting-logs/20060615.txt Also the council project page links to 20060620.txt (?). --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Project Sunrise -- Proposal
Marius Mauch wrote: > Functional changes, bugfixes, etc. Let people use common sense there. > The intention is simply that people watching the bug don't have to track > the overlay as well to get notifications of important changes (like a > bugfix that prevented them from using the ebuild previously). > Certainly you wouldn't consider whitespace changes or coding style > updates as an *important*, would you? Could this be automated through a post-commit hook in SVN? I'm thinking of something like the GCC bugzilla, which adds a comment to the relevant bug whenever a checkin is made. eg. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27601 --de. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Project Sunrise -- Proposal
Markus Ullmann wrote: > Okay, so after figuring out open problems (thanks to kloeri and various > other people for help here), we now have a resolution that should > satisfy all involved parties here. This should adress dostrow's demands > as well. Nice, I think this is a great improvement. > 2. People who contribute good ebuilds over a certain period of time are > allowed upon decision by project devs to actively help maintaining the > project. They'll be given commit rights for the project then. Same frome > above applies here: If we notice any abuse, we revoke access immediately. Would they be considered Gentoo staff, with everything that involves (quiz, etc)? > 7) tag on bugs > > All ebuilds that are made available on sunrise get an InOverlay KEYWORDS > entry on bugs.g.o so that everyone, who looks at the bug, knows about it. Would it also be useful to also have a keyword to indicate that the Sunrise ebuild has reached the point where it could be migrated to the gentoo repo if a maintainer for it steps up? I'm thinking that would make it easy to get a list of all m-w ebuilds that are ready for the tree. Maybe a page listing these packages would also be a good idea. --de. signature.asc Description: OpenPGP digital signature
