[gentoo-dev] Re: Quantity of open bugs
On Thu, 10 Mar 2011 20:25:10 + "Kevin F. Quinn" wrote: > I would guess these old untouched bugs aren't actually going to be > touched, ever - a lot simply won't be relevant any more for one reason > or another. All they're doing is cluttering up bugzilla. I never understand this argument. How does an open bug "clutter" up bugzilla any more than a closed bug? It's pretty simple. If a bug isn't fixed, it should be open. Automatically closing them doesn't make things "better", it just generates shitloads of useless mail. -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: Bugzilla - New Default Status Workflow
On Fri, 11 Mar 2011 04:52:19 +0100 Jeroen Roovers wrote: > On Thu, 10 Mar 2011 21:06:54 +0100 > Amadeusz Żołnowski wrote: > > > > Status = NEW && Assignee = bug-wranglers -> Status = UNCONFIRMED > > > Status = NEW && Assignee = [maintainer] -> Status = CONFIRMED > > > > Who confirms the bug? I would expect that CONFIRMED is set by the > > package maintainer and the one who assigns bugs leaves the status. > > I was referring to existing bug reports, not new ones. New ones should > come in as UNCONFIRMED and would be changed to CONFIRMED when assigned > - bug wrangling does have this element of validation, you know. > Apparently when maintainers accept the bug, it changes to IN PROGRESS, > and when [s]he doesn't it should be resolved as invalid or duplicate > or whatever, but heck, maybe the flow chart should speak for itself. Bug wranglers should only mark bugs CONFIRMED if they can personally reproduce them. If no one has produced the bug other than the original poster then that's the very definition of UNCONFIRMED. Or maybe you're thinking CONFIRMED as in "I confirm this is a bug report and not a lunch order"? -- fonts, gcc-porting, it makes no sense how it makes no sense toolchain, wxwidgets but i'll take it free anytime @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On Thu, 10 Mar 2011 21:06:54 +0100 Amadeusz Żołnowski wrote: > > Status = NEW && Assignee = bug-wranglers -> Status = UNCONFIRMED > > Status = NEW && Assignee = [maintainer] -> Status = CONFIRMED > > Who confirms the bug? I would expect that CONFIRMED is set by the > package maintainer and the one who assigns bugs leaves the status. I was referring to existing bug reports, not new ones. New ones should come in as UNCONFIRMED and would be changed to CONFIRMED when assigned - bug wrangling does have this element of validation, you know. Apparently when maintainers accept the bug, it changes to IN PROGRESS, and when [s]he doesn't it should be resolved as invalid or duplicate or whatever, but heck, maybe the flow chart should speak for itself. Here is the URL again: http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html jer
Re: [gentoo-dev] Quantity of open bugs
On 03/10/2011 02:25 PM, Kevin F. Quinn wrote: Hi all, I was nosing through bugzilla, and noticed: * Number of open bugs is greater than 14,000 * Number of open bugs untouched for more than 2 years - well over 2000. * Number of open bugs untouched between 1 and 2 years - well over 2000. * Number of open bugs untouched between 6 months and 1 year - well over 2000. * Number of open bugs untouched between 3 months and 6 months - over 2000 The winner is bug #78406, which hasn't been touched for over 2240 days - over 6 years - at the time of writing. I would guess these old untouched bugs aren't actually going to be touched, ever - a lot simply won't be relevant any more for one reason or another. All they're doing is cluttering up bugzilla. I think Duncan has already covered the major points I was going to mention: particularly with respect to the fact that we are all volunteers and thus subject to resource constraints that other projects might not have. I realize that it is frustrating to a user to have a bug sit for a year (or more) without ever being resolved (or even looked at), but there is really only one way to resolve that: get someone who has the time and expertise to step in and fill the gap. Given that we can't exactly hold a gun to people's heads and MAKE them work on Gentoo stuff (nor would I personally be inclined to trust code produced using such methods), I really don't see another alternative. We closed a number of bugs related to SELinux recently; many of those bugs had been open for quite some time and things had changed sufficiently that we believed that the bug itself was no longer relevant, or we needed feedback from the user and didn't get any. Some of those bugs had been open for a couple of years. But we reviewed EACH of those bugs and made a decision on a case-by-case basis. I understand and appreciate the desire to close open bugs that are cluttering up the bugzilla. Not only do they create extra cruft for everyone to wade through, they also make Gentoo look bad (my GOD, they've got open bugs dating back to the founding of the Roman Empire!). However, I'm not convinced that blanket closing bugs that are over x days (weeks, months, years) is the best (or even desirable) approach. If a bug is related to a package that no longer exists, then it seems pretty obvious that there is no need to keep the bug around. If the bug is waiting on feedback from a user, and that user hasn't provided the requested feedback in, say, 60 days (after a bump to the bug) then I'd say that the bug is arguably no longer of importance to the user, or at least the email address we have on file for that user doesn't work any more. Beyond those two conditions, I'd really be loathe to close anything without good evidence to indicate that it either is no longer relevant, or it can't be fixed. Just my $0.02 (not adjusted for currency devaluation) Later, Gizmo
[gentoo-dev] Re: Quantity of open bugs
Kevin F. Quinn posted on Thu, 10 Mar 2011 20:25:10 + as excerpted: > Hi all, > > I was nosing through bugzilla, and noticed: > > * Number of open bugs is greater than 14,000 > * open bugs untouched > 2 years - well over 2000. > * open bugs untouched 1 - 2 years - well over 2000. > * open bugs untouched 6 mo to 1 year - well over 2000. > * open bugs untouched 3 - 6 months - over 2000 > > The winner is bug #78406, which hasn't been touched for over 2240 days - > over 6 years - at the time of writing. > > I would guess these old untouched bugs aren't actually going to be > touched, ever - a lot simply won't be relevant any more for one reason > or another. All they're doing is cluttering up bugzilla. > > > So I'd like to suggest a drastic, perhaps controversial action. Mark > all bugs that haven't been touched for over (say) 3 months as > "Resolved:Wontfix", with a polite comment saying that it is closed due > to lack of resource amongst the volunteer developer community. You have a point, but for the way Gentoo works, 3 months is rather too short. Gentoo tracks all sorts of not-ordinarily-considered-bugs as bugs, and some of the stuff tracked is long-term projects. I've had (gentoo initscript feature) bugs complete with patches sit for > six months, before the Gentoo package maintainer had time to look at it and say yeah, the idea looks good. Another user ended up updating the patch before it was applied, as stuff /had/ changed, but it /was/ eventually applied. Meanwhile, both the other user and I (and who knows if anyone else) had been using the feature in our own initscripts, keeping it working, etc, but the package didn't turn over /that/ frequently, and over a year to resolve with a six-month and a three-month idle period wasn't /that/ bad -- certainly considering that the patch and feature ultimately got in, and it wouldn't have with your proposal unless someone simply bumped the bug for no other reason than to keep it open. Arguably, a year might be better, or possibly six months, but certainly, the auto-close message should urge the user to re-open if it's still appropriate. But I'm not sure even that will go over well. Maybe two years or five years... because arguably at five years, no matter what the bug is, if it's still valid, it really /needs/ updated, since so much around it will have changed. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] updating GLEP 1
On Thursday, March 10, 2011 12:28:59 Patrick Börjesson wrote: > On 2011-03-09 19:11, Mike Frysinger wrote: > > +list. GLEPs are then reviewed at a Council meeting where it may be > > approved +or rejected outright, or send it back to the author(s) for > > revision. This > > Just a minor note; The sentence is written from the perspective of the > GLEP, so the last part should probably be ", or sent back to the > author(s) for revision". thanks. ive tweaked that and committed the result now. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Last rites: www-client/chromium-bin
On 3/10/11 9:33 PM, Mike Gilbert wrote: > Chromium tarballs are actually around 140 MB. It would be interesting > to see if we can trim that tarball down. Oh yes, we can. I guess the biggest problem is testing, but we can certainly remove more from the tarball. If anyone's interested, it's src/tools/export_tarball/export_tarball.py in the Chromium source tree. I can review patches. :-D Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Last rites: www-client/chromium-bin
On Thu, Mar 10, 2011 at 3:04 PM, James Cloos wrote: >> "PH" == Paweł Hajdan, writes: > > PH> That's the chromium-bin, really. The difference is that chromium has > PH> more deps and takes more time to compile than grub. Also, it has much > PH> more frequent releases, and almost every stable release is a security > PH> update. > > And every one of those chromium releases is another 200 Meg download. > > Or is that yet another? > > Still yet another? Chromium tarballs are actually around 140 MB. It would be interesting to see if we can trim that tarball down. For comparison, Firefox weighs in at about 50 MB.
[gentoo-dev] Quantity of open bugs
Hi all, I was nosing through bugzilla, and noticed: * Number of open bugs is greater than 14,000 * Number of open bugs untouched for more than 2 years - well over 2000. * Number of open bugs untouched between 1 and 2 years - well over 2000. * Number of open bugs untouched between 6 months and 1 year - well over 2000. * Number of open bugs untouched between 3 months and 6 months - over 2000 The winner is bug #78406, which hasn't been touched for over 2240 days - over 6 years - at the time of writing. I would guess these old untouched bugs aren't actually going to be touched, ever - a lot simply won't be relevant any more for one reason or another. All they're doing is cluttering up bugzilla. So I'd like to suggest a drastic, perhaps controversial action. Mark all bugs that haven't been touched for over (say) 3 months as "Resolved:Wontfix", with a polite comment saying that it is closed due to lack of resource amongst the volunteer developer community. I'm sure a suitable bugzilla script wiz could do that relatively easily. Users who care about such bugs can still comment on them, or talk directly to the assigned dev to highlight it's still a relevant issue to them, or even to supply a solution against the current tree. It could be an ongoing policy, in which case, users who care about them can keep bugs alive simply by posting useful updates to the bug, describing how the issue still applies to a new revision for example. Just a thought from an old ex-dev... Kev.
Re: [gentoo-dev] RFC: Making largefile a global use
On 03/10/2011 02:35 AM, Mike Frysinger wrote: i cant see much value anymore in even making this an option. just drop the USE flag and always use LFS. -mike +1
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
Excerpts from Jeroen Roovers's message of Thu Mar 10 20:42:29 +0100 2011: > For existing bugs, then, NEW bugs should be changed to UNCONFIRMED > when they are assigned to bug-wranglers, and to CONFIRMED when they > have already been assigned to their maintainers (irrespective of > whether they are actually confirmed or not or whether they are deemed > to be actual bugs). > > Status = NEW && Assignee = bug-wranglers -> Status = UNCONFIRMED > Status = NEW && Assignee = [maintainer] -> Status = CONFIRMED Who confirms the bug? I would expect that CONFIRMED is set by the package maintainer and the one who assigns bugs leaves the status. -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Last rites: www-client/chromium-bin
> "PH" == Paweł Hajdan, writes: PH> That's the chromium-bin, really. The difference is that chromium has PH> more deps and takes more time to compile than grub. Also, it has much PH> more frequent releases, and almost every stable release is a security PH> update. And every one of those chromium releases is another 200 Meg download. Or is that yet another? Still yet another? -JimC (who still prefers the src) -- James Cloos OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On Thu, 10 Mar 2011 11:04:19 -0500 Mike Gilbert wrote: > If we were to switch to the new workflow, it probably would make sense > to switch the default new bug status to UNCONFIRMED. I'm not sure how > we would handle the existing bugs in NEW status. I agree that new should now automatically be set to UNCONFIRMED when they are not assigned yet (i.e. have been automatically assigned to bug-wranglers) but to CONFIRMED when they are being assigned directly to their respective maintainers. For existing bugs, then, NEW bugs should be changed to UNCONFIRMED when they are assigned to bug-wranglers, and to CONFIRMED when they have already been assigned to their maintainers (irrespective of whether they are actually confirmed or not or whether they are deemed to be actual bugs). Status = NEW && Assignee = bug-wranglers -> Status = UNCONFIRMED Status = NEW && Assignee = [maintainer] -> Status = CONFIRMED > Here are the workflow diagrams for our old Bugzilla and the new one. I > find pictures are a bit easier to follow. Thanks, those really helped. (The only problem I have with the new workflow is that bugs assigned to bug-wranglers can usually be dealt with more quickly when it is obvious that new information has been added, which is the case when a bug has been closed as RESOLVED, NEEDINFO, after which reopening it will set it to REOPENED. If we're going to lose that, then the b-w assigned list loses some definition. But maybe bugzilla 4's support of the Changed column can help there.) jer
Re: [gentoo-dev] Re: RFC: Making largefile a global use
On Thu, 10 Mar 2011 10:56:31 +0100 justin wrote: > On 10/03/11 10:44, Diego Elio Pettenò wrote: > > Il giorno gio, 10/03/2011 alle 09.08 +0100, justin ha scritto: > >> > >> there are not many packages using it, but I will add this flag to > >> another 10. > > > > Why? > > just because upstream has this configure flag. but it seems we agree > on removing the flag completely, defaulting on largefile support and > fixing what needs a fix. > Correct? +1 on forcing it always on. gpgme already requires all packages linked against it to use same largefile switch value as it does, and maintaining the ability to switch it on/off just creates more trouble than profit. The only use case I see for the explicit switch possibility are the dependencies of -bin packages. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] updating GLEP 1
On 2011-03-09 19:11, Mike Frysinger wrote: > +list. GLEPs are then reviewed at a Council meeting where it may be approved > +or rejected outright, or send it back to the author(s) for revision. This Just a minor note; The sentence is written from the perspective of the GLEP, so the last part should probably be ", or sent back to the author(s) for revision".
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On Thu, Mar 10, 2011 at 6:15 AM, Markos Chandras wrote: > On Thu, Mar 10, 2011 at 12:10:14PM +0100, "Paweł Hajdan, Jr." wrote: >> On 3/7/11 11:13 AM, Brian Harring wrote: >> > Re-read what he stated- it'll convert all existing NEW bugs to >> > CONFIRMED upon migration. There's a fair number of bugs that are in a >> > NEW state, decent number that have sat for a long while too. Those >> > bugs aren't 'confirmed'- just like with the new work flow where the >> > dev flips it from UNCONFIRMED to CONFIRMED, leave it to devs to flip >> > the current bugs from UNCONFIRMED to CONFIRMED rather than just >> > marking everything as CONFIRMED. >> >> Maybe I'm misunderstanding something, but it seems we have both >> UNCONFIRMED and NEW in the "old" workflow. My understanding is that >> CONFIRMED is the new name for NEW, which makes sense. >> > Sorry but no. NEW means "Ok I think this is a bug. Can you please take a > look?". CONFIRMED is "ok this is definitely a bug. I am able to > reproduce etc and will look into fixing it". The meaning is slightly > different but it is important to distinguish valid from invalid bugs. > > > Regards, > -- > Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 > If we were to switch to the new workflow, it probably would make sense to switch the default new bug status to UNCONFIRMED. I'm not sure how we would handle the existing bugs in NEW status. Here are the workflow diagrams for our old Bugzilla and the new one. I find pictures are a bit easier to follow. Bugzilla 2.22: http://www.bugzilla.org/docs/2.22/html/lifecycle.html Bugzilla 4.0: http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html
Re: [gentoo-dev] release 11.0 and freshmeat.net
On Thu, Mar 10, 2011 at 8:52 AM, Anthony G. Basile wrote: > Hi, > > I noticed that release 11.0 was annouced on distrowatch.com, > sourcewell.berlios.de, and other places, but not on freshmeat.net. The > last release announced there is 10.0 back in Oct 7, 2009. dabbot is > listed, but he is on devaway until May. Is PR aware? > > BTW, I think the liveCD is very pretty :) > > -- > Anthony G. Basile, Ph.D. > Gentoo Developer > > > Hi Team, The release has been submitted for verification on freashmeat. This process typically takes less than 24 hours. Regards, David -- David Abbott (dabbott) Gentoo http://dev.gentoo.org/~dabbott/
[gentoo-dev] release 11.0 and freshmeat.net
Hi, I noticed that release 11.0 was annouced on distrowatch.com, sourcewell.berlios.de, and other places, but not on freshmeat.net. The last release announced there is 10.0 back in Oct 7, 2009. dabbot is listed, but he is on devaway until May. Is PR aware? BTW, I think the liveCD is very pretty :) -- Anthony G. Basile, Ph.D. Gentoo Developer
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On Thu, Mar 10, 2011 at 12:10:14PM +0100, "Paweł Hajdan, Jr." wrote: > On 3/7/11 11:13 AM, Brian Harring wrote: > > Re-read what he stated- it'll convert all existing NEW bugs to > > CONFIRMED upon migration. There's a fair number of bugs that are in a > > NEW state, decent number that have sat for a long while too. Those > > bugs aren't 'confirmed'- just like with the new work flow where the > > dev flips it from UNCONFIRMED to CONFIRMED, leave it to devs to flip > > the current bugs from UNCONFIRMED to CONFIRMED rather than just > > marking everything as CONFIRMED. > > Maybe I'm misunderstanding something, but it seems we have both > UNCONFIRMED and NEW in the "old" workflow. My understanding is that > CONFIRMED is the new name for NEW, which makes sense. > Sorry but no. NEW means "Ok I think this is a bug. Can you please take a look?". CONFIRMED is "ok this is definitely a bug. I am able to reproduce etc and will look into fixing it". The meaning is slightly different but it is important to distinguish valid from invalid bugs. Regards, -- Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 pgp8gp2xYOSAS.pgp Description: PGP signature
Re: [gentoo-dev] Re: Last rites: www-client/chromium-bin
On 3/5/11 11:05 AM, Duncan wrote: > What about handling chromium-bin the same way amd64 handles grub-static? > They create a standard binpkg of the normal grub ebuild (using > standardized USE flags, of course), using that as the source tarball for > the grub-static ebuild, which then simply ebuild-scripts the unpack and > install of the binpkg tarball. That's the chromium-bin, really. The difference is that chromium has more deps and takes more time to compile than grub. Also, it has much more frequent releases, and almost every stable release is a security update. > In theory, the ebuild could even grab and merge the appropriate binpkg > based on arch, allowing the ebuild to be keyworded for more archs than the > usual binary-only ebuild tends to be, altho I'm not sure that'd work in > practice as I'm unsure of the effects on the metadata cache and whether > that would be allowed or not. Yeah, I can understand how it could work technically. The only issue is to make the version bump one automated step. Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On 3/7/11 11:13 AM, Brian Harring wrote: > Re-read what he stated- it'll convert all existing NEW bugs to > CONFIRMED upon migration. There's a fair number of bugs that are in a > NEW state, decent number that have sat for a long while too. Those > bugs aren't 'confirmed'- just like with the new work flow where the > dev flips it from UNCONFIRMED to CONFIRMED, leave it to devs to flip > the current bugs from UNCONFIRMED to CONFIRMED rather than just > marking everything as CONFIRMED. Maybe I'm misunderstanding something, but it seems we have both UNCONFIRMED and NEW in the "old" workflow. My understanding is that CONFIRMED is the new name for NEW, which makes sense. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] unbreaking net-print/foo2zjs
On 3/7/11 1:05 PM, Hanno Böck wrote: > Am Sun, 27 Feb 2011 15:44:13 +0100 > schrieb "Paweł Hajdan, Jr." : > >> As the package seems rather unmaintained, I'm going to wait for a >> while and check in the ebuild if nobody is against that. >> >> Any feedback is welcome, please let me know what you think. > > I thought about splitting the stuff to make maintaining easier. One > ebuild for the driver itself, one for the color profiles and one for > the firmwares. Yeah, I was also thinking about that. However, I haven't analyzed the build system enough to know how to handle the files downloaded from the network separately. I think my plan for now is to check in something working, and try to improve it when I have another chunk of time. Of course anyone is free to hack on it too. Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Re: RFC: Making largefile a global use
Il giorno gio, 10/03/2011 alle 10.56 +0100, justin ha scritto: > > > just because upstream has this configure flag. but it seems we agree > on > removing the flag completely, defaulting on largefile support and > fixing > what needs a fix. > Correct? Correct. Any configure with AC_SYS_LARGEFILE will get a --enable-largefile option, but if you grep through the tree, this is usually simply added unconditionally. It is more interesting to see whether it actually supports LFS entirely; quite a few packages forget to include config.h in some file or other, and cause mixed LFS and non-LFS syscalls to be used, which is bad. I have written an utility as part of Ruby-Elf[1] called verify-lfs that is designed to check for that. Also note that largefile has no meaning on most 64-bit arches (AMD64 for sure, I guess the others as well). [1] http://www.flameeyes.eu/projects/ruby-elf -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: RFC: Making largefile a global use
On 10/03/11 10:44, Diego Elio Pettenò wrote: > Il giorno gio, 10/03/2011 alle 09.08 +0100, justin ha scritto: >> >> there are not many packages using it, but I will add this flag to >> another 10. > > Why? just because upstream has this configure flag. but it seems we agree on removing the flag completely, defaulting on largefile support and fixing what needs a fix. Correct? justin signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: RFC: Making largefile a global use
Il giorno gio, 10/03/2011 alle 09.08 +0100, justin ha scritto: > > there are not many packages using it, but I will add this flag to > another 10. Why? Please remember that largefile doesn't just mean files bigger than 4GiB, it enables more than just sizeof(off_t)==8, it is also required to access data on huge filesystems (that right now are not enabled to be generated by anything, but still). I don't think at all that largefile should be an option; if something has trouble working with largefile it should be fixed, not conditioned. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
Re: [gentoo-dev] RFC: Making largefile a global use
On Thu, Mar 10, 2011 at 2:12 PM, justin wrote: > euse -i largefile [snip] > [+ C ] largefile (dev-libs/eggdbus): > Support for large files > For the record: eggdbus was merged into glib itself as gdbus, and almost nothing needs it anymore. It'll be removed as soon as libgnome-keyring-2.32.0 and polkit-0.99-r1 become stable on all arches. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] RFC: Making largefile a global use
On Thursday, March 10, 2011 03:36:46 Amadeusz Żołnowski wrote: > Excerpts from justin's message of Thu Mar 10 09:08:24 +0100 2011: > > there are not many packages using it, but I will add this flag to > > another 10. > > And I think, it is of a general, global meaning. Do you agree in > > making it a global USE? > > I'm new here, but I think it would be good idea to list packages using > that flag with meaning described by its maintainers and your proposal. quse -D largefile -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Making largefile a global use
Mike Frysinger wrote: On Thursday, March 10, 2011 03:08:24 justin wrote: there are not many packages using it, but I will add this flag to another 10. And I think, it is of a general, global meaning. Do you agree in making it a global USE? i cant see much value anymore in even making this an option. just drop the USE flag and always use LFS. -mike Just a users opinion. I read about this on the wiki to be sure it was what I thought it was. Isn't this the default about everywhere else? I agree with Mike, why not just turn it on as a default setting? Dale :-) :-)
Re: [gentoo-dev] RFC: Making largefile a global use
On 10/03/11 09:36, Amadeusz Żołnowski wrote:
> Excerpts from justin's message of Thu Mar 10 09:08:24 +0100 2011:
>> there are not many packages using it, but I will add this flag to
>> another 10.
>> And I think, it is of a general, global meaning. Do you agree in
>> making it a global USE?
>
> I'm new here, but I think it would be good idea to list packages using
> that flag with meaning described by its maintainers and your proposal.
euse -i largefile
global use flags (searching: largefile)
no matching entries found
local use flags (searching: largefile)
[+ C ] largefile (app-text/dos2unix):
Support for large files
[+ C ] largefile (dev-libs/eggdbus):
Support for large files
[+ C ] largefile (net-misc/freerdp):
Support for large files
[+ C ] largefile (net-p2p/mktorrent):
Enable largefile support on 32 bit systems
[+ C ] largefile (sci-biology/emboss):
Support for large files
[+ C ] largefile (sci-biology/exonerate):
Enable largefile support on 32 bit systems
[+ C ] largefile (sci-geosciences/grass):
Enable LFS support for huge files
The sci packages and dos2unix are under my control.
Others are maintained by net-...@gentoo.org, hwoar...@gentoo.org,
volk...@gentoo.org & freedesktop-b...@gentoo.org.
And will add it or not to all sci-biology/{emboss,ambassy} packages.
But I would agree with Mike in defaulting to LFS.
justin
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Making largefile a global use
Excerpts from justin's message of Thu Mar 10 09:08:24 +0100 2011: > there are not many packages using it, but I will add this flag to > another 10. > And I think, it is of a general, global meaning. Do you agree in > making it a global USE? I'm new here, but I think it would be good idea to list packages using that flag with meaning described by its maintainers and your proposal. -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Making largefile a global use
On Thursday, March 10, 2011 03:08:24 justin wrote: > there are not many packages using it, but I will add this flag to > another 10. > And I think, it is of a general, global meaning. Do you agree in making > it a global USE? i cant see much value anymore in even making this an option. just drop the USE flag and always use LFS. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] RFC: Making largefile a global use
Hi, there are not many packages using it, but I will add this flag to another 10. And I think, it is of a general, global meaning. Do you agree in making it a global USE? justin signature.asc Description: OpenPGP digital signature
