Re: repo missing package
On Sat, 11 Jan 2020 at 21:38, Greg Troxel wrote: > > Manuel Bouyer writes: > > > On Sat, Jan 11, 2020 at 03:43:58PM +0100, Rhialto wrote: > >> On Fri 10 Jan 2020 at 10:25:13 -0500, Greg Troxel wrote: > >> > So maybe I've been lucky. Maybe it's MAKE_JOBS. Maybe it's something > >> > else we don't understand. > >> > >> On my machine, rust and firefox also "just built". I did get messages in > >> my xconsole windown about random though, but not only during these > >> builds it seems. > > > > I forced MAKE_JOBS=1 for rust on the build cluster, and rust did > > build on 8.0/i386 this time. A parallelism issue is coherent with the > > error message from the previous run (trying to access a non-existent file > > in the build directory) > > So I guess we have a proposal on the table that says: > > rust is broken for -jN > therefore we should set MAKE_JOBS_SAFE=no I used to run with higher -jN many months ago and occasionally hit rust build problems. Since I - by necessity, very hot laptop - switched to -j1, I don't think I've had a failure; a few days ago I built rust 1.40. > > any other data points? --
Re: repo missing package
Manuel Bouyer writes: > On Sat, Jan 11, 2020 at 03:43:58PM +0100, Rhialto wrote: >> On Fri 10 Jan 2020 at 10:25:13 -0500, Greg Troxel wrote: >> > So maybe I've been lucky. Maybe it's MAKE_JOBS. Maybe it's something >> > else we don't understand. >> >> On my machine, rust and firefox also "just built". I did get messages in >> my xconsole windown about random though, but not only during these >> builds it seems. > > I forced MAKE_JOBS=1 for rust on the build cluster, and rust did > build on 8.0/i386 this time. A parallelism issue is coherent with the > error message from the previous run (trying to access a non-existent file > in the build directory) So I guess we have a proposal on the table that says: rust is broken for -jN therefore we should set MAKE_JOBS_SAFE=no any other data points?
Re: repo missing package
On Sat, Jan 11, 2020 at 03:43:58PM +0100, Rhialto wrote: > On Fri 10 Jan 2020 at 10:25:13 -0500, Greg Troxel wrote: > > So maybe I've been lucky. Maybe it's MAKE_JOBS. Maybe it's something > > else we don't understand. > > On my machine, rust and firefox also "just built". I did get messages in > my xconsole windown about random though, but not only during these > builds it seems. I forced MAKE_JOBS=1 for rust on the build cluster, and rust did build on 8.0/i386 this time. A parallelism issue is coherent with the error message from the previous run (trying to access a non-existent file in the build directory) -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: repo missing package
On Fri 10 Jan 2020 at 10:25:13 -0500, Greg Troxel wrote: > So maybe I've been lucky. Maybe it's MAKE_JOBS. Maybe it's something > else we don't understand. On my machine, rust and firefox also "just built". I did get messages in my xconsole windown about random though, but not only during these builds it seems. Jan 2 06:58:48 murthe /netbsd: cprng 26328 17 30: creating with partial entropy Rust took some 2,5 hours to build it seems; firefox nearly 14. (But I did pause building a few times and I don't remember when exactly) -rw-r--r-- 1 root wheel 360726 Jan 2 06:44 babl-0.1.72.tgz -rw-r--r-- 1 root wheel 296670777 Jan 2 09:17 rust-1.39.0nb2.tgz -rw-r--r-- 1 root wheel1181253 Jan 2 22:58 alsa-lib-1.1.4.1.tgz -rw-r--r-- 1 root wheel 57394952 Jan 3 11:50 firefox-71.0.tgz -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: repo missing package
Patrick Welche writes:
> On Wed, Jan 08, 2020 at 06:38:16PM -0500, Greg Troxel wrote:
>> I was able to build rust and firefox on 2019Q4.
>
> Did it just work, or did you keep having to restart it? (PR pkg/54795)
> (and gpgme always hangs for me in pbulk, but always works with cd gpgme &&
> make)
I am pretty sure it just worked, but I was not paying attention. What I
am doing is:
hardware is a 2008 MacBookPro3,1 (4G RAM, 232G spinning disk)
system is netbsd-8 amd64 (up to date, not 8.0)
pkgsrc is checked out and symlinked into /usr/pkgsrc
I use ccache
MAKE_JOBS=1 (because I'd rather wait than have heat)
loop:
I update pkgsrc (was head, and this was during freeze, and at
branching I have flipped the box to Q4 with -r).
I rm all the work directories.
I run "pkg_rolling-replace -uvk", and on later runs when I get
serious about fixing things (vs getting a handle on the state of the
branch), I omit the -k.
I look at what failed, try to fix them, often committing something,
and often just rm'ing some packages and rebuilding because there is
some problem that causes make replace trouble but not a pbulk build
(scons version conflict, files moving between packages, etc.)
goto loop
I have a function to list package installation times (which for pkg_rr
correspond to build times):
pkgwhen ()
{
( cd /var/db/pkg && lt */+CONTENTS | sed -e 's/\/+CONTENTS//' )
}
lt ()
{
ls -ltr "$@"
}
Here is a fragment of the output of pkgwhen. You can see that rust took an
enormously long time to build, ~17h. firefox took ~10h.
I am 99.9% sure I didn't touch
the box during this time, other than perhaps to tail the pkg_rr output
or run pkgwhen to see how it was doing.
-rw-r--r-- 1 root wheel93776 Dec 18 18:32 x11-links-1.31
-rw-r--r-- 1 root wheel 390 Dec 18 18:33 ccache-3.7.6
-rw-r--r-- 1 root wheel 905 Dec 18 18:36 sqlite3-3.30.1
[snip]
-rw-r--r-- 1 root wheel 857 Dec 20 12:02 erlang-iconv-1.0.8
-rw-r--r-- 1 root wheel 955 Dec 20 12:03 erlang-fast_yaml-1.0.15
-rw-r--r-- 1 root wheel 1086 Dec 20 12:03 erlang-fast_tls-1.0.23
-rw-r--r-- 1 root wheel 1071 Dec 20 12:04 erlang-eimp-1.0.6
-rw-r--r-- 1 root wheel 2134552 Dec 21 05:14 rust-1.39.0nb2
-rw-r--r-- 1 root wheel 918 Dec 21 06:23 erlang-stringprep-1.0.12
-rw-r--r-- 1 root wheel 1814 Dec 21 06:23 erlang-fast_xml-1.1.32
-rw-r--r-- 1 root wheel10324 Dec 21 06:24 erlang-xmpp-1.2.2
-rw-r--r-- 1 root wheel 8396 Dec 21 09:26 py27-qwt-qt4-5.2.0nb4
-rw-r--r-- 1 root wheel 275794 Dec 21 09:28 py27-twisted-18.9.0nb1
-rw-r--r-- 1 root wheel40064 Dec 21 09:29 py27-nevow-0.14.4
-rw-r--r-- 1 root wheel 481 Dec 21 09:30 tex-pdfcrop-1.37nb4
-rw-r--r-- 1 root wheel33067 Dec 21 09:44 py27-foolscap-0.13.1
-rw-r--r-- 1 root wheel 1224 Dec 21 09:46 py37-libxml2-2.9.10
-rw-r--r-- 1 root wheel 946 Dec 21 09:46 itstool-2.0.6nb1
-rw-r--r-- 1 root wheel10461 Dec 21 09:47 mate-polkit-1.22.0nb2
-rw-r--r-- 1 root wheel 381495 Dec 21 09:59 gnome-themes-standard-3.20.2nb9
-rw-r--r-- 1 root wheel 8004 Dec 21 10:02 xfce4-xarchiver-0.5.4.14
-rw-r--r-- 1 root wheel 462230 Dec 21 10:04 xfce4-wm-themes-4.10.0nb12
-rw-r--r-- 1 root wheel 375 Dec 21 10:54 cbindgen-0.10.1
-rw-r--r-- 1 root wheel 700456 Dec 21 21:45 firefox-71.0
-rw-r--r-- 1 root wheel 5357 Dec 21 21:49 libcanberra-0.30nb1
[snip]
-rw-r--r-- 1 root wheel 8106 Dec 22 01:40 xfce4-desktop-4.14.1
-rw-r--r-- 1 root wheel11073 Dec 22 01:44 py37-anytree-2.7.2
-rw-r--r-- 1 root wheel13438 Dec 22 01:48 py37-lxml-4.4.2
-rw-r--r-- 1 root wheel77281 Dec 22 01:49 py37-pygments-2.4.2
-rw-r--r-- 1 root wheel23177 Dec 22 01:54 tex-oberdiek-2019
and then the timestamps jump making it clear there were later runs.
I did an update (on the branch) last night, and am doing a fresh pkg_rr
run. After that's done I can do a 'make package' in rust and then in
firefox.
On a similar machine (but a 2006 non-pro macbook, on which I am running
netbsd-8 i386), rust and firefox also built ok.
So maybe I've been lucky. Maybe it's MAKE_JOBS. Maybe it's something
else we don't understand.
Re: repo missing package
On Wed, Jan 08, 2020 at 06:38:16PM -0500, Greg Troxel wrote: > I was able to build rust and firefox on 2019Q4. Did it just work, or did you keep having to restart it? (PR pkg/54795) (and gpgme always hangs for me in pbulk, but always works with cd gpgme && make) Cheers, Patrick
Re: repo missing package
George Georgalis writes: > On Wed, Jan 8, 2020 at 5:17 PM Greg Troxel wrote: >> >> As for gating the release announcement, that isn't really reasonable, > > okay, fine :) it's my first choice of package manager because it's > separate form the OS anyway :) > > I think it was only (relatively) recently I started using > NetBSD/amd64/8.1/All and I didn't think about the consequences at all, > using 8.x_2019Q3 and/or pkgsrc is a better value for me. You can also build your own packages and then use pkgin on them. I would encourage you to build things from source, if you have the disk space and a machine that can cope (say 100G of disk and 4G of RAM should be ok). You can mix your packages and the official builds in practice, if you are careful to check out the pkgsrc-2019Q4 branch. You can also choose pkgsrc-current but those don't mix with the branch builds. > Clock management has had more issues in releases than any other > device, in my vmware and virtualbox experience. I think it stems from > RTC doesn't make sense in a VM, so it's hard to characterize expected > behavior, let alone support it, and inherit NTP at the same time... > > thanks for the links. A patch for rust to test the monotonic clock vs > RTC might be an easy win, but if that fails I'd consider removing the > forward clock tests altogether, if that is actually a problem > (comparing timestamps in tests vs in operation), maybe a different > locking scheme could resolve the issue? I really haven't looked into this. If you can figure out what's going on precisely that would be helpful. > if xen vm clock counters are rolling backward, I'm sure there is a > very good and likely very complicated reason for it, if xen is not > using the monotonic api for vm timesource, I'm very curious why? If > the monotonic time source is moving backward, then I'm sure this will > be very interesting bug and would reconsider removing the rust clock > tests. ;-) I don't understand what you mean. xen runs on the bare metal and the dom0 and domUs run under xen. This is different from nvmm/kvm/virtualbox/vmware-desktop and similar. > > > > > > > > -- > George Georgalis, (415) 894-2710, http://www.galis.org/
Re: repo missing package
On Wed, Jan 08, 2020 at 06:38:16PM -0500, Greg Troxel wrote: > [...] > > I was able to build rust and firefox on 2019Q4. There is a rust/xen bad > interaction. I'm not sure Xen is to blame here. I got rust build failure on bare metal as well. -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: repo missing package
On Wed, Jan 8, 2020 at 5:17 PM Greg Troxel wrote: > > As for gating the release announcement, that isn't really reasonable, okay, fine :) it's my first choice of package manager because it's separate form the OS anyway :) I think it was only (relatively) recently I started using NetBSD/amd64/8.1/All and I didn't think about the consequences at all, using 8.x_2019Q3 and/or pkgsrc is a better value for me. > As I understand it, there is some kind of bad clock behavior in a NetBSD > domU (under xen), and I think the issue is that one the clocks can go > backwards slightly. I am not sure this violates POSIX, but it seems > rust fails if it detects this. I can't find the PR that describes this. > > The relevant standard might be > > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_gettime.html > > So if anybody wants to help, set up Xen, and in a NetBSD 8 domU, install > pbulk and then try to build rust, and debug from there. > > This may be a useful clue (but it may not be): > > https://github.com/longsleep/linux-pine64/issues/44 Clock management has had more issues in releases than any other device, in my vmware and virtualbox experience. I think it stems from RTC doesn't make sense in a VM, so it's hard to characterize expected behavior, let alone support it, and inherit NTP at the same time... thanks for the links. A patch for rust to test the monotonic clock vs RTC might be an easy win, but if that fails I'd consider removing the forward clock tests altogether, if that is actually a problem (comparing timestamps in tests vs in operation), maybe a different locking scheme could resolve the issue? if xen vm clock counters are rolling backward, I'm sure there is a very good and likely very complicated reason for it, if xen is not using the monotonic api for vm timesource, I'm very curious why? If the monotonic time source is moving backward, then I'm sure this will be very interesting bug and would reconsider removing the rust clock tests. ;-) -- George Georgalis, (415) 894-2710, http://www.galis.org/
Re: repo missing package
George Georgalis writes: > On Wed, Jan 8, 2020 at 3:38 PM Greg Troxel wrote: > >> The default URL is repointed, but you should still be able to get the >> previous branch. > > I have success using > http://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0_2019Q3/All/ > > but my inquiry was for 'last successful packages' from amd64/8.1/All > ...would seem that's what I have now, however, is it a bug that the 8.1 > url is linked to 8.0_2019Q4 already? or perhaps Q4 announcement > should be gated with successful building of Q3 packages? pkgsrc itself in 2019Q4 is actually ok; the problem was that rust failed on NetBSD's pkgbuild cluster. I built rust 1.39.0 on netbsd-8 (up to date stable) amd64 on December 19. As for gating the release announcement, that isn't really reasonable, because pkgsrc supports 23 operating systems, and on those many CPU architectures and multiple releases. This is just one of many cases, albeit arguably the most important from the NetBSD point of view. The announcement is simply an email that goes out. People start running bulk builds when they choose, and they finish at some point. In this case I was busy between branch-tagging (which is also end of freeze) and announcement (and we produce drafts and review them), so I did wait about 24h for the 8/amd64 build to finish, but only as a microoptimization to avoid people asking where those results were, not because I really consider announcement and builds finishing to be linked. As I understand it, there is some kind of bad clock behavior in a NetBSD domU (under xen), and I think the issue is that one the clocks can go backwards slightly. I am not sure this violates POSIX, but it seems rust fails if it detects this. I can't find the PR that describes this. The relevant standard might be https://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_gettime.html So if anybody wants to help, set up Xen, and in a NetBSD 8 domU, install pbulk and then try to build rust, and debug from there. This may be a useful clue (but it may not be): https://github.com/longsleep/linux-pine64/issues/44
Re: repo missing package
On Wed, Jan 8, 2020 at 3:38 PM Greg Troxel wrote: > This is the build for 2019Q4. It started before the announcemnt, when > the branch was created and someone had time to start it. I discovered the problem today, renewing a vm with http://nyftp.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.1/All > > If so, why were they removed from the url? Is a prior, more successful > > bulk build directory available? > > The default URL is repointed, but you should still be able to get the > previous branch. I have success using http://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.0_2019Q3/All/ but my inquiry was for 'last successful packages' from amd64/8.1/All ...would seem that's what I have now, however, is it a bug that the 8.1 url is linked to 8.0_2019Q4 already? or perhaps Q4 announcement should be gated with successful building of Q3 packages? -- George Georgalis, (415) 894-2710, http://www.galis.org/
Re: repo missing package
George Georgalis writes: > Thanks for this info, (and the comment about rust, Greg). > By the looks of that page, a full build takes a minimum of 9 days, maybe > more. > > pkgsrc bulk build for NetBSD 8.0/x86_64 > Build start: 2019-12-29 11:55 > Build end: 2020-01-06 12:47 yes, it takes a long time. Also there are multiple builds sharing the cluster, and most of them have converged. > That would put the next build minimum Jan 15, unless successful > packages are not rebuild. The new build is incremental and faster, as I understand it. > Since this is not a new pkgsrc branch, wouldn't the prior successful > binaries be compatible? This is the build for 2019Q4. It started before the announcemnt, when the branch was created and someone had time to start it. > If so, why were they removed from the url? Is a prior, more successful > bulk build directory available? The default URL is repointed, but you should still be able to get the previous branch. I was able to build rust and firefox on 2019Q4. There is a rust/xen bad interaction.
Re: repo missing package
On Wed, Jan 8, 2020 at 12:45 PM Ottavio Caruso wrote: > > On Wed, 8 Jan 2020 at 20:20, Ron Georgia wrote: > > > > Am I missing something? I lot of packages are missing out of the > > https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.1/Allrepo. > > Like firefox, tint2, feh... was this on purpose or am I out to lunch? > > > That's because all those build failed: > http://nyftp.netbsd.org/pub/pkgsrc/packages/reports/2019Q4/NetBSD-8.0-x86_64/20191229.1155/meta/report.html Thanks for this info, (and the comment about rust, Greg). By the looks of that page, a full build takes a minimum of 9 days, maybe more. pkgsrc bulk build for NetBSD 8.0/x86_64 Build start: 2019-12-29 11:55 Build end: 2020-01-06 12:47 That would put the next build minimum Jan 15, unless successful packages are not rebuild. Since this is not a new pkgsrc branch, wouldn't the prior successful binaries be compatible? If so, why were they removed from the url? Is a prior, more successful bulk build directory available? Thanks, -George -- George Georgalis, (415) 894-2710, http://www.galis.org/
Re: repo missing package
Ah. Thanks. So that’s what that means. Guess I need to pay closer attention. On Wed, Jan 8, 2020 at 3:45 PM Ottavio Caruso < ottavio2006-usenet2...@yahoo.com> wrote: > On Wed, 8 Jan 2020 at 20:20, Ron Georgia wrote: > > > > Am I missing something? I lot of packages are missing out of the > > https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.1/Allrepo. > > Like firefox, tint2, feh... was this on purpose or am I out to lunch? > > > That's because all those build failed: > > http://nyftp.netbsd.org/pub/pkgsrc/packages/reports/2019Q4/NetBSD-8.0-x86_64/20191229.1155/meta/report.html > > -- > Ottavio Caruso > -- Ron Georgia “90% of my problems are due to ignorance, the other 10% is because I just don’t know any better.”
Re: repo missing package
Ron Georgia writes: > Am I missing something? I lot of packages are missing out of the > https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.1/Allrepo. Like > firefox, tint2, feh... was this on purpose or am I out to lunch? It is probably true that you are ok and it was not intentional. Bulk builds are done under xen, and xen is not quite the same as native, and some packages are overly finicky. One of the difficult ones is rust. The builds continue to run and it is somewhat likely that the next run will build rust and hence a lot more packages.
Re: repo missing package
On Wed, 8 Jan 2020 at 20:20, Ron Georgia wrote: > > Am I missing something? I lot of packages are missing out of the > https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.1/Allrepo. > Like firefox, tint2, feh... was this on purpose or am I out to lunch? > That's because all those build failed: http://nyftp.netbsd.org/pub/pkgsrc/packages/reports/2019Q4/NetBSD-8.0-x86_64/20191229.1155/meta/report.html -- Ottavio Caruso
repo missing package
Am I missing something? I lot of packages are missing out of the https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/8.1/Allrepo. Like firefox, tint2, feh... was this on purpose or am I out to lunch? -- 90% of my problems are due to ignorance, the other 10% is because I just don't know any better.
