Re: HEADS UP: Merge of binutils 2.17
On 2011-02-16 21:00, Dimitry Andric wrote: So I plan to merge the binutils-2.17 project branch to head this weekend, if there are no further objections. If you have found a showstopper bug, please let me know ASAP. :) Okay, binutils 2.17.50 has now been merged to head in r218822. If you compile kernels by hand, make sure to first run make buildworld, or at least make kernel-toolchain, to get a new ld in /usr/obj. Otherwise, linking your kernel might fail. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Merge of binutils 2.17
On 2011-02-19 15:35, Dimitry Andric wrote: Okay, binutils 2.17.50 has now been merged to head in r218822. If you compile kernels by hand, make sure to first run make buildworld, or at least make kernel-toolchain, to get a new ld in /usr/obj. Otherwise, linking your kernel might fail. Note, this also applies when you want to build a -CURRENT kernel on -STABLE. In this case, you must run a make buildworld, or minimally make kernel-toolchain, before running make buildkernel or make kernel. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Merge of binutils 2.17
On 2011-01-07 21:57, Dimitry Andric wrote: For some time, I have been working on importing a newer version of binutils into -current. This updates our quite ancient 2.15 version to the last version available under GPLv2, 2.17.50. The binutils 2.17 project branch has been cooking for quite some time, and it now seems ready for merging into head. Thanks to Erwin Lansing, who performed multiple exp-runs, a few remaining issues with ports have been fixed (or will be fixed very soon). So I plan to merge the binutils-2.17 project branch to head this weekend, if there are no further objections. If you have found a showstopper bug, please let me know ASAP. :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Merge of binutils 2.17
On Fri, Jan 07, 2011 at 09:57:47PM +0100, Dimitry Andric wrote: Hi all, This is slightly OT. I get this error on ia64 which seems to be binutils related (still 2.15). I just thought if it is, then it might have an effect on 2.17 as well. The error seems to be ia64 specific. On amd64 and sparc64 I don't get it. Installing print/teTeX-base on ia64 gives this: *snip* install -o root -g wheel -m 444 ./mktex.opt /usr/local/share/texmf/web2c/mktex.opt install -o root -g wheel -m 555 ./mktexdir /usr/local/share/texmf/web2c/mktexdir install -o root -g wheel -m 444 ./mktexdir.opt /usr/local/share/texmf/web2c/mktexdir.opt install -o root -g wheel -m 555 ./mktexnam /usr/local/share/texmf/web2c/mktexnam install -o root -g wheel -m 444 ./mktexnam.opt /usr/local/share/texmf/web2c/mktexnam.opt install -o root -g wheel -m 555 ./mktexupd /usr/local/share/texmf/web2c/mktexupd /bin/sh ../libtool --mode=install install -o root -g wheel -m 444 .libs/libkpathsea.a /usr/local/lib install -o root -g wheel -m 444 .libs/libkpathsea.a /usr/local/lib/libkpathsea.a ranlib /usr/local/lib/libkpathsea.a chmod 644 /usr/local/lib/libkpathsea.a /bin/sh ../libtool --mode=install install -s -o root -g wheel -m 555 kpsewhich /usr/local/bin install -o root -g wheel -m 555 -s kpsewhich /usr/local/bin/kpsewhich install -s -o root -g wheel -m 555 kpsestat /usr/local/bin BFD: /usr/local/bin/stmBQcoa: The first section in the PT_DYNAMIC segment is not the .dynamic section strip:/usr/local/bin/stmBQcoa[.interp]: Bad value BFD: /usr/local/bin/stmBQcoa: The first section in the PT_DYNAMIC segment is not the .dynamic section strip:/usr/local/bin/stmBQcoa: Bad value install: wait: No such file or directory gmake[2]: *** [install-exec] Error 70 gmake[2]: Leaving directory `/usr/ports/print/teTeX-base/work/tetex-src-3.0/texk/kpathsea' gmake[1]: *** [install] Error 1 gmake[1]: Leaving directory `/usr/ports/print/teTeX-base/work/tetex-src-3.0/texk' gmake: *** [install] Error 1 *** Error code 2 Stop in /usr/ports/print/teTeX-base. many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Merge of binutils 2.17
Erik Cederstrand píše v ne 09. 01. 2011 v 00:10 +0100: I was pretty sure I couldn't improve anything with 5 minutes of thinking. I'm glad the most obvious things have already been done, and I'm sure you and others have put a lot of effort into this. My question was more what, if anything, can be done to speed up the cluster. Performance and numbers of build nodes is okay. What we really need here is faster, more robust scheduling infrastructure (master node software), linimon@ is working hard on this task. Also, how long does it take to complete an exp-run on the cluster? If everything goes smoothly, 20 hours wall time. -- -- Pav Lucistnik p...@oook.cz p...@freebsd.org Do not meddle in the fashions of wizards, for they are seasonal and quick to fall out of style! signature.asc Description: This is a digitally signed message part
Re: HEADS UP: Merge of binutils 2.17
On 2011-01-07 22:54, Ade Lovett wrote: Most likely it's low priority given all the other exp-runs that affect 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and a bunch of other infrastructure stuff. Not to mention the impending 7- and 8- RELEASEs. I understand, and there will probably also be shortage of people with time during the holiday season. I'm fine with holding this off for as long as it takes to make it work for everybody. It would be nice to get it in well before 9.0 slowly starts going into freeze mode, though. Then of course there's the issue (which is certainly getting better) of finding a point in time along the -CURRENT path where the tree is stable (sic) enough to get through a full ports run (which is one of the bigger internal stress tests we have of the system). Yes, unfortunately there are some stability problems in vanilla -current as of late, especially with long multiprocess builds, such as universes or bulk packaging with -j nnn. Sometimes it panics. :( IMO, the best approach would be to make sure it does the right thing with 'make universe' (twice, naturally, the second time being when all traces of the previous binutils has been purged from the building system). Since the beginning of the binutils 2.17 project branch, I have built universes many times with it, and as far as I know, all problems with the base system have been solved, on all arches. Once that's done, commit (please bump __FreeBSD_version as part of this, in case ports OSVERSION hacks are eventually needed), and then give the exp-run a whirl -- with all of the above, this should be nicely after 7.4/8.2 I would rather see exp-run results before committing this. :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Merge of binutils 2.17
On 2011-01-08 01:54, Anonymous wrote: Looks like lang/sbcl doesn't like new ld(1), here on amd64. Same error when building using devel/binutils. Can you reproduce? ... //doing warm init - compilation phase This is SBCL 1.0.43, an implementation of ANSI Common Lisp. More information about SBCL is available athttp://www.sbcl.org/. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. Bus error Yes, it gives a bus error here too, at least on amd64. I found a similar thread about such an issue with sbcl, started by you in March 2009: http://lists.freebsd.org/pipermail/freebsd-current/2009-March/004690.html It looks like in this case, the same problem happens, it eats large amounts of memory, and then dies (this is on a box with 4G RAM and a few G of swap): PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 33512 dim 1 1110 8244M 3055M CPU11 0:54 68.99% sbcl Obviously, when it tries to actually access stuff that is above the total virtual memory of the box, it will die. In any case, the workaround in that previous thread (setting the sysctl machdep.prot_fault_translation=2) works for me, at least to let the port build to completion, and install succesfully. Now, in the previous report, it seems there was something going on with .note.ABI-tag sections, which needed a kernel fix. And since Kostik is now introducing new .note sections, for the non-executable stack feature, it may be that I just hit a window where it is not entirely complete? The last sync of binutils-2.17 with head was at r217118, just after the introduction of those .note sections, but before several related changes in the kernel and other areas. I will sync the binutils-2.17 branch again, and see if that helps the port to build without setting the workaround sysctl. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Merge of binutils 2.17
Hello Pav, Den 08/01/2011 kl. 20.34 skrev Pav Lucistnik: Package cluster is quite clever, akshully, and since this is OT here, just terse comments Sorry, replied to a bad message... redirecting to current@ 1. adding SSD disks irrelevant because of bullet 2. 2. source and destination directories on md devices already done, swap backed md devices are used 3. huge ccache cache 4. dist-cc these tend to have their own issues 5. some heuristics on which ports could be skipped because dependencies haven't changed since last run this is also already done, we call it incremental builds 6. tuning the host system for this specific task empty words I was pretty sure I couldn't improve anything with 5 minutes of thinking. I'm glad the most obvious things have already been done, and I'm sure you and others have put a lot of effort into this. My question was more what, if anything, can be done to speed up the cluster. Also, how long does it take to complete an exp-run on the cluster? Thanks, Erik
Re: HEADS UP: Merge of binutils 2.17
On Jan 8, 2011, at 3:10 PM, Erik Cederstrand wrote: Hello Pav, Den 08/01/2011 kl. 20.34 skrev Pav Lucistnik: Package cluster is quite clever, akshully, and since this is OT here, just terse comments Sorry, replied to a bad message... redirecting to current@ 1. adding SSD disks irrelevant because of bullet 2. 2. source and destination directories on md devices already done, swap backed md devices are used 3. huge ccache cache 4. dist-cc these tend to have their own issues 5. some heuristics on which ports could be skipped because dependencies haven't changed since last run this is also already done, we call it incremental builds 6. tuning the host system for this specific task empty words I was pretty sure I couldn't improve anything with 5 minutes of thinking. I'm glad the most obvious things have already been done, and I'm sure you and others have put a lot of effort into this. My question was more what, if anything, can be done to speed up the cluster. Also, how long does it take to complete an exp-run on the cluster? Erik, As I said before, the tinderbox / exp-run infrastructure needs to be made portable, the infrastructure needs to be there, and as extra credit (I've stated this in other emails in the past) parallelization in ports/pkg_install needs to be fixed as ports/packaging in FreeBSD doesn't work in an ACID[1]-like manner. I'd rather not repeat the reasons in greater detail. Please look for my replies to this thread on current@ for more details in part A, and look for my replies on ports@ for more details in part B. Thanks, -Garrett 1. http://en.wikipedia.org/wiki/ACID___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Merge of binutils 2.17
On Fri, Jan 7, 2011 at 3:57 PM, Dimitry Andric d...@freebsd.org wrote: Hi all, For some time, I have been working on importing a newer version of binutils into -current. This updates our quite ancient 2.15 version to the last version available under GPLv2, 2.17.50. (Special thanks to Nathan Whitehorn for his valuable feedback.) As far as I know, all issues building and running the base system with this version of binutils have been solved, so I am planning to merge it into -current in approximately one week (e.g. Friday, 2011-01-14). If you want to test, please checkout the project branch: svn://svn.freebsd.org/base/projects/binutils-2.17 or apply the following diff to r217118 or later (warning: very large diff, might need handholding to apply successfully, and use -E while patching): http://www.andric.com/freebsd/binutils/binutils-2.17-r217118-1.diff.xz Then build world and kernel from the resulting source tree, and install them. There should be no directly visible changes, except for the newer version number reported by as(1), ld(1) and so on: 2.17.50 [FreeBSD] 2007-07-03 Please report any problems with either the base system, or ports that come up as a result of this binutils update. In the main directory http://svn.freebsd.org/base/projects/binutils-2.17/ all of the Text files are seen as Binary files by Firefox in Linux , then , instead of displaying them , it is starting a download dialog about a binary file . It is likely that , the others in sub directories are the same . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Merge of binutils 2.17
On 01/07/2011 12:57, Dimitry Andric wrote: Please report any problems with either the base system, or ports that come up as a result of this binutils update. This is much appreciated work of course, but I'm wondering if you've requested an experimental ports run with the change? It would be good to know how much damage to expect before the change gets committed. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Merge of binutils 2.17
On 2011-01-07 22:22, Doug Barton wrote: This is much appreciated work of course, but I'm wondering if you've requested an experimental ports run with the change? It would be good to know how much damage to expect before the change gets committed. Yes, I submitted an exp-run request Nov 15, 2010: http://www.freebsd.org/cgi/query-pr.cgi?pr=152268 Unfortunately, there has been little or no interest. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Merge of binutils 2.17
On 2011-01-07 22:21, Mehmet Erol Sanliturk wrote: http://svn.freebsd.org/base/projects/binutils-2.17/ all of the Text files are seen as Binary files by Firefox in Linux Try http://svn.freebsd.org/viewvc/base/projects/binutils-2.17/ instead. For checking out the source tree, please use a Subversion client, not a browser. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Merge of binutils 2.17
On 01/07/2011 13:29, Dimitry Andric wrote: On 2011-01-07 22:22, Doug Barton wrote: This is much appreciated work of course, but I'm wondering if you've requested an experimental ports run with the change? It would be good to know how much damage to expect before the change gets committed. Yes, I submitted an exp-run request Nov 15, 2010: http://www.freebsd.org/cgi/query-pr.cgi?pr=152268 Ah, well done then. :) Unfortunately, there has been little or no interest. Fair enough, that sounds to me like portmgr is volunteering to clean up the mess then. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Merge of binutils 2.17
On Jan 07, 2011, at 15:41 , Doug Barton wrote: On 01/07/2011 13:29, Dimitry Andric wrote: Yes, I submitted an exp-run request Nov 15, 2010: http://www.freebsd.org/cgi/query-pr.cgi?pr=152268 Unfortunately, there has been little or no interest. Fair enough, that sounds to me like portmgr is volunteering to clean up the mess then. Most likely it's low priority given all the other exp-runs that affect 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and a bunch of other infrastructure stuff. Not to mention the impending 7- and 8- RELEASEs. Then of course there's the issue (which is certainly getting better) of finding a point in time along the -CURRENT path where the tree is stable (sic) enough to get through a full ports run (which is one of the bigger internal stress tests we have of the system). IMO, the best approach would be to make sure it does the right thing with 'make universe' (twice, naturally, the second time being when all traces of the previous binutils has been purged from the building system). Once that's done, commit (please bump __FreeBSD_version as part of this, in case ports OSVERSION hacks are eventually needed), and then give the exp-run a whirl -- with all of the above, this should be nicely after 7.4/8.2 -aDe ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Merge of binutils 2.17
On 01/07/2011 13:54, Ade Lovett wrote: On Jan 07, 2011, at 15:41 , Doug Barton wrote: On 01/07/2011 13:29, Dimitry Andric wrote: Yes, I submitted an exp-run request Nov 15, 2010: http://www.freebsd.org/cgi/query-pr.cgi?pr=152268 Unfortunately, there has been little or no interest. Fair enough, that sounds to me like portmgr is volunteering to clean up the mess then. Most likely it's low priority given all the other exp-runs that affect 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and a bunch of other infrastructure stuff. Not to mention the impending 7- and 8- RELEASEs. That may very well be the case, but if so then it's incumbent on portmgr to communicate that. If you check the audit trail you will find that they did not. Then of course there's the issue (which is certainly getting better) of finding a point in time along the -CURRENT path where the tree is stable (sic) enough to get through a full ports run (which is one of the bigger internal stress tests we have of the system). IMO this is a total red herring, and has been for several years now. I run -current every day on my real-work system, and barring the occasional hiccup it's been buildable nearly every time I've tried. The way I would approach the problem of building packages for -current is to pick a day to update the src tree, then do the following: 1. make buildworld make kernel reboot 2. make installworld reboot 3. update ports tree 4. start building ports That can all be automated, and at the point where any of it fails the system barks loudly and stops trying to proceed. This would of course require a human to be involved once a week or so with running mergemaster, and maybe the odd cleanup here or there, but most times that doesn't even have to happen in band. I suggest Wednesday as the day to update the source since there is usually a lot of activity on the weekend, and if something is broken on Wednesday it gives people a chance to respond during working hours. The great thing about this is that if it fails, no harm no foul. Having some packages, even a week or so out of date is much better than what we have now. Of course, there are other things that would go along with this ... finding and tagging the very few packages that actually deeply care about system internals being first on the off the top of my head list. But the current system of don't do anything just isn't cutting it. IMO, the best approach would be to make sure it does the right thing with 'make universe' (twice, naturally, the second time being when all traces of the previous binutils has been purged from the building system). Once that's done, commit (please bump __FreeBSD_version as part of this, in case ports OSVERSION hacks are eventually needed), and then give the exp-run a whirl -- with all of the above, this should be nicely after 7.4/8.2 If portmgr is unwilling/unable to do the exp-run before dim is ready to commit, then I'd say yes, that all sounds fine; especially bumping __FreeBSD_version. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Merge of binutils 2.17
Dimitry Andric d...@freebsd.org writes:
[...]
Please report any problems with either the base system, or ports that
come up as a result of this binutils update.
Looks like lang/sbcl doesn't like new ld(1), here on amd64.
Same error when building using devel/binutils. Can you reproduce?
$ make
[...]
obj/from-xc/src/code/signal.lisp-obj
obj/from-xc/src/code/late-defbangmethod.lisp-obj
obj/from-xc/src/pcl/walk.lisp-obj
[building initial core file in output/cold-sbcl.core:
writing 8192 bytes [2 pages] from #SB!FASL::GSPACE :READ-ONLY
writing 4096 bytes [1 page] from #SB!FASL::GSPACE :STATIC
writing 44081152 bytes [10762 pages] from #SB!FASL::GSPACE :DYNAMIC
/(DESCRIPTOR-BITS INITIAL-FUN)=#X100288BA79
done]
* //testing for consistency of first and second GENESIS passes
//header files match between first and second GENESIS -- good
158.30 real 145.93 user 9.10 sys
//entering make-target-2.sh
//doing warm init - compilation phase
This is SBCL 1.0.43, an implementation of ANSI Common Lisp.
More information about SBCL is available at http://www.sbcl.org/.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
Bus error
0.20 real 0.07 user 0.13 sys
*** Error code 138
$ env -i gdb --args ./src/runtime/sbcl --core output/cold-sbcl.core
[...]
Program received signal SIGUSR1, User defined signal 1.
0x000801f843bc in kill () at kill.S:3
3 RSYSCALL(kill)
Current language: auto; currently asm
(gdb) bt
#0 0x000801f843bc in kill () at kill.S:3
#1 0x00411d47 in see_if_sigaction_nodefer_works () at
interrupt.c:1691
#2 0x0041216d in interrupt_init () at interrupt.c:1828
#3 0x004156e4 in main (argc=3, argv=0x7fff3f88,
envp=0x7fff3fa8) at runtime.c:316
(gdb) bt f
#0 0x000801f843bc in kill () at kill.S:3
No locals.
#1 0x00411d47 in see_if_sigaction_nodefer_works () at
interrupt.c:1691
sa = {
__sigaction_u = {
__sa_handler = 0x411c30 sigaction_nodefer_test_handler,
__sa_sigaction = 0x411c30 sigaction_nodefer_test_handler
},
sa_flags = 80,
sa_mask = {
__bits = {536870944, 0, 0, 0}
}
}
old_sa = {
__sigaction_u = {
__sa_handler = 0,
__sa_sigaction = 0
},
sa_flags = 2,
sa_mask = {
__bits = {0, 0, 0, 0}
}
}
#2 0x0041216d in interrupt_init () at interrupt.c:1828
i = 0
#3 0x004156e4 in main (argc=3, argv=0x7fff3f88,
envp=0x7fff3fa8) at runtime.c:316
core = 0x0
sbcl_argv = (char **) 0x0
embedded_core_offset = 0
runtime_path = 0x0
noinform = 0
end_runtime_options = 0
disable_lossage_handler_p = 0
initial_function = 140737488306056
sbcl_home = 0x0
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Merge of binutils 2.17
On Jan 07, 2011, at 17:37 , Doug Barton wrote: On 01/07/2011 13:54, Ade Lovett wrote: Most likely it's low priority given all the other exp-runs that affect 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and a bunch of other infrastructure stuff. Not to mention the impending 7- and 8- RELEASEs. Before I start on this, I would like a few things noted for the record: 1. I have set Reply-To to developers@ (this should be a major hint) 2. I am not a current member of portmgr@ 3. I requested, and served, for a very short time, on the first portmgr That may very well be the case, but if so then it's incumbent on portmgr to communicate that. If you check the audit trail you will find that they did not. Horsecrap. You are taking an individual PR history without reference to the whole host of things that were also going on at the same time. Like it or not, when it comes to ports, -STABLE wins over -CURRENT every single time. IMO this is a total red herring, and has been for several years now. I run -current every day on my real-work system, and barring the occasional hiccup it's been buildable nearly every time I've tried. Apologies for not being able to drive my email client appropriately. The issue at hand is one of running -CURRENT. There is a distinct, and fundamental difference between running -CURRENT on a single system, as opposed to a cluster of systems that are tightly interlinked. I do not doubt that -CURRENT works for you on your individual machines. If you would like a taste of how heavily package build clusters stress out whatever host system they are running on, then I urge you to install one of the two tinderbox ports under ports-mgmt, proceed to add, let's say, x11/gnome2 or x11/kde4, and run the build. make buildworld/buildkernel/installworld/installkernel plus associated steps is in fact an exceptionally tiny subset of what FreeBSD actually does on a daily basis. Even more so when it comes to the bulk building of packages that apparently a lot of folks rely on. The way I would approach the problem of building packages for -current is to pick a day to update the src tree, then do the following: Sadly, the only thing I can say to your 4-step procedure, and with utmost politeness, is that your src-centric views are completely missing the point. 4. start building ports is in fact a 20- or 30-step process to ensure no cross-contamination. Even a cursory glance at /usr/ports/Tools/portbuild would verify this. No-one really likes having massive clusters, requiring continual attention (hardware failures and so on). Really. But the current system of don't do anything just isn't cutting it. I look forward to your input and total solutions on how to make this better. I do. This may sound sarcastic, but I am absolutely, positively, 100-percent looking for better solutions, particularly in situations where, to take a random example, the entire existing compiler base is removed and replaced with something better. Doug, you have comprehensively shown that in its current (sic) instantiation, the package building cluster is completely, utterly, and totally incapable of keeping up with the sandbox that is -CURRENT. I for one look forward to your proposed solutions to this righteous problem. Regards, -aDe ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: Merge of binutils 2.17
On Jan 7, 2011, at 9:48 PM, Ade Lovett wrote: On Jan 07, 2011, at 17:37 , Doug Barton wrote: On 01/07/2011 13:54, Ade Lovett wrote: Most likely it's low priority given all the other exp-runs that affect 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and a bunch of other infrastructure stuff. Not to mention the impending 7- and 8- RELEASEs. Before I start on this, I would like a few things noted for the record: 1. I have set Reply-To to developers@ (this should be a major hint) 2. I am not a current member of portmgr@ 3. I requested, and served, for a very short time, on the first portmgr That may very well be the case, but if so then it's incumbent on portmgr to communicate that. If you check the audit trail you will find that they did not. Horsecrap. You are taking an individual PR history without reference to the whole host of things that were also going on at the same time. Like it or not, when it comes to ports, -STABLE wins over -CURRENT every single time. IMO this is a total red herring, and has been for several years now. I run -current every day on my real-work system, and barring the occasional hiccup it's been buildable nearly every time I've tried. Apologies for not being able to drive my email client appropriately. The issue at hand is one of running -CURRENT. There is a distinct, and fundamental difference between running -CURRENT on a single system, as opposed to a cluster of systems that are tightly interlinked. I do not doubt that -CURRENT works for you on your individual machines. If you would like a taste of how heavily package build clusters stress out whatever host system they are running on, then I urge you to install one of the two tinderbox ports under ports-mgmt, proceed to add, let's say, x11/gnome2 or x11/kde4, and run the build. make buildworld/buildkernel/installworld/installkernel plus associated steps is in fact an exceptionally tiny subset of what FreeBSD actually does on a daily basis. Even more so when it comes to the bulk building of packages that apparently a lot of folks rely on. The way I would approach the problem of building packages for -current is to pick a day to update the src tree, then do the following: Sadly, the only thing I can say to your 4-step procedure, and with utmost politeness, is that your src-centric views are completely missing the point. 4. start building ports is in fact a 20- or 30-step process to ensure no cross-contamination. Even a cursory glance at /usr/ports/Tools/portbuild would verify this. No-one really likes having massive clusters, requiring continual attention (hardware failures and so on). Really. But the current system of don't do anything just isn't cutting it. I look forward to your input and total solutions on how to make this better. I do. This may sound sarcastic, but I am absolutely, positively, 100-percent looking for better solutions, particularly in situations where, to take a random example, the entire existing compiler base is removed and replaced with something better. Doug, you have comprehensively shown that in its current (sic) instantiation, the package building cluster is completely, utterly, and totally incapable of keeping up with the sandbox that is -CURRENT. I for one look forward to your proposed solutions to this righteous problem. Hi Ade, Sorry to jump in, but I think that a lot of the solution to this problem is two part: 1. Using the VM resources at your.org . 2. Replicating pointyhat's infrastructure for mass deployment. Back at BSDCan 2010 your.org offered cycles and resources for tinderboxes (ports and src alike), but I think that due to lack of time / resources portmgr hasn't been able to invest in that solution (*slap me please if I'm incorrect :)..*). Not sure if the src development tinderbox infrastructure became a reality either. If developers had access to a [relatively] easy to deploy infrastructure and pointyhat was easy to replicate (that in and of itself is a major project that linimon@ was working on in the past year or so), then this would be less of a problem. Granted, the ports tree is huge, but by now dim@ could have probably finished off a few self-service exp-runs on his own if he could have done it on his own. Thanks, -Garrett___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Package building for -current (Was: Re: HEADS UP: Merge of binutils 2.17)
I'm happy to have a discussion about this topic either publicly, or privately, your choice. Since your message went to -current@, that's where my reply is headed. I've also cc'ed ports@ since the topic is relevant there too. Meanwhile, I've snipped some of what you wrote to focus on the issues that I think are most relevant. I value and respect both your opinion and your experience in these issues, but I have some rather profound disagreements with your conclusions. On 01/07/2011 21:48, Ade Lovett wrote: On Jan 07, 2011, at 17:37 , Doug Barton wrote: On 01/07/2011 13:54, Ade Lovett wrote: Most likely it's low priority given all the other exp-runs that affect 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and a bunch of other infrastructure stuff. Not to mention the impending 7- and 8- RELEASEs. Before I start on this, I would like a few things noted for the record: 1. I have set Reply-To to developers@ (this should be a major hint) 2. I am not a current member of portmgr@ 3. I requested, and served, for a very short time, on the first portmgr That may very well be the case, but if so then it's incumbent on portmgr to communicate that. If you check the audit trail you will find that they did not. Horsecrap. You are taking an individual PR history without reference to the whole host of things that were also going on at the same time. Like it or not, when it comes to ports, -STABLE wins over -CURRENT every single time. I disagree rather profoundly on this point. We have a tolerance/expectation of our leadership just plain not communicating with us that has gone way past unhealthy. It takes 30 seconds to respond to a PR and say We can't get to this before the pending releases, here is a suggested course of action. That's a perfectly reasonable thing for a person to expect in response to a request. In addition to not responding just being plain rude, it fosters the attitude of Why should I bother communicating with portmgr, they never respond anyway. Not to mention the fact that occasionally the fact that portmgr doesn't like to communicate can sometimes create actual problems, such as when they removed the MD5 checksum stuff without warning, and therefore broke all the ports management and other tools that depended on them. I was glad of the action to finish the change, but the action came after months of no communication about it at all. IMO this is a total red herring, and has been for several years now. I run -current every day on my real-work system, and barring the occasional hiccup it's been buildable nearly every time I've tried. Apologies for not being able to drive my email client appropriately. The issue at hand is one of running -CURRENT. There is a distinct, and fundamental difference between running -CURRENT on a single system, as opposed to a cluster of systems that are tightly interlinked. Believe it or not, I understand that. I also get that sometimes running package building on -current stresses it in ways that cause it to break. That's a good thing. :) My point is that YEARS of ignoring the problem is not acceptable, and needs to change. For a long time portmgr griped about not having enough systems for the build cluster. Now they have plenty of hardware available, but the problem is that the system is too pointy-hat centric. Apparently significant progress has been made in that area, but none of it seems to have trickled down to actually getting more packages built for more platforms better and faster. I do, honestly, get that this is a hard problem. But if portmgr needs help, it needs to ask for it. It asked for and received more hardware, so clearly the foundation and the FreeBSD community at large is ready to step up to help. I think it's pretty obvious at this point that the gating factor is person-hours, so portmgr needs to be a lot more aggressive in developing new volunteers, asking for help with specific tasks, etc. etc. The fact that they are dealing with hard problems is no longer an acceptable excuse for years of failure to solve them. Sadly, the only thing I can say to your 4-step procedure, and with utmost politeness, is that your src-centric views are completely missing the point. 4. start building ports is in fact a 20- or 30-step process to ensure no cross-contamination. Once again, I get that bit too. Since we do, in fact, already have a package building cluster I was handwaving it because I was trying to address your red herring about we can't find a version of -current we like so we can't even try. The essential points that I'm trying to communicate are: 1. Most of the time HEAD works pretty well nowadays 2. Very few ports care that deeply about the guts of the system they are running on I look forward to your input and total solutions on how to make this better. I do. See above. I would love it if the foundation wanted to fund me to spend the amount of time it would take to
